• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 214 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28388D: Problems with updating CPU1 FW using SSBL

pranay r
Intellectual 390 points
Part Number: TMS320F28388D
Other Parts Discussed in Thread: SYSBIOS

Hello All,

I'm using F28388D for my product development.

I want to update CPU1 FW using SSBL, I'm using SYS/BIOS in CPU1 and SSBL for CPU1 is baremetal and I allocated

Flash sectors 1, 2 and 3 for SSBL

Flash Sector 13 for Mode selection -> to know whether we need to stay in Program mode or Boot mode,
        - So that this flash sector will be read and validated with custom keyword whether to stay in SSBL mode for updating FW received over IPC via Ethernet from CM core

Remaining Flash sector will be allocated for Application FW.

RAM is also partitioned accordingly in such a way that SSBL and Application FW will not used same part of RAM.

Progress made:

So far we were able to Erase flash sectors, Write total Application FW into Flash via IPC <- Ethernet(CM) and write required Keyword to required flash sector so that Jump happens to Application FW.

we have ensured that no peripherals are re-initialized in SSBL and Application FW.

Problem statement:

So whenever we try to jump to Application FW from SSBL after writing keyword by calling " __asm(" LB 0x86000 ");" /*jumping to entry point*/

I see that execution is getting hung before main even starts. Main is not even getting executed.

I further digged up in dis-assembly and found that execution is hung in -> xdc_runtime_startup_exec_e Function in startup.c

Debug 1:

I tried adding startup hooks configuration in .cfg file of Application FW which added "Startup.resetFxn = Startup.reset; " thought this would help but it didnt help.

Stuck on this problem since past few weeks, can you guys please help me sort this out. I can share Source codes in personal message if required for faster resolution.

Thanks and regards,

Pranay.

  • 0
    TI__Guru 53975 points

    If you load the application to flash using CCS and then boot the application from flash after a power cycle does it run as expected? Is it specifically when you try to load and run it from the SSBL that you get this problem?

    What is stored at 0x86000? The SYS/BIOS ti_sysbios_family_c28_f2838x_init_begin section?

    Whitney

  • 0 in reply to Whitney Dewey
    Intellectual 390 points
    Whitney Dewey said:
    If you load the application to flash using CCS and then boot the application from flash after a power cycle does it run as expected?

    Yes I forgot to mention that this is another fundamental problem we are facing, we suspecting that this is not happening as we have a change in BEGIN address.
    So basically, we're able to run in debug mode seamlessly but once we flash using CCS and then reset/restart board, FW is unable to boot, not sure where to change and what to change. we've changed in .cfg file - Boot.loadSegment = "FLASH3 PAGE = 0"; but this doesn't help either.

    Whitney Dewey said:
    What is stored at 0x86000? The SYS/BIOS ti_sysbios_family_c28_f2838x_init_begin section?

    In 0x86000 we're storing entry point of CPU1 application FW which is mentioned in .cmd file.

    Edit 1:

    I have an update here.

    Whenever we try to boot, It will try to jump from SSBL to App FW, At that time Before even main() starts it will execute some startup functions from libraries related to "rts2800_fpu64_eabi.lib" which is already stored in .data section in RAM. So it will find and execute this rtsc libraries and jump to  main() and starts execution.

    So now coming to the issue, This thing works if we're running in debug mode but when we try to flash FW using SSBL, I see that respective location in RAM are filled ITRAP, i.e., unable to find start up functions.so as it is unable to find the library location hence jumping to illegal handler().

    Correct me if my understanding is wrong and let me know how to sort this issue out.

    --Pranay.

  • 0 in reply to pranay r
    TI__Guru 53975 points
    pranay r said:
    In 0x86000 we're storing entry point of CPU1 application FW which is mentioned in .cmd file.

    It would be good to check the .map file as well to confirm that what you think is being placed at 0x86000 is actually there.

    pranay r said:
    So now coming to the issue, This thing works if we're running in debug mode but when we try to flash FW using SSBL, I see that respective location in RAM are filled ITRAP, i.e., unable to find start up functions.so as it is unable to find the library location hence jumping to illegal handler().

    Are you trying to execute functions from RAM before RAM has even been initialized? Are you able to put your start up functions in flash instead of RAM or do a memcpy to copy them from Flash to RAM before you need to execute them?

    Whitney