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.

TMS320F28377D: About the ".TI.ramfunc" setting in "F2837xD_sci_flash_kernels"

Part Number: TMS320F28377D
Other Parts Discussed in Thread: C2000WARE

Hi,

F2837xD_sci_flash_kernels to set the RAM area .TI.ramfunc for CPU2 program code to "M0 RAM" will not work, but "D0 RAM" will work.
Because the version of C2000Ware was old (1.00.05.00), I changed it to the latest version (3.02.00.00), and it came to be able to write to CPU2 side.
I just looked at the differences between the old and new F2837xD_sci_flash_kernels, The area of .TI.ramfunc in CPU2 was allocated to M0 RAM for the old one and D0 RAM for the new one.
However, On the other hand, some of the C2000Ware samples use the M0 RAM. So, I don't know why it doesn't work with M0 RAM.

I would like to know the following points:

Q1: Can't I use the M0 RAM as a .TI.ramfunc?
Q2: Is there any reason why it can't be used in the case of serial boot?
Q3: Can't I use it only with CPU2?


Best Regards,
H.U

  • Hidenori, 

    I am currently looking into this and will get back to you shortly. Are you only programming CPU2 or were you looking to use M0 RAM with CPU1 as well? Also, is D0 RAM being used for something else such that you want to use M0 RAM for .TI.ramfunc?

    Thank you,

    Anu Biradar

  • Hi,

    Please take a look at section 4.9.3.4 Reserved RAM and Flash Memory Map in the TRM (https://www.ti.com/lit/ug/spruhm8h/spruhm8h.pdf).

    As mentioned in this section, there are some reserved locations in M0/M1 (reserved locations are different for CPU1 and CPU2).  We need to make sure that kernels are not using that space and hence are updated to use Dx (I don't have the old version installed in my laptop and could not check the old linker cmd at this time).

    Thanks and regards,

    Vamsi

  • Hi Anu Biradar, Vamsi,

    Thank you for your reply.

    All of the M1 RAM is used as a data area for both CPU1 and CPU2, with 0x0400 to 0x077F used as the stack and 0x0780 to 0x07FF as the data area (note: TI-RTOS is not used).
    The RAM area for the program code is currently allocated to LS0 and LS1 for the CPU and LS2 for the CLA.
    D0 RAM is used only as a .TI.ramfunc.
    The reserved area (Boot ROM) of M0/M1 is not used. Also, TI-RTOS is not used.

    Best Regards,
    H.U

  • Hidenori,

    Ok, thank you.  I don't see any issue in how they were used.  It might be that the stack is overflowing and hence modified it.

    Thanks and regards,
    Vamsi

  • Hi Vamsi,

    Loading the blinky_dc_cpu01.tx and blinky_dc_cpu02.txt provided by C2000 ware into their respective cores using F2837xD_sci_flash_kernels has the same problem.
    This problem occurs when F2837xD_sci_flash_kernels loads an application to CPU2.
    The CPU1 side is working fine. Is this still suspected to be the stack overflow?

    Could you use blinky_dc_cpu01.tx and blinky_dc_cpu02.txt to check the operation?

    Best Regards,
    H.U

  • Hidenori,

    Do you mean the issue comes when using old C2000Ware where TI.ramfunc is mapped to M0 RAM?

    Or

    When using the latest C2000Ware contents?

    Please clarify.

    Thanks and regards,

    Vamsi

  • Hi Vamsi,

    It occurs in the latest version of the C2000 Ware.
    The F2837xD_sci_flash_kernels of the latest version has the TI.ramfunc area for CPU2 is allocated to D0RAM.
    So there is a need to change the TI.ramfunc region to M0RAM to reproduce this phenomenon.

    Best Regards,
    H.U

  • Hidenori,

    Thank you for the details.

    Our team will check and get back to you.

    Thanks and regards,

    Vamsi

  • Hidenori, 

    I was able to run the blinky_dc_cpu01.txt and blinky_dc_cpu02.txt files with .TI.ramfunc mapped to M0RAM in flash_programming_cpu2_RAM.cmd with the following steps: 

    1. Build F2837xD_sci_flash_kernels_cpu01 in CCS with SCI_BOOT_ALTERNATE as the argument to SCI_GetFunction() in F2837xD_sci_flash_kernels_cpu01.c.

    2. Build F2837xD_sci_flash_kernels_cpu02 in CCS.

    3. Set the controlCARD to SCI Boot Mode by setting SW1 Position 1 to 0, and SW1 Position 2 to 1.

    4. Connect to CPU1 in CCS. Click "Reset CPU" and set memory location 0xD00 to 0x815A.

    5. Connect to CPU2 in CCS. Click "Reset CPU" and hit "Resume". After the program hits ESTOP, Click "Resume" again.

    6. Click "Resume" for CPU1 in CCS.

    7. Run the following command in a command prompt (note that CPU1 needs the alternate kernel file):

    serial_flash_programmer.exe -d f2837xD -k f2837xD_fw_upgrade_example\F2837xD_sci_flash_kernels_cpu01_alt.txt -a f2837xD_fw_upgrade_example\blinky_dc_cpu01.txt -b 9600 -p COM<com port number> -m f2837xD_fw_upgrade_example\F2837xD_sci_flash_kernels_cpu02.txt -n f2837xD_fw_upgrade_example\blinky_dc_cpu02.txt -v

    8. Select Option 1 - DFU CPU1. This will allow blinky_dc_cpu01.txt to de downloaded to Flash.

    9. Select Option 13 - Run CPU1 and Boot CPU2 - and enter the entry point address. This will allow the CPU2 kernel to be downloaded to RAM

    10. Select Option 2 - DFU CPU2. This will allow blinky_dc_cpu02.txt to de downloaded to Flash.

    11. Select Option 15 - Run CPU2 - and enter the entry point address. 

    Hope this helps!

    Thank you,

    Anu Biradar

  • Hidenori, Please refer to this issue (if you haven't already). It indicates why the issue occurs when .TI.ramfunc is mapped to RAMM0.

    Thanks,

    Sira

  • Hi TI Team,

    Thank you for your support.
    It worked fine in my environment and solved the problem.

    Best Regards,
    H.U