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

TMS320F28075: Board not booting from flash despite setting Z1_BOOTCTRL

Matthew Riggs
Prodigy 50 points

Part Number: TMS320F28075

Hello! I'm hoping this will be an easy one. I am working with a TMS320F28075 on a new custom board, and so far it is going well. As long as I run the firmware using the debugging, everything works as expected, however I can't seem to get the board to boot out of on-chip flash when my JTAG emulator is disconnected. With the emulator connected, I can use EMU_BOOTCTRL to verify that a value of 0x2A2A0B5A causes the flash to be booted from. I'm able to verify the flash boot by watching the current draw from the board.

When we laid out the board we did not consider the Boot Mode Select Pins, and neither are low at boot. GPIO41 is being pulled up however, so I used the On Chip Flash tool in Code Composer Studio to set Z1_BOOTCTRL to 0x2A2A0B5A. My understanding is that should point both Boot Mode Select Pin 1 and 2 to GPIO41, and that 0x0B will cause the "Get Mode" to select the Flash. I'm able to see in the Memory Browser that Z1_BOOTCTRL remains set after power cycling.

Reading the TRM, it looks like the JTAG nTRST causes EMU_BOOTCTRL to be used, so I've been trying to encourage a flash boot by disconnecting the programming interface, but the board still does not boot from flash.

In a different thread, I saw that CodeStartBranch.asm needed to be included in their project to get flash boot working. I've got F2807x_CodeStartBranch.asm in my project as a "Linked Resource".. I'm not sure if that's what is needed to get it properly included.

Right now I'm at a loss for what to try next... any suggestions are welcome!

Thanks,

-Matt

  • 0
    TI__Guru** 117261 points

    Hi Matt,

    Your configuration look correct. Please make sure you are using correct linker cmd file to map the code_start at address 0x80000. Please check your map file to confirm the same. If that is correct then I would suggest to run the device in stand-alone more with CCS connected. Please follow below steps for the same. -

    • Connect to CCS.
    • Load the code
    • Set breakpoint at main() function.
    • Write 0xFF5A at address 0xD00 via CCS memory watch window.
    • Reset the CPU via CCS reset icon.
    • Run

    CPU should halt at main().

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 50 points

    Vivek-

    Thanks for the quick reply!

    I checked the 28075_FLASH_lnk.cmd file and the .map file generated as part of build -- they show codestart being loaded into a BEGIN section at 0x80000 which has a size of 2.

    Here is the linker cmd file sections:

    MEMORY
{
PAGE 0 :  /* Program Memory */
          /* Memory (RAM/FLASH) blocks can be moved to PAGE1 for data allocation */
          /* BEGIN is used for the "boot to Flash" bootloader mode   */

   BEGIN           	: origin = 0x080000, length = 0x000002
<SNIP>
}


SECTIONS
{
   /* Allocate program areas: */
   .cinit              : > FLASHB      PAGE = 0, ALIGN(4)
   .pinit              : > FLASHB,     PAGE = 0, ALIGN(4)
   .text               : >> FLASHB | FLASHC | FLASHD | FLASHE      PAGE = 0, ALIGN(4)
   codestart           : > BEGIN       PAGE = 0, ALIGN(4)
<SNIP>

    And here is the .map file sections that result:

             name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
PAGE 0:
  RAMM0                 00000122   000002de  00000000  000002de  RWIX
  RAMLS0                00008000   00000800  00000004  000007fc  RWIX
  RAMLS1                00008800   00000800  00000000  00000800  RWIX
  RAMLS2                00009000   00000800  00000000  00000800  RWIX
  RAMLS3                00009800   00000800  00000000  00000800  RWIX
  RAMLS4                0000a000   00000800  00000000  00000800  RWIX
  RAMD0                 0000b000   00000800  00000000  00000800  RWIX
  BEGIN                 00080000   00000002  00000002  00000000  RWIX

 <SNIP>

  codestart 
*          0    00080000    00000002     
                  00080000    00000002     F2807x_CodeStartBranch.obj (codestart)
<SNIP>

    I performed the steps you outlined and the CPU halted at main() without an issue.

    I tried setting the WD_ENABLE switch in F2807x_CodeStartBranch.asm to 1 in case the watchdog was eating us before we got a chance to disable it in the main code, but that made no difference.

    Do you have any other suggestions for me?

    Thanks again!

    -Matt

  • 0 in reply to Matthew Riggs
    Prodigy 50 points

    Vivek-

    I'm happy to report that this problem is resolved; the issue turned out to be a race condition between the pulled-up boot mode pin's rail and the F28075's rail. 

    Once that race condition was resolved, we're booting from flash as expected and without issues.

    I appreciate your attention on this issue!

    -Matt