TM4C1294NCPDT: How to tell the difference between cold or warm reboot?

David Chance said:

I think a ideal solution will be a register that always comes up with known state from cold boot but its content will not change in warm reboot

Is there an good memory location I can pass some info between reboot? so that the software can continue some tasks started before software reset

Earlier you have some doubt on the EEprom life cycle? EEprom would have been the best choice for you. How often do you need to perform cold reboot in your application?

The EEprom is specified for 500k write cycles.

David Chance said:

Is there an good memory location I can pass some info between reboot? so that the software can continue some tasks started before software reset

If you are not losing power then just reserve an area of RAM that will not be overwritten.

If you want to preserve information across power loss, particularly if that is not at a controlled point, then add an external FRAM. Even external EE isn't really fast enough and the internal  'EE' has abysmal timing.

Robert

I got nervous when I was shown this errata

www.ti.com/.../spmz850g.pdf

See my previous question e2e.ti.com/.../2435253

Maybe we can have some clarifications from TI?

David Chance said:

I tried to avoid external parts due to the cost.

Actually I doubt it costs more. You have to add a hold-up supply to use an EE. Given the abysmal worst case timing for the emulated EE on the TI part that's not an inconsiderable consideration.

David Chance said:

If the EEPROM can indeed last for 500K r/w, I will use it

Interestingly if you get more writes, the approach to the problem becomes much simpler.

David Chance said:

btw, how do you reserve an area of RAM in CCS?

No idea, read the link and locate documentation for the compiler.  There's usually a set of options that control the memory map.

Robert

David Chance said:

What happens if the EEPROM is corrupted due to interruption? Will it become useless? or I can simply reprogram it?

Charles Tsai said:

. But also note that in the event of a power loss or reset while writing to the external device, the data is either loss, corrupted or incomplete.

That's the reason for suggesting an FRAM. The orders of magnitude increase in write speed makes it much easier to prevent this eventuality.

Robert

David Chance said:

btw, how do you reserve an area of RAM in CCS? it may be useful in the future application

Refer to the #pragma SET_DATA_SECTION usage in the TI ARM compiler user's guide. Once you define the section, you can map that section to the RAM at certain address if you want in the linker command file. 

David Chance said:

Thanks for the warning regarding EE corruption, I will consider FRAM in this case

The big issue here is interruption during the write, particularly power-down. That's worth avoiding in any case. Usually that results in local corruption (or an entry that doesn't stay programmed) but since EE programming is a long stateful process it sometimes confuses the state machine if you power off during writes. Mirrors and checksums still reduce the errors with EE

For external FRAM the process would be something like

• On Change
  1. Check to see if you have enough power to write
  2. Unprotect the memory
  3. Write
  4. Protect the memory

FRAM has unlimited write cycles so you can write every change and is fast enough that you do not ever need to check for write complete. As a result of the latter the power supply only needs to be sufficient to stay up long enough to perform the write protect, maybe a few uS.

For EE the process would be

• Accumulate change
• On power down (or every N seconds)
  • Unprotect the memory
  • Write
  • Wait for write to finish
  • Protect the memory

EEs have limited write cycles so you cannot write frequently. In addition since the write cycles are long you have to add code to wait for the write to complete and the power supply must stay up long enough to complete the write protect. This adds quite a bit to the cost of the power supply. Even external EE requires something like 5mS worst case write time, the TI emulation is 30mS nominal and 1.8s (yes seconds) for worst case high usage. TI doesn't give worst case for fresh usage, you could plan on double or triple nominal and hope you don't wear out but any truly safe design must plan on 1.8s per write for the hold-up.

Robert

Thanks for your suggestion!