TMS570LC4357: To which address corresponds each RGS:RDS of TMS570LC?

Etienne,

There's really not enough information here for you to do anything useful in my opinion other than to flag pass/fail status.

The RGS and RDS refer to physical instances of memory arrays, and I don't think we give you the physical to logical mapping so even if you know which group and which array returned data (RDS); you still don't know the CPU address which is what you are after if you are trying to do anything more than a pass/fail.

Also with FSRA0 - knowing "the memory address of the first failure on port 0" without knowing the order in which the test program in PBIST accesses the memory doesn't really tell you anything about the other addresses in the array. For example, what if the test is accessing the RAM randomly?

Sorry I think all you can get out of this is a pass/fail ...

That's unfortunate. Our case is that we'll only use about 50% of the RAM and we would like to probability of a BIST failure by disregarding latent failures related to parts of the RAM which we do not use... Otherwise we'll fail the whole system for a RAM failure which in fact wouldn't have affected it.

Hi Etienne,

We need to work with what's documented though and I don't see any possibility given the available information to do anything more via PBIST() than red light/green light. You could implement some sort of secondary check on your own but then you need to ask if you really want to continue operating with a 'wounded' MCU.

RAM group 29 is the first 128KB of RAM (0x08000000 - 0x0801FFFF), RAM group 30 is the next 384KB of RAM (0x08020000 - 0x807FFFF). Not exactly what you asked for, but maybe it helps.

Thank you: I reached that fact as an hypothesis when I analyzed the TRM, and you just confirmed that :)

Does that mean that the RAM ECC memory is not testable with the PBIST module?

The ECC bits are tested by PBIST. It treats the memory as 72-bit wide instead of 64-bit wide.

Hello Etienne,

I have some good news and some not so good news based on my research into this issue. First, the first address failure is sequential within the group under test noting that RGS and RDS will also be sequential corresponding to the 64 bit word located at the address.

The not so good news is from our team that does our return analysis of failures. They state that even a single failure in an unused portion of SRAM can indicate some greater issue such as a failure of the sense amp used across multiple bit cells or some other physical failure within the die itself.  They noted that even a failure in the unused portion of the SRAM might be indicative of a weakness within the SRAM that could also impact addresses that may not be adjacent or within the same address range. As such, TI recommends using the full capability of the PBIST to test the entire SRAM block and to consider the element in its entirety as pass/fail as Anthony has suggested before. Also note that the although there is some reduction in probability of  permanent failure by considering only half the SRAM, this reduction is very small compared to the risks of not invalidating the entire SRAM based on the results.

One could, however, consider that a transient fault could be in play. i.e., if a fault occurs, you could re-initiate PBIST and run multiple times to assure that the original results were soft error related.

Also, you may still consider that only the lower half of SRAM is used from an in application point of view in the FMEDA given PBIST is executed at startup and is primarily focused on latent faults and the upper half is not used for any safety functions (assuming you are using the MPU to protect accesses outside the defined range of the application). This should allow you to still maintain appropriate reductions in FIT rates given the reduced SRAM size. Note that we can discuss this aspect more on the private forum should you have questions.

Hopefully you find this information helpful. Let me know if there are further questions.