Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN
Tool/software:
Team,
Question about TMS570LC4357 using the HalCoGen API/drivers.
A customer could successfully use the two below features separately:
Core Idle / Wakeup: core inactive waiting for an interrupt to wake up the core (this saves power whilst the core is suspended)
Flash Sleep / Active: flash wrapper sleeping and then (re)activating (this saves power whilst the flash is asleep)
However they are seeing issues when putting it together in the final application (a more detailed description is available below).
-Do we have some procedures or guidelines about using both features together?
-Any tips that could help debug or analyze the behavior?
-See as well customer question below.
Thanks in advance!
Anthony
Below is a brief explanation of the difficulties we face:
Two features that do not seem to work well in combination but in principle should
a) Core Idle / Wakeup: core inactive waiting for an interrupt to wake up the core (this saves power whilst the core is suspended)
b) Flash Sleep / Active: flash wrapper sleeping and then (re)activating (this saves power whilst the flash is asleep)
These features have been demonstrated to work both independently and in combination in an isolated example program (especially when a delay awaiting flash readiness was introduced to the latter).
BUT
When highly similar code is integrated into our fin outline program the overall functionality breaks down once feature b) is added to feature a) resulting in combinations of pre-fetch aborts, data aborts, or missing wakeup (RTICOMP0 interrupt) and /or ESM nERROR just after the WFI (Wait For Interrupt instruction).
These individual outcomes are in themselves very repeatable but vary dramatically in outcome when relatively trivial changes are made to the related code. It should be noted that use of the debugger to investigate may be further confusing the issue.
This subject area is not well described (especially Flash Sleep / Active). In principle examples exist for other members of the Hercules family but not this device which might indicate an underlying problem or constraint (?).
For us this these features, especially in combination, would seem to provide the most significant power saving across all options available.
What has to be done to ensure that these two features will operate successfully and in combination on the TMS570LC4357 under all conditions?
It appears that a potential cause for a pre-fetch abort is an unexpected invocation of the HALCoGen::esmHighInterrupt() (which as it happens is not loaded into RAM).
Regardless this is still very weird since analysis of the registers at this time shows that ESM::ESMIOFFHR register contains 0x31 which translates to a Group 2 Channel 16 error which according to the Data Sheet (page 132) is Reserved i.e. an unexpected error!*?
This cascade of errors and their effects seem to be blocking the simultaneous handling of the RTI (which is also registered in the VIM::INTREQ0 register) and thus the chain of events that could lead in this instance to wake up from the WFI and recovery.
