This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Auto run on power up

I'm having some (minor) trouble with a board based on an NRF52840 that I want to start running as soon as power is applied... 

This is built using a RAK5010 board, but using custom firmware, the firmware uses an S340 softdevice.

Reading these forums it seems the general consensus is that once power is applied to the nrf52 then it should start executing, and the only similar discussions I could see were related to devices not being ready during power up and needing a delay or where the reset pin was incorrectly configured, neither is the case here.

The RAK5010 has an nrf52840 and a BG96 GPS module on board, the board has two switches one RST connected to the NRF reset pin (using pin 18) and a PWR connected to the BG96 chip. 

The behaviour I have is when power is applied nothing executes until the power button is used to turn on the BG96, at which point the NRF starts executing my code four seconds later.
On the schematic there's no connection from the power button to the NRF it is purely connected through the BG96, I can't see how/why any of the other connected pins would trigger the startup but clearly that must be the case.

So.... I wanted to understand the boot process and logic with a softdevice to try to work out if I have anything incorrectly configured during my install/flash that would be causing this and or what I can/or should change to fix this behaviour.


Is there any configuration that is flashed that can define what pins cause a startup? or alternatively is there any configuration that sets the board to *not* start executing unless a pin is toggled?

I can share my code since it will be opensource (albeit the full program is rather large) but I see this same behaviour if I compile any of the NRF SDK example program.

  • Thanks and Kenneth going to give up for a bit! I just can't see it.

    I used mass_erase to start from a clean slate so I don't think that's related to old code, dumping the flash all appears to be gone when I start off.

    I'm pretty sure the reset pin is being set correctly, I tried with, firstly, reset disabled (i.e. 0xFFs in 0x10001200 and 0x1001204) then I tried a few other values (e.g. 31, 18 etc).

    This board has a reset button attached to pin 18, so if I don't set it or I set it to some other value then that button no longer resets the nRF, if I set it to 18 then the reset behaviour is as expected. So. I think it's being set and unset correctly and is being handled correctly.

    If I have it set to 18, then when the board is "off" (i.e. board has battery power but before the BG96 is started up) then pressing that reset button does nothing so I think this is a deeper issue. Once the BG96 is powered up, the nRF app boots up and the reset button behaves as expected.

    Hence my first questions if there was anything else that controls this or could be causing this since I couldn't see anything in the documentation and it sounds from your answers like that isn't the case.

    All very odd and I can't figure it out at the moment. Not a show stopper, I can live with having to start up with the BG96 button, and unless it's not complete the RAK5010 schematic doesn't show any reason why this might happen.

    If I can find a way to get to the power and clock lines somewhere I'll have a go at monitoring those at some point.

    thanks again.

  • I am not aware of anything, so monitoring power lines I think is a good idea. There is some requirements to the rise up time on VDD that you can check at the same time:
    https://infocenter.nordicsemi.com/topic/ps_nrf52840/recommended_op_conditions.html 

  • Perfect! thanks for the tip/documentation link. I used that to follow and check the power lines and check the RAK schematic, the VDD1 line wasn't receiving 1.8v until the BG96 powered up, but oddly I saw they had a non-installed jumper to supply this on their schematic. If I add a jumper here (it's a 0ohm) then the behaviour is as expected and the nRF powers up on battery connection.

Related