TMS570LS3137: Hercules PBIST configuration

Hello Jim,

1. Those registers are not published in the TRM and datasheet. I will check if we will add those information to the TRM in next release.

2. To run wrong algorithm on selected memory will generate an error: FSRF0=1. The FSRF0 is a read only register, and wrong code will not affect the value in FSRF0.

Regards,

QJ

QJ,

Is it possible for you to send me a snippet of the upcoming TRM or any documentation detailing this code? We are using this code in a DO178 (FAA) compliant program, so ALL code must be derived from software requirements. I expect this code is performing an important self-test function, but if I don't have any documentation to support this code, I have to delete it.

Thanks,

Jim

Jim,

We don't have plan to publish those information, those information are internal use only. Actually you don't need those registers to enable PBIST self test. The PBIST self test API in safeTI library doesn't use those information.

SL_SelfTest_PBIST(...)

Regards,
QJ

QJ,
If I ifdef-out those writes to addresses FFFFE400-E458, then the processor does not boot, so at least some of those writes are necessary to run the PBIST self-test. Can you give me "anything" to define that code operation? Otherwise as I wrote, if I have zero documentation, I will have to delete all of this PBIST self-test, and it seems like it is performing an important function.

Thanks,
Jim

Hi Jim,

pbistSelfCheck() generated by HALCoGen uses custom algorithm which will make the PBIST fail to ensure that PBIST is capable of detecting and indicating a memory self-test failure. The reserved register (pbistREG->rsvd1[1U]  = 1U;) is to run the custom algorithm. The custom algorithm is defined by the lines just above the line "pbistREG->rsvd1[1U]    = 1U";

We do not want customers to write to the "RSVD" registers because there is lot of chances for user to make error with custom algo and make the device memory test to produce erroneous result. 

You could also do pbist Self Check by simply choosing wrong memory against wrong algorithm. i.e you can select a single port Memory and choose a dual port Test algorithm ( basically not follow PBIST RAM Grouping Table in datasheet). I will modify the code for you as reference.

Regards,

QJ

Thanks QJ; I will have to exclude that pbistSelfCheck code from my project, because I cannot have undocumented code.

Jim

Hello Jim,

As mentioned by QJ, the code in question is used to generate a failure in PBIST so that the error notification path can be validated. understand the concerns with the undocumented registers and use in your DOxxx class application. As QJ mentioned, the same task can be accomplished with documented registers and ROM based algorithms by running a ROM algorithm on a single or dual port RAM block or vise versa running a single or dual port RAM algo on a ROM block. Either will generate a PBIST fault resulting in a fault that can then be used to validate the error notification path. No matter how it is done, this is a key step in the functional safety story for Hercules devices and should not be skipped.

Chuck or QJ,
I think I understand, but how do I invoke an error on a good memory block? I am already running some of the canned algorithms on all used RAM, and all tests pass. I thought maybe I could run one of these RAM tests on a Flash-block, but the pbistREG interface only specifies the RAM group to perform the test on.
Thanks,
Jim

Hi Jim,

There is also the possibility to choose a ROM block which is where the algo information is stored. You can select this block and run the March13N algo on it (same as with RAM). It will return an error which will then exercise the fault notification path as required. There is no option to select a Flash block as you have noted.

Chuck,
I tried running the MARCH13N test on the PBIST ROM block as you suggest, and the new code causes my debugger to detach (A bunch of IcePick and JTAG errors I could send you if you want); however the code will run outside the debugger, but I cannot verify (with this Hercules Dev board) that it is properly doing what it is supposed to. Are there any tricks, or must I prepare the CPU (write to some special register) in order to do this?
Thanks,
Jim

Hi Jim,
Can you send me the exact configuration/setup of your PBIST run so I can have a look. It shouldn't cause a debugger disconnect like that. It sounds like it caused a device reset of some sort.

Chuck,

I un-if-def-ed the code in question, and now it works; hopefully it does not come back to haunt me later. Thanks again for your help,

Jim

Jim,

If this causes you any grief during your assessment/audits, please let me know by sending a private message. I can either join the discussion or see if I can push this and provide some NDA material that provides the documentation of the registers that aren't included in the TRM.