TMS570LC4357: NoInit RAM Memory Issue for Bootloader + Application Projects

Alex Lee

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN,

Tool/software: HalcoGen, CCS

Hi TI Support,

We have used TMS570LC4357 for our project development and configured both Bootloader Image + Application Software Image inside the TMS570 Flash Memory. We are also trying to configure a 512-byte non-init RAM inside the flash using HalcoGen such that we can keep some debug parameters inside the Non-init memory during power lost or unexpected reset.

We are following another TI user example TMS570LC4357: No init memory on reset for storing reset information step by step.

Before we implement the Non-init RAM feature, the software always run correctly: After reset or power on, SW goes to bootloader first then jumps to application software.

After implemented the above Non-Init RAM, we encountered some issues:

- When we use TI Debug XDS110 probe the SW reset reason can be saved and displayed correctly.

- However, if we power off and then power on, the software is hanging there, neither enters bootloader nor the normal application.

- If we press the TRST reset button, there is still no any response and software still hanging.

- If we press the PORRST reset button, then the software can restart correctly.

- If we do power cycle again, the issue comes back again

In order to make the bootloader and Application keep the same Non-init RAM, we enable the MPU for bootloader as well. Application Software has enabled MPU region 15 for this non-init RAM, Bootloader follows the same setting + Region 2 & 3 permissions changed

May I know what is the reason for this? I have attached our codes screenshots for your reference and debugging:

NonInitRAM-fail.zip

3 months ago

0 jagadish gundavarapu 3 months ago

TI__Guru 74106 points

Hi Alex Lee,

Alex Lee said:
- However, if we power off and then power on, the software is hanging there, neither enters bootloader nor the normal application.

Where exactly core is stucking, i mean in which API or instruction?

(+) TMS570LC4357: TMS570LC4357 - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

Refer above thread once, here i explained method to point out where exactly code got stuck after resetting and without disturbing current execution.

Alex Lee said:
After implemented the above Non-Init RAM, we encountered some issues:

Are you using this area in application or bootloader yet?

--
Thanks & regards,
Jagadish.

0 Alex Lee 3 months ago in reply to jagadish gundavarapu

Prodigy 70 points

jagadish gundavarapu said:
Where exactly core is stucking, i mean in which API or instruction?

We cannot identify which core is stucking, as the debugger is removed. Even we connect the debugger, after power off and power on reset, the debugger session will be lost and we cannot trace back which API got stuck.

jagadish gundavarapu said:
Are you using this area in application or bootloader yet?

To keep consistency, we initialize the same byte array in bootloader and application software, but we only operate the byte array in application software

0 jagadish gundavarapu 3 months ago in reply to Alex Lee

TI__Guru 74106 points

Hi Alex,

Alex Lee said:
We cannot identify which core is stucking, as the debugger is removed. Even we connect the debugger, after power off and power on reset, the debugger session will be lost and we cannot trace back which API got stuck.

Please follow the procedure that i mentioned in first comment of the below thread, using this procedure we can connect the debugger again without any power sequence and without altering any execution.

(+) TMS570LC4357: TMS570LC4357 - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

--
Thanks & regards.
Jagadish.

0 Alex Lee 3 months ago in reply to jagadish gundavarapu

Prodigy 70 points

jagadish gundavarapu said:
Please follow the procedure that i mentioned in first comment of the below thread, using this procedure we can connect the debugger again without any power sequence and without altering any execution.

Thanks. We have followed the instructions and found the software programes eneter the ESM error routine, Group 3 Channel 3 as below:

...

Any clue of why it happened?

0 Alex Lee 3 months ago in reply to Alex Lee

Prodigy 70 points

jagadish gundavarapu said:
Please follow the procedure that i mentioned in first comment of the below thread, using this procedure we can connect the debugger again without any power sequence and without altering any execution.

Thanks. We have followed the instructions and found the software programes eneter the ESM error routine, Group 3 Channel 3 as below:

Update: This ESM error found out is caused by our special settings. We actually create a Non-Init variable in Non-Init RAM region and we assign value to it without initialization. It is found out this will cause ESM report error. Now we move this variable update after ESM error check.

We do not see the ESM error any more but the application software will randomly enter the exception after the bootloader SW and application SW transit several times.

Can you kindly confirm our MPU configuration is correct and how to continue debugging the new issue?

0 AJ Favela 2 months ago in reply to Alex Lee

TI__Intellectual 1860 points

Hi Alex,

I apologize for the late response, do you still require support on this question?

Kind regards,

AJ Favela