This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LS3137 (rev B) ESMSR3 bit7 - "FMC uncorrectable error"

Other Parts Discussed in Thread: NOWECC

Dear friends,

Recently we started enabling flash ECC in our app.  (That was its own adventure, but never mind that here.)  This mostly seems to work.

Possibly related, possibly not, I discovered that, while running our app some time after boot, ESMSR3 bit 7 gets set and the nERROR pin becomes active.  However, the processor continues executing and everything is otherwise fine.  The data sheet labels this ESR channel as "FMC - uncorrectable error: bus1 and bus2 interfaces (does not include address parity error and errors on accesses to EEPROM bank)".

I am quite surprised, because this is a Group3 channel.  It had been my impression that any activity on a Group3 channel would immediately trigger a processor abort.  The "Reset / Abort / Error Sources" table in the data sheet implies that "Bus1" uncorrectable flash errors result in "Abort (CPU), ESM => nError", but "Bus2" uncorrectable flash errors result in just "ESM => nError".

This further surprises me because while I knew there were two SRAM buses, I didn't realize there were two flash buses.  What's the difference between them?  If I want all uncorrectable flash ECC errors to result in a fault, what should I do?  Since it's a Group3 ESM channel, there are no control registers for its behavior (originally I thought that's because they all create an immediate CPU abort, but apparently not).  Meanwhile I am _not_ seeing any errors logged in the flash error registers... but of course, there's the possibility that I'm Doing It Wrong(tm).

To recap, my questions are:

- Is it true that some Group3 ESM errors are non-aborting?  If so, how should I catch them?

- What is the difference between "bus1" and "bus2" of the main flash memory?

- Why would uncorrectable flash ECC errors that set an ESM channel not show up in the flash error capture registers?

More details available on request, if it helps.  Thanks!

-- egnor

  • Egnor,

    I believe that you did not program the entire Flash memory. The ECC error is generated when CPU accesses the the unprogrammed region via speculative fetch. The error will go away if you program the entire flash with ECC.

    Cortex-R4 CPU uses "speculative fetch" to prefetch data in order to minimize the memory access bottleneck. Occasionally, this speculative reads from memory which is not defined by the application. When his happens, the prefetched data will discarded by CPU later. Therefore, CPU does not enter abort although it reports the error when the data is prefetched if ECC is not programmed correctly for this data.

    Hope the above answers your question.

    Thanks and regards,

    Zhaohong

  • That makes total sense, and in fact there's even a paragraph in the TR about this issue:

    "The ECC values for all of the ATCM program memory space (flash banks 0 through 6) must be programmed into the flash before SECDED is enabled. This can be done by generating the correct values of the ECC with an external tool such as nowECC or may be generated by the programming tool. The Cortex R4 CPU may generate speculative fetches to any location within the ATCM memory space. A speculative fetch to a location with invalid ECC, which is subsequently not used, will not create an abort, but will set the ESM flags for a correctable or uncorrectable error. An uncorrectable error will unconditionally cause the nERROR pin to toggle low. Therefore care must be taken to generate the correct ECC for the entire ATCM space including the holes between sections and any unused or blank flash areas."

    Thanks!