TMS320F28379D: Reserved RAM Memory Map for CPU2

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

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