This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28379D: Reserved RAM Memory Map for CPU2

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hi experts,

What is the area of reserved RAM Memory Map for CPU2?

The TRM includes the following statements.

But I think this statement is wrong.

The reasons are listed below.

I debugged F2837xD_sci_flash_kernels_cpu02 on CPU2 using the following link.
e2e.ti.com/.../3501137

Changed ramfuncs to RAMM0.(flash_programming_cpu2_RAM.cmd in F2837xD_sci_flash_kernels_cpu02 project)

Downloading the kernel with this setting will corrupt the data at the beginning of RAMM0.

Next, I changed the size of RAMM0 in reference to TRM.

However, even with this setting, the data at the beginning of RAMM0 is corrupted.

Finally, I changed the size of RAMM0 as follows.

With this setting, RAMM0 will contain the correct data.

Based on this result, I believe the Boot ROM uses more RAM than the 0x00A0.

Could you please confirm that these results are correct?

My HW : F28379D controlCARD
My SW : CCSv10.1 & C2000Ware_3_03_00_00

Best regards,
Sasaki

  • Hello

    Yes, I can confirm when using SCI boot that it does use more RAM than listed in TRM. I observed using up to and including address 0xAD. Try from address 0xAE.

    We'll correct the TRM.

    Best regards

    Chris

  • Hello Chris-san,

    Thank you for your reply.

    I try from address 0xAE, but I loaded the F2837xD_sci_flash_kernels_cpu02 into RAMM0 and it did not work properly.

    Dumping the RAMM0 memory after SCI boot, I found the following.

    The SCI boot was used up to 0x12C in RAMM0.

    I try from address 0x12E,I have successfully downloaded the F2837xD_sci_flash_kernels_cpu02 to RAMM0.

    Best regards,
    Sasaki

  • Sasaki

    I re-did my tests and the CPU2 SCI bootloader actually isn't using more than its reserved RAM memory.

    If you set a breakpoint at address 0x0 on CPU2 when doing the firmware update, you'll see what the SCI ROM bootloader is using once it completes loading the kernel app (but hasn't run the kernel yet). In the below image, you can see the SCI bootloader uses up to 0x67 then the unmodified CPU2 kernel starts using memory at 0x80.

    You're likely seeing a conflict from the loading the CPU2 blinky app being loaded. Please check and see.

    Best regards

    Chris

  • Hi Chris-san,

    Thank you for your support.

    I set the breakpoint to 0x0 on CPU2 and checked it, and I can see the SCI bootloader uses up to 0x68.

    Then when I run the kernel, it uses up to 0xC0. At this time, the blinky_dc_cpu02 has not been downloaded yet.

    Then run "2-DFU CPU2" in the serial_flash_programmer and download blinky_dc_cpu02, it uses up to 0x12C.

    My blinky_dc_cpu02(default flash project)  does not use RAMM0.

    However, the default kernel project(F2837xD_sci_flash_kernels_cpu02) cannot download blinky_dc_cpu02, because it is actually used until 0x12C after the kernel is downloaded.

    Can you download blinky_dc_cpu02 when you load the kernel project at 0x80?

    Also, do you know why the kernel uses memory up to 0x12C?

    Best regards,
    Sasaki

  • Hello

    From my understanding, the default projects are what are present under the flash programmers directory in C2000Ware, in which I've used and loaded successfully. 

    Let me investigate further regarding the kernel and their memory usage.

    Best regards

    Chris

  • Hi Chris-san,

    Thank you for your support.

    Christopher Chiarella said:
    Let me investigate further regarding the kernel and their memory usage.

    I have assigned the following project ".TI.ramfunc" to RAMM0.

    C:\ti\c2000\C2000Ware_3_03_00_00\device_support\f2837xd\examples\dual\F2837xD_sci_flash_kernels

    Please let me know If you find the cause of this problem.

    Best regards,
    Sasaki

  • Sasaki-san,

    I will also be looking into this, and will provide you an update within a day.

    Thanks,

    Sira

  • Hi Sira-san,

    Do you have any update?

    Best regards,
    Sasaki

  • Sasaki-san, sorry I have not been able to spend time on this. I will positively get back to you by Monday. Thanks, Sira

  • Sasaki-san,

    Since I started looking at this issue from scratch, here are my observations:

    1. The default CPU2 Flash Kernel has RAMM0 defined from 0x80 with length 0x380, even though the TRM indicates that the Boot ROM reserves 0x02 to 0xA1. So there is some inconsistency there that needs to be fixed.

    2. Without any further changes to the CPU Flash Kernel, I am able to get blinky_dc_cpu02 to download and work properly. Here, .TI.ramfunc is assigned to RAMD0, and the .map file indicates that RAMM0 usage is 0x80 to 0x93.

    3. With .TI.ramfunc assigned to RAMM0, the .map file indicates the RAMM0 usage length is 0xf8. And as stated by you, I am not able to download blinky_dc_cpu02 to CPU2.

    4. I changed CPU2 Flash Kernel to begin at 0x12E, and as stated by you, it works.

    It is strange why the issue is exposed when .TI.ramfuncs is run out of RAMM0 and not otherwise, when there are still sections assigned to RAMM0. Let me discuss further with Chris.

    Thanks,

    Sira

  • Hi Sira-san,

    Thank you for your reply.

    Please let me know if you know what causes the bootloader to use up to 0x12E of RAMM0.

    Best regards,
    Sasaki

  • Sasaki-san,

    Chris made an interesting observation thus "

    The kernel isn’t going through c_init (which is currently intentional in the code, though I don’t know why). I think the stack pointer isn’t getting updated to the assigned location and the kernel is continuing to use the same stack location as used by ROM therefore “violating” what is assigned via the linker command file."

    And this is indeed the case because the calls to _c_int00 are commented out in both fwupgradec1toc2_start.asm and fwupgradec2_start.asm. They both directly call main. We don't understand why. Probably need to go look at the development history.

    As a first test, I uncommented the calls to _c_int00 (and commented the calls to main) in both the .asm files, and tested the behavior. I used the default placement for RAMM0 (at 0x80), and moved ramfuncs to RAMM0. It seemed promising, because once the kernel is loaded to CPU2, I would not get a command prompt to run DFU-CPU2. With this change, I got that prompt, ran DFU-CPU2. But at the end, when I ran command 15 Run CPU2, neither of the LEDs were blinking.

    Something for you to investigate as well, as will we.

    Thanks,

    Sira

  • Hi Sira-san,

    Thank you for your information.

    Please let me know if you get any new information.

    I will investigate this when I have the time to do so.

    Best regards,
    Sasaki

  • Sasaki-san, I will get back to you shortly. Thanks, Sira

  • Sasaki-san, 

    After the above test, where the c_int00 call was present in both CPU01 and CPU02 flash kernels , didn't work, I also tried including the c_int00 call only in one of the flash kernels - CPU01 and CPU02. In both cases, the behavior was the same, the application did not properly download to Flash.

    This is something that I will file a JIRA for so it can hopefully be fixed soon, but for now, I will recommend that you either use a different RAM region for .TI.ramfunc, or the modified size that works.

    Thanks,

    Sira

  • Hi Sira-san,

    Thank you for your information.

    Sira Rao80 said:
    This is something that I will file a JIRA for so it can hopefully be fixed soon, but for now, I will recommend that you either use a different RAM region for .TI.ramfunc, or the modified size that works.

    I understand.
    I know how to deal with it, so it's not a problem.

    Best regards,
    Sasaki