• State Verified Answer
  • Replies 7 replies
  • Subscribers 62 subscribers
  • Views 4870 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 100096
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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
...
  • 0

    Update: I've pinpointed the cause of the failure to the "loading dynamic data" stage. I modified my code to only load dynamic data after the power is cycled (instead of before every connect attempt); the data is still saved after every disconnect. This allowed me to successfully disconnect/re-connect, however the original problem is still present after the chip's power is cycled because dynamic data must be loaded back to the chip.

  • 0

    Hi Tom,

    1. Could you please let me know whether in your ACI driver, ACI commands wait for command response?
    2. Load dynamic data, after this sequence of commands from your controller, nRF8001 post-processes the dynamic data. This should complete in few milliseconds. Could you be able to provide a verbose log from your application controller with timestamp on each ACI cmd sent?

    The load dynamic data and immediate advertisement using ACI_CONNECT after a pin reset and the same sequence after a disconnection, save dynamic data, load dynamic data and ACI_CONNECT should have similar outcome. The requested log will be helpful in providing you with more information.

    Regards, Vinayak

  • 0 in reply to vich
    1. Yes, I wait for a command response event after each command, with excessive timeouts (1 second typical and 5 seconds for extra delay of last setup command, as Figure 44 indicates).
    2. It seems to be working fine, but maybe there's a timing issue... looking at my SPI logic analyzer output, the procedure is:
    • send 1st Setup command, out of 17 total setup messages
    • 1st CommandResponse event arrives after 43 ms (maybe just preparing for Setup?)
    • next 15 Setup commands/CommandResponse events take about 1 ms between each (as expected)

    NOTE: occasionally one or more of the first 16 Setup commands will have to wait between 400-900 ms to receive CommandResponse event

    • send 17th and final Setup command -17th CommandResponse event arrives after 915 ms (expected post-processing?) -DeviceStarted event (standby mode) arrives after 1 ms -then first 5 WriteDynamicData commands/CommandResponse events take about 1 ms between each, out of 6 total dynamic data messages -send 6th and final WriteDynamicData command -6th CommandResponse event arrives after 3 ms (expected post-processing?) -send Connect command -get DeviceStarted event after 345 ms, with standby mode and fatal HW error -get HardwareError event with file = "ll_ctrl.s0.c" and line = "814"

    Hopefully this helps... I assume that once I get the final CommandResponse event to the WriteDynamicData command, the device is ready to receive the Connect command.

  • 0

    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

  • 0 in reply to David Edwin

    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.

Related