Closed leibin2014 closed 9 years ago
Some more discovery: There is a API btle_initializeSecurity() in the latest nRF51822 driver. Currently I use this API for init Security, then meet the target polling failed problem. In API btle_initializeSecurity() it calls functions pstorage_init(), sd_ble_opt_set(BLE_GAP_OPT_PASSKEY, &opts) and dm_init(). There wasn't such a API in the old code. I just called sd_ble_opt_set(BLE_GAP_OPT_PASSKEY, &opts), didn't call pstorage_init() and dm_init(). Didn't meet this problem in the old code. So looks like this problem is related to pstorage or device manager process.
pstorage_init() is called to initialize Nordic's Pstorage module, which is needed to store bonding information if bonding is requested. We haven't changed anything explicitly to cause different debugging behaviour. There is a demo to exercise security APIs: https://developer.mbed.org/teams/Bluetooth-Low-Energy/code/BLE_SecureHeartRate/. Could you please verify that this demo works usefully on your platform?
One more thing. You mentioned that you've tried to go back to S110. S110v8 has a different application start address when compared to s130, I hope you've taken that into account.
If you believe the problem arises from pstorage_init(), then try to comment it out and see if things work better. But please verify that the SecureHeartRate demo works for you.
After I comment out pstorage_init() and dm_init(), the problem is gone.
that's interesting. Could you please work with the SecureHeartRate demo and verify that it works for you?
Here is some comments from Nordic guy:
DM uses pstorage for storing the bond info persistently in flash and the CPU is being halted during flash writes. Maybe that could explain the debug behavior you see, although it should not take several seconds.
Hi, Thanks for bringing in feedback from Nordic. They're the real authors and maintainers of pstorage.
If you don't attach the debugger, does the SecureHeartRate demo work?
I have just tested the SecureHeartRate demo. It also have the same problem.
The OpenOCD output is as below: Info : Padding image section 0 with 2112 bytes Info : Padding image section 1 with 2856 bytes Warn : using fast async flash loader. This is currently supported Warn : only with ST-Link and CMSIS-DAP. If you have issues, add Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg to disable it Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (9445). Workaround: increase "set rem otetimeout" in GDB target state: halted target halted due to debug-request, current mode: Thread xPSR: 0xc1000000 pc: 0x000006d0 msp: 0x000007c0 Error: nrf51.cpu -- clearing lockup after double fault Polling target nrf51.cpu failed, trying to reexamine Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints Error: address + size wrapped(0xfffffffe, 0x00000004) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0xc1000000 pc: 0x000006d0 msp: 0x000007c0 Warn : target nrf51.cpu is not halted Polling target nrf51.cpu failed, trying to reexamine Info : SWD IDCODE 0x0bb11477 Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
Does the SecureHeartRate demo work for you when you're not connected using OpenOCD? If it does, I'd argue that this is something you should take up with Nordic, since they're responsible for the functionality of pstorage. It may also be that it is unfair to expect pstorage to work in presence of SWD debugging.
Yes, the demo works fine if I don't connect using OpenOCD. Even if I connect using OpenOCD it still works fine, just the GDB is broken.
Dear,
We are using nrf51822 for products of our company. We use mbed + nRF51822 driver + BLE_API for the BLE peripheral devices. We use OpenOCD+GDB for SWD interface as debugging tool. In OpenOCD the target is polled each 100ms. Previously everything is fine. But recently the target is always polled failed in several seconds after getting BLE_GAP_EVT_AUTH_STATUS event.
This problem is cause by updating the nRF51822 driver and BLE_API to the latest version( with softdevice s130 ver 1.0.0). If roll back to the old version with s110 v7.1.0, this problem is gone. I also tried replacing s130 with s110 v8.0.0 in the latest nRF51822 driver, the problem is still there.
Our application for the peripheral device is as below:
So my question is what cause this problem? Anything related SWD or debugging stuff was changed when nRF51822 driver was updated from s110 v7.1.0 to s130 v1.0.0(or s110 v8.0.0)?
If any more information you need please feel free to let me know.
Thanks!