We have some data tagged with #pragma PERSISTENT in Hercules code. It seems like this was copied from the way its done in the WD. However, unlike the MSP430, this doesn't actually give persistent since there's no FRAM for that memory section to be allocated to. As a result, testing shows this data doesn't survive a power reset. That said, it seems like the noinit behavior of #pragma PERSISTENT works so the data might persist through a powered-on reset. More testing would be required...
[ ] Fix this by allocating the data to non-volatile memory like F021 (not easy). See resource
Helpful forum questions (topic is bootloaders but addresses linker memory allocation):
[ ] Store data in the FS of one of the Flash chips connected to Hercules (make sure this doesn't collide with how Camera does or CommandDispatcher would use that space).
[ ] Or... since none of this is critical just store this data in another chip like a database and query to retrieve it (Radio PS or WD persistence).
[ ] Or... just ignore it. None of Hercules' persistent data is mission-critical. This is likely not worth the time.
NOTE: A fix for this isn't very important. This Issue is mainly just for documentation of a non-conformance.
We have some data tagged with
#pragma PERSISTENTin Hercules code. It seems like this was copied from the way its done in the WD. However, unlike the MSP430, this doesn't actually give persistent since there's no FRAM for that memory section to be allocated to. As a result, testing shows this data doesn't survive a power reset. That said, it seems like thenoinitbehavior of#pragma PERSISTENTworks so the data might persist through a powered-on reset. More testing would be required...Cameradoes orCommandDispatcherwould use that space).NOTE: A fix for this isn't very important. This Issue is mainly just for documentation of a non-conformance.