• State Verified Answer
  • Replies 7 replies
  • Subscribers 62 subscribers
  • Views 4883 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
...
Parents
  • 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.

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

Children
No Data
Related