I have a CC2541 running a modified version of SimpleBLEPeripheral, communicating with an iOS device. Upon connection w/ the iOS device, I issue ConnParamUpdate to get my desired parameters, most important of which is my Supervision Timeout, which I want to be as high as possible based on the problems I'm seeing. I am familiar with the ConnParam rules on iOS, and I have a packet sniffer running, showing me that I get a response of SUCCESS after my ConnParamUpdates.
After updating the parameters, the iOS dumps a lot of data over to the Peripheral, the last few bytes of which are a footer. When the Peripheral sees the footer, it calls a function which takes all of this data (which it has been storing in NVM using HalFlashWrite in real-time as the data comes over piece by piece), reads it back from NVM using HalFlashRead, and then writes it out to SPI Flash using a flashWrite function I wrote. This is accomplished using a nested for() loop, where I basically do this:
for( do this 40 times)
{
for (do this 8 times)
{
HalFlashRead();
flashWrite()
}
}
My problem is that after a few cycles of HalFlashRead and flashWrite, my radio stops responding, and the connection eventually times out on the iOS side of things. Since iOS isn't great at dropping connections, I'm being forced to end the connection from the CC2541 -- I don't want to have to keep connecting/disconnecting all the time, so I'm trying to figure out what's causing the iOS to consider the connection as "timed out". To be clear, the iOS log shows the connection as "timed out" only once the Supervision Timeout has been reached, but I know that the iOS has "given up" on the connection long before this Supervision Timeout, because the CC2541 stops responding during this heavy for() loop processing. This is what I think, anyway.
I see the L2CAP-C packets on my Bluetooth sniffer just stop coming up, shortly after I enter this heavy processing loop -- as if the iOS device gives up trying to send them, even though the Supervision Timeout has definitely not been reached yet. This nested for loop only takes a second (two at the very most) to complete, and if my Supervision Timeout is set to, say, 5 seconds, then there are 3 seconds after this heavy process during which I would *assume* that the CC2541 radio would pick back up with communication to the iOS device, but this doesn't happen. Instead, the iOS shows that the connection has terminated / timed out. It's worth mentioning that I know my Supervision Timeout settings are being understood by the iOS device, because I can watch the log file report a connection timeout after 3 seconds, or 5 seconds, depending on what I set the Supervision Timeout at.
I am wondering three things:
1) Why do these function calls seem to block the RF performance of the CC2541? I thought the RF stuff had the highest priority
2) Is this an issue with L2CAP or LL? Am I missing Connection Events? Maybe an interrupt lockup has occurred?
3) Since the RF does seem to be blocked, I need a way to "kick" it back into gear once my heavy HalFlash and SPI Flash processing is done. I have plenty of time to do this, because the Supervision Timeout is more than twice the length of time that this heavy processing takes.
My goal here is to not have to disconnect the BLE connection during this NVM and SPI Flash processing.