NRF51822 reset handler

RE: NRF51822 reset handler

AmbystomaLabs — Thu, 18 Jan 2018 19:21:16 GMT

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:

put a delay before you init the uart. This will hopefully give time for the usb transceiver to be ready.
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.
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.

RE: NRF51822 reset handler

Chris Hunt — Wed, 17 Jan 2018 01:36:11 GMT

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.

RE: NRF51822 reset handler

AmbystomaLabs — Tue, 16 Jan 2018 23:54:57 GMT

Wow, quite the mix of hardware. I assumed the Red Bear was a module. Nope! It is a module with a BLE module slapped on it.

So, can you clarify what is working and not? I assume you mean the uart on hub is not working, but I'm not sure how you could distinguish this from ESB not working, or client uart connections not working.

Is the topology a red bear at each sensor, then ESB back to a red bear as hub, then uart to usb via MK20 to virtual uart on a PC?

RE: NRF51822 reset handler

AmbystomaLabs — Mon, 15 Jan 2018 19:28:09 GMT

I don't think it changes anything on the possible causes. Please post your code and a schematic of the nano board if possible. How are you powering it when it fails to start correctly? Also, the serial devices you have it connected to, are these all 3volt devices?

RE: NRF51822 reset handler

Chris Hunt — Mon, 15 Jan 2018 18:46:07 GMT

Oh I am sorry. The register is NRF_UART0->EVENTS_RXDRDY.

RE: NRF51822 reset handler

MartinBL — Mon, 15 Jan 2018 16:48:20 GMT

I have never heard of NRF_POWER->EVENTS_RXDRDY. Do you mean NRF_UART->EVENTS_RXDRDY?

RE: NRF51822 reset handler

AmbystomaLabs — Sun, 14 Jan 2018 17:21:51 GMT

Sounds like whomever wrote the code failed to initialize gpio/comms correctly. I don't think you can even configure the reset vector so not much to say about configuring reset. It should go to 0x0 and then start at the MBR if running SD, or the first line of your code if not running SD.

Some gpio/comms take a few clocks to be configured. Out of power reset everything goes back to defaults, but out of button reset this is not true. So likely the code runs, stuff gets initialized, some of it wrong and it doesn't work...you do a button reset, some of the settings are sticky and next time around it works.

This is especially true of the NRF_POWER-> registers.

Also, since it is not a Nordic DK you are using it could be a hardware issue. Anything processor related takes quite a bit of current to get the ball rolling. This aspect is often is lost on new engineers.
So, it could be some voltage dipping issue during a cold start.