nRF8001 re-connection fails with hardware error

[Tom]

When I successfully bond with an Android device, then disconnect the Android device, the following attempt to re-connect fails. It appears the chip enters some internal error state after disconnection, and even when I power cycle the chip occasionally the setup data loading will fail the first few attempts (*). Maybe someone knows what "file = ll_ctrl.s0.c, line = 814" means in the HardwareErrorEvent debug info? Is there a timing issue related to disconnecting and then re-connecting?

Here is my nRF8001-side debug output:

DEBUG: # BLUETOOTH: connected to peer address = 65:26:8A:B2:79:BA
DEBUG: # BLUETOOTH: bonded
... (Android disconnects)
DEBUG: # BLUETOOTH: disconnected (BTLE status code = remote user terminated [0x13])
DEBUG: # BLUETOOTH: saved dynamic data from nRF8001
DEBUG: # BLUETOOTH: loaded dynamic data to nRF8001
DEBUG: # BLUETOOTH: connecting...
DEBUG: # DeviceStarted: fatal hardware error
DEBUG: # HardwareError: file = ll_ctrl.s0.c, line = 814
DEBUG: # BLUETOOTH: powered off (my code forces power cycle after hardware error)
DEBUG: # BLUETOOTH: powered on
DEBUG: # BLUETOOTH: entered Setup mode
DEBUG: # BLUETOOTH: failed to load setup data to nRF8001 (*)
DEBUG: # BLUETOOTH: loaded setup data to nRF8001
DEBUG: # BLUETOOTH: entered Active/Standby mode
DEBUG: # BLUETOOTH: loaded dynamic data to nRF8001
DEBUG: # BLUETOOTH: connecting...
DEBUG: # DeviceStarted: fatal hardware error
DEBUG: # HardwareError: file = ll_ctrl.s0.c, line = 814
DEBUG: # BLUETOOTH: powered off
...

[David Edwin]

Hi,

Can you give the full chip markings on your nRF8001. The marking typically is [b]nRF D 8001 xyza AB [/b]

Can you also insert a 100ms delay between the final command response event for the writeDynamicData and the Connect command. Let us know the results

Thanks

[Tom]

Chip markings: NRF D 8001 1243FU

Inserting the delay seems to fix the problem... is this a reliable fix or just a hack? I'd feel more confident if the final CommandResponse event signaled the chip is ready, but I guess this will do.

[David Edwin]

I have done some measurements and I see that the delay can be as low as 10ms (instead of 100ms). You are correct, that the final Command Response Event should have signaled that the chip is ready. I will flag this as an issue and will have a note created for it.

Thanks

[Tom]

Thanks for looking into this more!