My problem is that the BLE stack misbehaves when the application SW is started via a bootloader.
When there is no bootloader (application started directly) BLE works correctly.
The problem: BLE scanning (RX) reports in invalid (gapScannedDevice_t) length, advEventType and payload.
BLE advertisment (TX) works correctly even when started from bootloader.
Is there something RAM address dependent regarding Gap_StartScanning/gapScannedDevice_t parameter?
Bootloader should be transparent to application, so it considered as a clean start. (stack reset, bss cleared..)
Bootloader seems to be working correctly, also rest of the application too, only the BLE part fails.
Bootloader (no BLE stack) at flash address: 0x21000000
jump to app
vector_p = 0x21019000
SCB->VTOR = vector_p
Application flash address: 0x21019000
binary image shifted by 0x19000
MCUXpresso SDK v2.2.0
You can check the bootloader example that we provide in for the OTA example as well as give a check to the BLE Application Developer's Guide.pdf for further details on this.
Hope that helps.
After a lot of debugging I figured out that calling CALIB_SystemCalib library function for the 2nd time reduces the BLE tag report count by 3. (from 30tag/sec to 10)
First it was called from bootloader, 2nd it was called from application. Digging deeper it is the CALIB_PowerOn(); part that causes this problem.
Reported tags are still valid, but less.
Looks like a library or HW bug.
It would appear that the issue it's in the bootloader as this does not seem to happen in the example applications, are you using your custom board?
Did you use the one I mentioned as a base?
Sorry I forgot to mention I could reproduce the issue without a bootloader, so in the application I just called CALIB_SystemCalib twice, and the find rate went down by 3 times, and it is easy to reproduce.
We use custom board with 32Mhz crystal, but that shouldn't matter.
What do you mean that you are calling the CALIB_SystemCalib twice? Your board design can affect, is this reproducible in the development kit?
Is there a way to fully reset the BLE SW stack?
Looks like to retains some data even when jumping to main application (resetting stack, clearing static variables), BLE causing a lot of problem for us.
Doing this doesn't solve the problem: