• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 390 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.

Original question:

TMS320F28379D: can't get launchXL to boot from flash

TMS320F28379D: can't get launchXL to boot CPU2 from flash

ken hutchinson
Prodigy 195 points
Part Number: TMS320F28379D

Hi All. I've got a driverlib project with both CPU's. Works fine with JTAG load to RAM.

CPU1 will run from flash (with JTAG disconnected). CPU2 does not. Based on blinking LED's. 

If I connect with the JTAG, it always reloads everything and it all works. So I don't know how to debug. Is there a way to connect with the debugger and see where CPU2 is stuck?

Something that isn't clear in the example CMD linker files, is the line  .TI.ramfunc : {} LOAD = FLASHD,     is always the same for both CPU's even if FLASHD isn't used. Does this matter?

thanks

Ken

  • 0
    Prodigy 195 points

    as a test, on CPU1, I removed the call to   Device_bootCPU2(FLASH)

    On CPU2, I removed the check for shared memory configuration complete     while(MemCfg_getInitStatus(MEMCFG_SECT_GS15) != 0);     and added about a 1sec delay.

    Same result. CPU1 works, CPU2 does not.

    I can confirm that CPU1 and CPU2 are in the respective predefined symbols and _FLASH is in both. Are there any other stupid things I may be missing?

    thanks

  • 0 in reply to ken hutchinson
    Prodigy 195 points

    I think CPU2 is getting lost in    Flash_initModule

    The values in the memcpy  seem valid. the linker ramfunc is defined (just like examples) and appears in MAP file

    .TI.ramfunc : {} LOAD = FLASHD,
    RUN = RAMLS0,

    I'm still not clear how these linker values connect to symbols in the C code or the sections in the linker file. How does it know to put Flash_initModule in this section? 

  • 0 in reply to ken hutchinson
    Prodigy 195 points

    fixed the problem that made me think the error was in Flash_initModule.  

    On CPU2, I had    RUN = RAMGS0    which CPU2 didn't have R/W access to. Changed it to  RUN=RAMLS0

    It now works in the debugger, but still does not work during a flash boot. So back to where I started.  I have no idea where it dies..

  • 0 in reply to ken hutchinson
    Prodigy 195 points

    Also tried the example  blinky_dc_cpu02   in FLASH config.

    It worked with the JTAG connected, but not when I cycled power (only cpu1 was working)

  • 0 in reply to ken hutchinson
    Prodigy 195 points

    I have it working. For the record, in case someone else has this problem, I think I had it right, but didn't know it. 

    CPU1 must call   Device_bootCPU2   to release CPU2 boot loader (ROM). But you can't do this if running in debug mode or it hangs up. It's not necessary if loading with JTAG.

    CPU2 doesn't need any special calls in your code, but good practice to wait until CPU has configured the I/O and peripheral ownership.

    Both CPU's linker must include   TI.ramfunc   to allocate the   Flash_initModule   pointers and both CPU's must call Device_init where this function is called.

    I would still appreciate somebody explaining how that works. I see how I can add something like   #pragma CODE_SECTION(motor1ControlISR, ".TI.ramfunc");     for my own functions to copy to flash.  But how does it connect the ramfunc directive to Flash_initModule?  And what is the flash number used for (in the default cpu2 linker file, the designated flash isn't used anywhere else)?