Hi all,
I've painstakingly traced a stall in the CC3000 driver code to a call to nvmem_read() which happens during wlan_smart_config_process(). This call attempts to read the AES key from NVMEM on the CC3000, and is split into two parts - SimpleLinkWaitEvent() immediately followed by SimpleLinkWaitData(). I've managed to figure out that in between these calls, there is a delay between SpiPauseSpi() and SpiResumeSpi() that is causing an interrupt to be missed, meaning that the driver waits forever for data (the second step of nvmem_read()).
Here is a logic trace showing the problem. Note that line 6 shows the state of interrupt processing - enabled is HIGH, paused/disabled is LOW.
As you can see, IRQ goes low while interrupt handling is disabled. It resumes shortly, but by that point it is too late.
My question is - am I implementing resume and pause correctly? I'm simply disabling and enabling interrupts on the IRQ pin. If this is correct, it seems like I've hit some kind of race condition or even a bug in the library.
Thanks!
Vishal