This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ACI_EVT_HW_ERROR line 571 nrf8001

I am using a nrf8001 and the arduino aci library ported to work with my project. I have started from hello world example. Connecting to the device from android app, sending some data over the uart and then disconnecting seems to be mostly working fine. After some time I get something like this in my debug output

C5 :5, F, 0, 0, 50, 0,

Advertising started. Tap Connect on the nRF UART app

E3 :3, 84, F, 0,

E4 :4, 81, 3, 1, 2,

Evt Device Started: Standby

E25 :19, 83, 3B, 2, 6C, 6C, 5F, 6C, 6D, 2E, 73, 30, 2E, 63, 0, 18, 23, DB, F9, F0, 36, 28, A0, D9, 0, 0,

HW error: 571

6C 6C 5F 6C 6D 2E 73 30 2E 63 0 98 23 DB F9 F0 36 8 A0 D9 0 0 0

C5 :5, F, 0, 0, 50, 0,

Advertising started. Tap Connect on the nRF UART app

after this, the device does not seem to be advertising anymore and requires a power cycle to get it back to working.

The markings on the chip are "NRF D 8001 143900"

Any help would be greatly appreciated. Thanks

seems pretty similar to this question devzone.nordicsemi.com/.../

  • If you get an Hardware Error Event, you should be able to recover it with a pin reset to the nRF8001. Does that work for you ? What is the Android version that you are using and the phone model ?

  • I'm mostly testing with a Nexus 5x on android 7 but have also tested with a samsung S7 edge which I think is running 6. I will try doing a pin reset today. What I found yesterday was I seem to be able to get it to the state where I get the "Advertising started. Tap Connect on the nRF UART app" debug output but it no longer seems to be advertising without that hardware error showing up at all.

  • Well I changed to another board (same design) and now I am seeing hardware errors still, but it actually does go back to advertising afterwards (without doing a pin reset). I didn't get a chance to try the pin reset on that previous board.

  • I think this needs a bit more work so I suggest that you move this case to the support portal so there will be a bit more attention.

  • I think I have figured out why my chip was stopping. Occasionally the RDYN line takes longer than I had expected to become low after REQN was pulled low. I had overlooked the fact that the library pulls the REQN line low forever while it polls for the RDYN line to be low. I had other things for the micro to be doing and one of these things used the SPI. So on these occasions when RDYN took too long I was doing SPI with REQN left low (RDYN could come low while the other tasks had priority) which unsurprisingly seems to have been the cause of the nrf8001 stopping working.

    Now my question is: If I pull REQN low but then I need to do something else before the RDYN comes low is there any problem with me putting the REQN high while I do other things and then pull it low when I have time to deal with the nrf8001 again? I am trying this now and it seems to be working fine.

Related