You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Alvaro Prieto <al...@verily.com> on 2018/04/03 15:36:11 UTC

Retained Register Interface (also, hi!)

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

Re: Retained Register Interface (also, hi!)

Posted by Alvaro Prieto <al...@verily.com>.
Here's my first attempt at it:
https://github.com/apache/mynewt-core/pull/996

On Tue, Apr 3, 2018 at 1:49 PM, Alvaro Prieto <al...@verily.com>
wrote:

> I like that idea. I'll start implementing for the NRF with something like
> that, we can come up with the name in the meantime.
>
> How about something with nonvolatile like hal_nvreg? I guess they are
> volatile with a hard reset though...
>
> Alvaro
>
> On Tue, Apr 3, 2018 at 11:59 AM, marko kiiskila <ma...@runtime.io> wrote:
>
>> 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 <al...@verily.com>
>> 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
>>
>>
>

Re: Retained Register Interface (also, hi!)

Posted by Alvaro Prieto <al...@verily.com>.
I like that idea. I'll start implementing for the NRF with something like
that, we can come up with the name in the meantime.

How about something with nonvolatile like hal_nvreg? I guess they are
volatile with a hard reset though...

Alvaro

On Tue, Apr 3, 2018 at 11:59 AM, marko kiiskila <ma...@runtime.io> wrote:

> 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 <al...@verily.com>
> 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
>
>

Re: Retained Register Interface (also, hi!)

Posted by marko kiiskila <ma...@runtime.io>.
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 <al...@verily.com> 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