RM48L530: How to keep RAM data after PBIST and memoryInit

Chris Smith29

Part Number: RM48L530
Other Parts Discussed in Thread: HALCOGEN

Our application uses the Halcogen generated selftests (run in sys_startup.c). Among these tests are the PBIST test, followed by a memoryInit. Unfortunately we have defined sections in the _no_init sections of the RAM that holds information required by the application which is lost due to these tests.

So typically the sequence would be:

1. Application detects some Fatal program error trapped by some exception handler

2. Error data is stored in _no_init RAM section

3. A software reset is generated

4. Application starts selftests (PBIST and memoryInit)

5. Application examines cause of exception by reading RAM and then reporting to the user.

The problem is that step 4 destroys our error info in the RAM. A revised approach would be:

1. Application detects some Fatal program error trapped by some exception handler

2. Error data is stored in _no_init RAM section

3. A software reset is generated

4. Application Backs up the RAM section with error info somewhere

5. Application starts selftests (PBIST and memoryInit)

6. Application restores the RAM section from the backed up version.

7. Application examines cause of exception by reading RAM and then reporting to the user.

So what are my options for a temporary backup area? I know I can use flash eeprom, but am having troubles.

I read somewhere that someone wanted to use one of the Perhipheral RAM, Is this possible?

over 5 years ago

0 QJ Wang over 5 years ago

TI__Guru**** 186336 points

Hello Chris,

You can use either EEPROM or any peripheral RAM (for example CAN RAM if this CAN is not used in your application).

0 Chris Smith29 over 5 years ago in reply to QJ Wang

Prodigy 70 points

We are using CAN1 but not CAN2 & CAN3.

Do you have any example code to store an array of bytes from normal RAM to CAN RAM?

Chris

0 QJ Wang over 5 years ago in reply to Chris Smith29

TI__Guru**** 186336 points

Hello Chris,

I did a simple test with CAN RAM before. I am not sure if I have this simple project available. Will check and let you know.

0 Sunil Oak over 5 years ago

TI__Mastermind 49120 points

Chris,

PBIST is fully software controlled. That is, it is executed only when the application initiates it.

Do you have any other conditions in your application where you cause a software reset? If so, then is there anything in your system that can tell you that the last software reset was caused by a fatal error in the system? The reset handler needs to be able to identify this. Then you don't need to store back the critical RAM contents and start PBIST and memory init, just directly examine the cause of the error and report to the user.

Regards, Sunil

0 Chris Smith29 over 5 years ago in reply to Sunil Oak

Prodigy 70 points

Hi Sunil,

Unfortunately we are strictly bound in some cases of errors to cause a reset of the application.The OS (sciopta) we are using will fall into its error hook if it detects something like a stack overflow or data abort. This we cannot change. In this case the only recovery is via reset of the CPU and thus we need to do all the startup selftests again including PBIST as determined by the FMEDA for our safety certification.

Typically errors in software would include code paths that should never happen under any normal circumstance (like a unknown case in a switch statement), these would also cause a reset by the exception handler in our application (again required by our FMEDA).

In all cases we have to report that a reset took place and the reason (error position number in the code) in a post mortem fasion (ie after the system has recovered to a known state).

So you see that the error position and reset cause must be kept somewhere during the PBIST and memoryInit of the main RAM, and then restored afterwards.

Regards

Chris

0 QJ Wang over 5 years ago in reply to Chris Smith29

TI__Guru**** 186336 points

Hi Chris,

If you want to use CAN2 RAM to restore data, it is fine. CAN2 RAM starts at 0xff1c0000.

To direct access the CAN RAM:

1. CAN module has to be in TEST mode

2. The RDA bit in Test Register has to be set:

canInit();

canREG2->CTL |= (1 << 7);

canREG2->TEST |= (1 << 9);

for (i=0; i<100; i++){

*ptr = 0x5a5a0000 + i;

ptr++;

}

Notice: Writes to Reserved bits have no effect. (upper 16-bit of 0x10, all bits of 0x14/0x18/0x1C/0x34/0x38/0x3c/... can not be used)

In the picture below, the crossed area are reserved.

Arm-based microcontrollers

Arm-based microcontrollers forum

RM48L530: How to keep RAM data after PBIST and memoryInit