Reading back uninitialised variable after soft reset nRF52 GCC

RE: Reading back uninitialised variable after soft reset nRF52 GCC

RK — Wed, 28 Jun 2017 12:18:21 GMT

it's 'lose' not 'loose'.

The datasheet doesn't say a pin reset clears RAM. None of the resets clear RAM, RAM contents is not guaranteed to be preserved, but it's not cleared, here's the note from the datasheet

Note: The RAM is never reset, but depending	on reset source, RAM content may be corrupted.

My experience has been it's never corrupted either.

You need to put a breakpoint on the reset handler, either your reset handler or the bootloader one. Find the address at 0x00000004 and breakpoint that (minus 1). You want the debugger to halt AS SOON as reset happens before even one instruction of code has been run. If your RAM location is zero then when it wasn't before the reset, I'm wrong and you can't do this. If it's not zero, something is zeroing it. Never mind the nrf52 startup file, gcc has its own crt0 (or equivalent) which is doing loads of copies and zeroes.

RE: Reading back uninitialised variable after soft reset nRF52 GCC

siliconwitch — Wed, 28 Jun 2017 08:50:44 GMT

According to section 18.8 (page 83) of the nRF52 datasheet, the table shows that for both CPU lockup and soft reset, the RAM is preserved.

The conditions where RAM may be corrupted are for power and pin reset reasons. This is fine because I report back POWER->RESETREAS along with my stored data. If the reset was caused by a condition that would have corrupted RAM, then I ignore the saved data anyway. For the soft reset condition (which both app error and hardfault cause), I should be fine to read back the RAM

RE: Reading back uninitialised variable after soft reset nRF52 GCC

endnode — Wed, 28 Jun 2017 00:50:59 GMT

Thx, not erased (by itself) but "unpredictable" (and should be init during start-up sequence which hammerfet want's to skip). My misunderstanding.

RE: Reading back uninitialised variable after soft reset nRF52 GCC

RK — Wed, 28 Jun 2017 00:40:05 GMT

zero_init isn't a defined GCC attribute so that's why it's ignored. Do you actually have a NoInit section in your linker file and if so what are its attributes. The most likely thing is it's being placed in a section which is zero-erased on startup. You need to go debug the startup code which is called after the reset handler and find out which sections are neither zero-filled, nor loaded from flash.

@endnode - RAM is not erased on reset. There's no guarantee it doesn't get corrupted but it's not erased. My experience is I've never yet seen it corrupted either but I'm sure it happens.

RE: Reading back uninitialised variable after soft reset nRF52 GCC

endnode — Tue, 27 Jun 2017 23:52:04 GMT

But soft reset works as any other reset = RAM is erased. I'm afraid this kind of information preserving won't work... at least all similar systems of "Hard fault logging" on nRF5x I've seen so far were using NVM (= allocating one or more flash pages and implementing simpler or more complex systems how to log/retrieve/interpret/report/clean the fault events).