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: SEU analysis/statistics for TMS570LS3137TMEP

Part Number: TMS570LS3137
Other Parts Discussed in Thread: TMS570LC4357-SEP

Hi,

Since we are dealing safety critical systems, we were asked to provide SEE upset rate for the part TMS570LS3137TMEP.

One recent thread says it is not available for this part.

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1323101/tms570ls3137-hercules-mcu-seu-mbu-analysis

And there is an old thread that says TI can share based on NDA

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/90468/tms570-avionics-seu-statistics

Could anyone give some clarity or information on this.

Thanks,

Jaiganesh

  • Jaiganesh,

    The consequences of SEU include temporary data loss in memories and transistor latch-up, etc. The errors associated with SEU do not cause system destruction and they can be recovered by rewriting the data. The memory (flash, RAM) on TMS570 is protected by ECC for single bit upsets. Bit multiplexing or bit interleaving where bits in the same logical word are physically separated is employed to minimize multibit errors in the same word.

        <-- Device Safety Manual

    We don't SEU report for TMS570LS3137 device. But we have SEU test report for TMS570LC4357-SEP BGA package

    https://www.ti.com/lit/an/spna249/spna249.pdf?ts=1711043400769&ref_url=https%253A%252F%252Fwww.ti.com%252Fsitesearch%252Fen-us%252Fdocs%252Funiversalsearch.tsp%253FlangPref%253Den-US%2526searchTerm%253DSEU+AND+TMS570%2526nr%253D11

  • Hi Wang,

    Thanks for your response. Could you please elaborate on '...they can be recovered by rewriting the data'. Does ECC module take care of rewriting the data or  software needs to rewrite the data into SRAM periodically by having backup copies and how do we handle it in case of FLASH data (actually code).

    Thanks,

    Jai

  • Hi Jaiganesh,

    1-bit error on SRAM will be detected and corrected, and the corrected data will be written back to SRAM. 

    1-bit error on flash will be detected and corrected, but the corrected data will not be written back to Flash.

  • Hi Wang,

    In our project, the code is mostly executing out of flash memory. If the corrected data will not be written back to FLASH, how does the code in FLASH memory execute correctly.  When we say it is 'corrected', where exactly the correction of 1-bit is happening in case of FLASH memory. 

    If it is not written back in FLASH memory, in case of power recycle, what happens to the FLASH code that was affected in previous cycle. We have a CRC check on the code as part of BIT. Will this CRC check fail as the affected bit was not corrected back in FLASH.

    Could you please provide more insights. 

    Thanks,

    Jai

  • HI Jai,

    There are two 128-bit instruction buffers and two 128-bit data buffers in flash wrapper. A total of eight 32-bit instructions and eight 32-bit data can be stored in the buffers at the same time.

    The Flash wrapper contains an embedded SECDED (Single Error Correction and Double Error Detection) circuit. SECDED when enabled provides capability to screen out memory faults and correct the fault. SECDED requires a total of eight ECC check bits associated with each 64 bit wide data word and its corresponding address. During read operation, the 19 address bits together with the 64-bit data read out of flash banks pass through the ECC check bit generator to produce the 8 check bits. These eight calculated ECC check bits are then XORed with the stored check bits associated with the address and the read data.

    The corrected instruction and data are stored in the instruction buffers and data buffers in flash wrapper. CPU reads instruction and data from those buffers.

  • Hi Wang,

    If I understand it correctly, the corrupted instruction in FLASH memory remains as it is and whenever this instruction is read by FLASH wrapper, it gets corrected before storing it in instruction buffer for CPU to read.

    If so, after a power recycle, the corrupted FLASH code may fail CRC check(implemented as part of PBIT). Is my understanding right?

    Thanks,

    Jai

  • Hi Jai,

    Your understanding is correct. You still get the correct CRC since the 1-bit error is corrected during reading.

  • My bad. I missed that 'You still get the correct CRC since the 1-bit error is corrected during reading'. 

    Thanks Wang.