DMAMEM / RAM2 and detecting first boot after power on alternatively detecting warmboot

[KurtE]

Sorry, I know that it is probably better not to jump in here. But I keep wondering, are you are you trying the different things for some specific hardware/software thing you are trying to build, or is this more a research project and the goal is to write a report?...

Can you point me to where it is documented in the SDK and what SDK do you mean?

Hint: he pointed you to some specific address: 0x400D4100
If you look at the imxrt.h file for that address or one near it you find:

#define IMXRT_SNVS_ADDRESS        0x400D4000

So a good place to look is chapter 20 in the Reference Manual. You will then see offset 0x100 from there is:

20.6.1.17 SNVS_LP General Purpose Registers 0 .. 7 (LPGPR0 -
LPGPR7)

I find the assumption that all values are equally likely dubious. Values read shortly after a reset might indeed be a lot closer to the initial value being stored or not. Given variation between chips and so on it might end up happening that those particular RAM cells are a lot more stable.

Have you tried it? If it were me, I would probably set multiple words, potentially not contiguous and see what happens. run a simple test like 1000 times and see if you ever do not detect if it is warm or cold.

If none of these solutions is sufficient. I would probably hook up some hardware, test setup. For example, a real simple processor, which has its own power supply. With one IO pin of it hooked up to maybe 3.3v pin of the teensy. So if it knows when or when not the teensy is powered up....
Then hook up some protocol between the two processors. Could be simple one IO pin, where maybe the Teensy pulls it high at startup, and the other one responds with a blink pattern. One blink: cold, two blinks warm... Could be UART. Teensy sends a message saying I am alive. The other processor could respond with this is a Cold start, or a count of how many warm starts or ...

But if it were me, I would start off with the KISS solution of setting multiple bytes high up in DMAMEM...

Good luck

 

[defragster]

Can you point me to where it is documented

Forum search "0x400D4100" should find only known context. The old forum thread will show the 'Enable' was a mystery to locate for some time

Is the value of the NVRAM defined on first boot?

NVRAM is a local variable pointer to the indicated fixed address. IIRC that area can be read, but not usably written until the indicated Enable is done.

Indeed, COLD Start RAM2 values not likely Random - but will hold some non-specific value that may or may not be constrained.
For years on prior T_3.x family PJRC put a known magic value in NVRAM (1 of 8) to know if the RTC value had been set from prior 'warm start'. Similar magic# was done with the CrashReport use of RAM2 - but not a single value - but 128 byte area and 4 byte checksum of the other 124 bytes to be sure it was relevant.

 

[defragster]

But if it were me

Odd - thread refresh showed quoted @Schaeg reply but not this from @KurtE

PJRC's CrashReport usage of a cache line of 128 bytes is well tested - under Crash conditions for years. A clone/copy of that code just 128 bytes below that used address should be able to replicate any needed portion of that code and Job Done to see Warm start maintained or Cold start lost as PJRC does on each MCU Reset since the 1062 products were released with that code working.

Using NVRAM less complex - given a reportedly simpler need - and could likely use 1 or 2 of those DWORDS for a trusted solution. Not sure if those NVRAM values are set ZERO on cold start - but RAM2 is not.

Test Code can run and then 'reset' for Warm start and it can also trigger an 'OFF' state IIRC. A second Teensy could monitor - or a button on Off/On could bring a cold start with <1 second GND. A SerMon - like TyComm stays connected for some 10(?) seconds after Teensy goes missing where USB output is additively maintained.

 

[KurtE]

Odd - thread refresh showed quoted @Schaeg reply but not this from @KurtE

As I mentioned I would KISS, maybe something like:

uint32_t *reboot_counter = (uint32_t *)0x2027FF00
if (strcmp((char *)0x2027FF04, "Mary Had A Little Lamb") != 0) {
   // Cold boot.
   strcpy((char *)0x2027FF04, "Mary Had A Little Lamb");
   *reboot_counter = 0;
} else {
    *reboot_counter = *reboot_counter + 1;
}
arm_dcache_flush((void *)reboot_counter, 32);

Note: Typed in on the fly. So could have typos...
And see if it ever fails...
Edit: String pointer should not be const...

 

[jmarsh]

PJRC's CrashReport usage of a cache line of 128 bytes is well tested

Cache lines are 32 bytes.

 

[defragster]

Cache lines are 32 bytes.

Indeed, they are. Mistaken/forgotten on the flush units Bytes not DWords - and confused the 'location' 128 comment in code

 

[Schaeg]

I found a bug in this when testing. I did only flush inside the if which led to wrong counts. This code seems to satisfy my needs so far. I confirmed it works with both watchdogs and software triggered interrupts (REQUEST_EXTERNAL_RESET (AIRCR=(AIRCR&VECTKEY_MASK)|VECTKEY|SYSRESETREQ)) and counts them as warm reboots.

static uint32_t DMAMEM warm_bootcount;


void setup()   {
    warm_bootcount += 1;
    if((SRC_SRSR & 1) == 1){ // check power on flag // used bitwise and here
      warm_bootcount = 0;
      SRC_SRSR = 1; // clear power on flag
    }
    arm_dcache_flush(&warm_bootcount, sizeof(warm_bootcount));
    initProgram();
};