Retain RTC during soft reset

RE: Retain RTC during soft reset

butch — Wed, 24 May 2017 12:22:15 GMT

Do you need all the RAM while cpu is active? One alternative is to leave blocks 0,1,2 disabled (power off) and modify your linker script to say there is only 8k of RAM (block3). Then the stack would be at the top of block 3 and your variables at the bottom. All would be valid after coming out of sleep and you wouldn't need to simulate a reset. I could be wrong?

RE: Retain RTC during soft reset

John — Thu, 21 Jan 2016 13:39:58 GMT

Note that the "noinit" sections for the non IAR examples require modification to the linker control files.

RE: Retain RTC during soft reset

John — Thu, 21 Jan 2016 13:38:19 GMT

Good point on the GPREGRET size. I missed that as well. Another way of allocating a variable to a specific location is below. Blatantly stolen from Nordics bootloader example:

    #if defined ( __CC_ARM )
static dfu_ble_peer_data_t m_peer_data __attribute__((section("NoInit"), zero_init));            /**< This variable should be placed in a non initialized RAM section in order to be valid upon soft reset from application into bootloader. */
static uint16_t            m_peer_data_crc __attribute__((section("NoInit"), zero_init));        /**< CRC variable to ensure the integrity of the peer data provided. */
#elif defined ( __GNUC__ )
__attribute__((section(".noinit"))) static dfu_ble_peer_data_t m_peer_data;                      /**< This variable should be placed in a non initialized RAM section in order to be valid upon soft reset from application into bootloader. */
__attribute__((section(".noinit"))) static uint16_t            m_peer_data_crc;                  /**< CRC variable to ensure the integrity of the peer data provided. */
#elif defined ( __ICCARM__ )
__no_init static dfu_ble_peer_data_t m_peer_data     @ 0x20003F80;                               /**< This variable should be placed in a non initialized RAM section in order to be valid upon soft reset from application into bootloader. */
__no_init static uint16_t            m_peer_data_crc @ 0x20003F80 + sizeof(dfu_ble_peer_data_t); /**< CRC variable to ensure the integrity of the peer data provided. */
#endif

RE: Retain RTC during soft reset

Martijn — Thu, 21 Jan 2016 13:23:16 GMT

uint32_t* backupCounter = (uint32_t*)0x20003000UL; //or whatever ram address you want to use *backupCounter = NRF_RTC0->COUNTER;

RE: Retain RTC during soft reset

braucadr — Thu, 21 Jan 2016 13:18:20 GMT

You're right, I was a bit too fast with my answer :-) My counter never reached the 8-Bit limit, so I didn't notice.

Concerning restoring the COUNTER value: I was assuming that GPREGRET was 32-Bit, so my idea was to add the current RTC COUNTER value to GPREGRET before resetting. RTC would then start from zero, but to get the time I would just take the current COUNTER value plus the summed up GPREGRET value.

Now that I realized that this approach doesn't work, I want to use a variable in the powered-on RAM. But how to make sure a variable is placed in a certain location in RAM?

RE: Retain RTC during soft reset

Martijn — Thu, 21 Jan 2016 12:54:19 GMT

but how? the GPREGRET is a 1 byte register and you can't backup the COUNTER register with it. and you can't restore the COUNTER value. I don't get it.

RE: Retain RTC during soft reset

braucadr — Thu, 21 Jan 2016 07:16:25 GMT

Thanks for your help guys. I went for the approach with GPREGRET

RE: Retain RTC during soft reset

RK — Thu, 21 Jan 2016 00:15:39 GMT

stack pointer initialised, yes and no. A 'real' reset takes the stack pointer from 0x00000000 and sets it before it does anything else so in that way, no it's not reset by what you're doing. However just about every startup assembler file I've seen ever also quite early on sets the SP to something valid explicitly. If you're getting all the way into main() then it's very unlikely the SP hasn't been set 2 or 3 times and is valid. So you probably have a different error.

Not sure that faking reset is the best way to go, it's hard to cover all the bases and get the chip in the same state it was in before. As John DeWitt suggests below, how about using a retained register and properly resetting. Also, if you just write it to a location in powered-on RAM, does that work, RAM isn't cleared by reset AFAIK.

RE: Retain RTC during soft reset

John — Wed, 20 Jan 2016 16:34:12 GMT

Why not stash the RTC in the POWER->GPREGRET register which is designed to survive reset prior to resetting? As long as you don't need to be hyper accurate the time to reset and return to running state shouldn't affect your absolute time that much.

RE: Retain RTC during soft reset

braucadr — Wed, 20 Jan 2016 14:59:04 GMT

Ok, got it. I call the MBR Reset Handler with

typedef void resetHandler_t(void);
resetHandler_t* mbrResetHandler = (resetHandler_t*)*(uint32_t*)0x04;
mbrResetHandler();

It seems to work as it runs thru the application Reset Handler after a while. But again, the first call of sd_nvic_critical_region_enter(0) fails, this time with a hard fault error.

I'm still confused with the stack pointer. Is it properly initialized without an actual reset?

RE: Retain RTC during soft reset

Martijn — Wed, 20 Jan 2016 11:11:54 GMT

The cortex-m0 core only uses the vector table placed at address 0x0. but there a multiple vector tables when you use a softdevice. The MBR has a vector table @ address 0x0. The softdevice has a vector table right after the MBR and the application has a vector table right after the softdevice. The MBR simply looks through the vector tables of the softdevice and application and jumps to the correct address.

When you call Reset_Handler() in you application you jump the Reset_Handler in you application space and skip the MBR version and softdevice version.

RE: Retain RTC during soft reset

braucadr — Wed, 20 Jan 2016 10:35:09 GMT

In startup_nrf51x.c I have:

void * g_pfnVectors[0x30] __attribute__ ((section (".isr_vector"))) = 
{
	&_estack,
	&Reset_Handler,
	&NMI_Handler,
	&HardFault_Handler,
	NULL,
	NULL,
	...,
...
}

Doesn't this mean that reset_handler address of the MBR(located at address 0x4) is exactly what I call with Reset_Handler()? I think the isr_vector is placed at address 0x00 with alignment 0x04 as described in the Cortex M0 Manual

I don't see the Stack being initialized. Do I maybe also have to reset the SP manually as it is normally done by the reset?

RE: Retain RTC during soft reset

Martijn — Wed, 20 Jan 2016 08:47:56 GMT

Ah, you call the reset handler of you application, which calls the reset handler of the application and resets the ram content of the application.

But it skips the reset_handler of the mbr and softdevice, so the softdevice ram content is still corrupted. I don't know whether this is possible, but maybe you can set the Reset_Handler pending via NVIC? or maybe you can get the reset_handler address of the MBR(located at address 0x4) and call that so the full chain of MBR -> softdevice -> application reset handlers is called without a reset.

RE: Retain RTC during soft reset

braucadr — Wed, 20 Jan 2016 08:40:52 GMT

Hi Martijn, thanks for your comment. I replaced NVIC_SystemReset() with Reset_Handler() and it basically works. But the first call of sd_nvic_critical_region_enter(0) after the "reset" crashes with the SIGTRAP signal. Could it be that the SVC_Handler is somehow corrupted after the Reset_Handler() call?

RE: Retain RTC during soft reset

Martijn — Tue, 19 Jan 2016 20:49:45 GMT

I think you don't need a reset, but you need the behavior of the reset handler. I think you can just call it right after you enabled the ram again. This will reinitialise the ram content, but keep the rtc running.