Hi Alvaro,

I’d recommend a new API in HAL. One where register contents will
survive reset, depending on the type of reset.

Have #define HAL_RETAIN_REG_MAX  XXX
in some MCU specific header file. And then in hal/hal_retain_reg.h

#ifnfdef HAL_RETAIN_REG_MAX
#define HAL_RETAIN_REG_MAX 0
#endif

void hal_retain_reg_write(unsigned int reg, uint32_t val);
uint32_t hal_retain_reg_read(unsigned int reg);

HAL_RETAIN_REG_MAX would presumably be 2 for nrf52, and a little bit
higher for STMs. For platforms which don’t have peripheral supporting
this kind of storage, you can carve out space from RAM by reserving
the space within linker script.

hal_retain is a bit long as a prefix, though :)

> On Apr 3, 2018, at 6:36 PM, Alvaro Prieto <[email protected]> wrote:
> 
> Hello,
> 
> My name is Alvaro. I'm a firmware/hardware engineer and I've been playing
> with mynewt at home and at work for a few months now. I mostly hang out in
> the mynewt slack, but I've been advised to come here for hal and other
> source change discussions.
> 
> The one today has to deal with a hal friendly way to access retained
> registers. By that, I mean registers that survive a soft reset.
> (NRF_POWER->GPREGRET on the NRF series).
> My question is: How do we implement this?
> 
> For background, my goal is to enter the serial bootloader without
> necessarily using the boot pin, so:
> 1. Set magic value in retained register
> 2. Call NVIC_SystemReset()
> 3. Bootloader sees magic value, clears it, and enters bootloader
> 
> While this is easy to do by just writing to the NRF_POWER->GPREGRET
> register, it doesn't really for for any other platforms. The STM series has
> the RTC backup registers, but other platforms might not support it.
> 
> Should I add retain register read/write functions to hal_system or should I
> add a new hal_retained_reg.
> 
> Looking forward to getting this working :D
> 
> Cheers,
> 
> Alvaro

Reply via email to