NRF51822 reset handler

[Chris Hunt]

Hi all,

I'm having a bit of trouble figuring out why my project using the RedBearLab BLE Nano board is not working. I'm using the NRF51822 as the hub in a star network using the ESB protocol. The hub is connected to a serial port and will return each sensor's current state when queried through the serial port. The hub works as described immediately after flash and after pin reset is activated through a button. However, the hub will not work when immediately plugged in. Although it will work once the button is pressed.

I feel as though this behavior may be because I have not configured power-on reset or the reset handler (in assembly) correctly? One strange thing I have noticed is that after button reset or initial flash, the NRF_POWER->EVENTS_RXDRDY register reads 0 and 1 as expected. However, after unplugging the hub and replugging it, that register always reads 1. This leads me to believe I am not cleaning up resources appropriately (i.e. my reset handler is not working). Any help in this regard would be greatly appreciated. Thank you for your time.

Note: I am not using any SoftDevice, if that matters at all.

EDIT: I've attached my project as a zip file. I'm using the GCC cross compiler with a single Makefile to compile the hex files. The relevant source file I've been discussing is in '/OrientationTrackingRX/source/main.c'. I've also included the board schematics in the Schematics subfolder. The BLE Nano board schematic is labeled while the USB interface I'm using is the MK20 USB schematic. I'd like the stress that I'd consider myself a newbie to serious embedded programming and would welcome any notes or critiques in general about the project structure and stuff. Please let me know if anything else is required. Thank you all!

Attached Project: NordicSemi.zip

[Chris Hunt]

Yes, the topology of the network is as you described. I guess it is a bit difficult to describe what exactly the issue is. Right after flashing any device, it works as expected. For the hub, this entails receiving packets from each node over ESB and receiving and sending commands to the usb. Each node also reads data from its sensor over I2C and sends that data to the hub over ESB. Additionally, I get the expected behavior after I reset a device using a reset button. However, if I simply power on a device (say by plugging in the MK20 to the PC USB port or connecting a node to a battery), I no longer get the expected behavior. For the hub, it does not respond to any UART commands and the nodes no longer respond to GPIO events. However, they seem to both still undergo ESB communication. That's kind of far as I have been able to parse out from my probing.

[AmbystomaLabs]

Sorry for the delay. I had an all day meeting yesterday.

I tried out the code on a 51822dk but it seems like I will have to set up quite a bit of hardware to make it all talk.

Just based on your comments and I own experience with UART's, I would guess some garbage is coming down the pipe from the usb transceiver on boot or since there is no flow control the uart just doesn't sync up correctly first time around. This is why the RX buffer has data and you get an event from it. Then my next guess is that it fails to parse correctly in the switch and things fall apart from there.

Assuming that the real issue is data in the RX buffer, some simple solutions you can try are to:

1. put a delay before you init the uart. This will hopefully give time for the usb transceiver to be ready.
2. do a reset if you see the RX event immediately after the uart init. If you are right and it should be clear then just wait till it is clear.
3. put in a loop to read the RX buffer to clear it after init.

I noticed you put in some code for NRF_POWER->RESETREAS. The way you are using it isn't correct. The power registers just retain data through a reboot. So reading the register only tells you that it just came out of a reset. The register doesn't drive the reset, that is done by the watchdog timer. I didn't see the corresponding code to init the watchdog timer. You can easily remove the code for resetreas and just make sure to init the WDT in main before the do loop. Then you can refresh the WDT in the loop if you wish. If it truly locks up then it won't run the main loop and will reset in one WDT interval.