AM2634: Retaining variables in RAM after reset.

Part Number: AM2634
Other Parts Discussed in Thread: TMS570LS1227, SYSCONFIG,

Tool/software:

Hello,

I am currently working on porting firmware from the TMS570LS1227. One of the modules requires data sharing between the firmware and the SBL, so that the UDS transaction initialized in the firmware can be completed in the bootloader. This enables the firmware update to be handled by the SBL afterward.

I have used SysConfig to define the UDS_SHM_MEM memory region and the UDS shared section in both the bootloader and firmware projects (see the picture below).

Initially, I implemented a watchdog reset in the firmware. However, after the reset, the RAM content is not retained, and all memory locations are initialized to 0.

After searching the forum, I came across the following post.

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1255920/am2634-non-initialized-ram-area-after-reset

Instead of using the watchdog reset, I tried performing a software warm reset instead (via the function call SOC_generateSwWarmReset()). Unfortunately, this did not resolve the issue, and the memory is still initialized to 0.

From my experience with the TMS570LS1227, I recall needing to customize the assembler initialization code. However, after reviewing the AM2634 code, I do not see anything that would require modification.

What is the correct way to implement RAM sharing between the firmware and the SBL, ensuring that the RAM retains its content?

Kind regards,

  • Hi Damian,

    Apologies for the delayed reply.

    RAM content will be there until you pull out the power

    but ROM would overwrite for the portion it uses and it would initialize the banks it uses, this will happen after any reset warm reset POR etc.

  • Hi Nilabh,

    I finally found the time to revisit this issue after working on something else for a while.

    Thank you for clarifying.

    I’ve successfully implemented sharing of the UDS_SHM_MEM buffer between the firmware and bootloader by moving the buffer to the very end of the available OCRAM (0x701F'F000 – 0x701F'FFFF). My first attempt failed when I placed UDS_SHM_MEM at 0x7005'0000, but the new location works as expected.

    I can also confirm that the memory retains its contents during both watchdog resets and software warm resets.

    Since the first attempt failed, I wanted to ask whether there is any official documentation available for the ROM bootloader that describes which memory regions are used and initialized when the ROM bootloader starts the SBL.

  • Since the first attempt failed, I wanted to ask whether there is any official documentation available for the ROM bootloader that describes which memory regions are used and initialized when the ROM bootloader starts the SBL.

    Yes please look at the SBL code linker file for more details, It maps out all the sections of memory being used by SBL.

    It is generated by syscfg.

  • You initially mentioned that the ROM bootloader (Primary Bootloader) overwrites and initializes the memory regions it uses. As I understand it (and based on what I’ve observed), some portions of RAM are indeed initialized at that stage. If possible, it would be very helpful to have clarity on exactly which memory regions are used and initialized (especially those explicitly initialized) by the ROM bootloader.

    The SBL itself isn’t an issue, as I can adjust memory usage using SysConfig and, as you mentioned, refer to the linker file to see how it’s mapped. The main challenge is understanding the regions handled by the ROM bootloader before SBL execution begins.

    Thanks again for your support.

  • Yes it is mentioned in TRM under PBIST setion:

  • Since there are four memory banks, each 512 KB, available as L2OCRAM, and the first two are being tested by the ROM Bootloader, it should be safe to use the remaining two banks for data sharing between the firmware and the bootloader.

    Thank you very much for your help.