• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 83 subscribers
  • Views 743 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.

TMS320F28386S: Boot to Flash does not work after power-up

Steven Liechti
Prodigy 60 points

Part Number: TMS320F28386S

We are using default GPIO Boot Mode and both pins (GPIO72 and GPIO84) are set high. So the Boot Mode should be "Boot to Flash".

In OTP the GPREG's are all ones (default). But the flash is secured by DCSM OTP. The CPU2 and CM are not programmed. The program start in flash shall be default (0x80000). The linker option "entry_point" is set to code_start and we are using TI's f2838x_codestartbranch.asm with watchdog disabled.

After loading the program with JTAG it works fine. But after a power-cycle the PC stays in an address range which according to TRM means it is in "Wait Boot Mode".

Also the Flash configuration of the Blinky LED example does not boot after power-cycle.

My questions:

  • Is it necessary to explicitly set the flash entry point (BOOTDEF) to 0x80000 and all other GPREG configurations in OTP register even if I want default boot mode?
  • Have the CPU2 and CM to be booted or flashed too such that the CPU1 boots correctly?
  • Can I use the "Flash Boot" option with secure flash or do I have to use "Secure Flash Boot"?
  • What else could be the problem?

Thanks in advance for the answers.

  • 0
    TI__Genius 15385 points

    Hi,

    Answer to your questions:

    1. No, I dont think you need to set the flash entry point to 0x80000 if you have pins configured to BOOT from Flash. 

    2. No CPU2 and CM does not need to be flashed.

    3. Copied Vivek Singh our security expert to confirm.

    It is strange why would the PC stay in Wait BOOT mode. Let me check with the experts, in the meantime can you send the details on what location is the PC getting stuck?

    Best Regards,

    Nirav

  • 0 in reply to Nirav Ginwala
    Prodigy 60 points

    Hi Nirav

    Thanks for the answers. After power-cycle and reconnect, the PC is at 0x3FD2AE, after resuming it stays at 0x3FB114 (which is Wait Boot Mode for Silicon RevA according to TRM).

    Regards, Steven

  • 0 in reply to Steven Liechti
    TI__Genius 15385 points

    Hi Steven,

    When you connect after power-cycle and reconnect, the PC showing 0x3FD2AE suggests that it stuck in BOOTROM. Once the debugger is connected and you resume it will go to either STANDALONE boot or Wait BOOT depending on EMU bootpin config key.

    I need to check with bootrom expert to determine what is at address 0x3FD2AE and why PC is at that address when you connect after power cycle.

    Best Regards,

    Nirav

  • 0 in reply to Nirav Ginwala
    TI__Genius 17370 points

    0x3FD2AE is beginning of boot rom code. by default the ccxml includes gel file. On target connect with CCS the gel file will reset the CPU, so the PC will point to beginning of boot rom code.

    To debug your issue remove the gel file and connect to the CPU. now check where the PC is pointing to.

  • 0 in reply to Baskaran Chidambaram
    Prodigy 60 points

    Thanks for the answers.

    I removed the .gel file. I programmed via JTAG, resumed, disconnected, power-cycled and connect. Then the PC is still pointing to 0x3FB114.
    I also attached two measurements showing the two Bootpins and the XRS Signal at power-up (left Bootpin0 and XRS, right Bootpin1 and XRS). I think that is okay, only to be sure the Bootpins are correct.

    Regards, Steven

  • 0 in reply to Steven Liechti
    Prodigy 60 points

    Could you figure anything out that could be the problem?

    I tested the program on a fresh device, where the OTP is not programmed yet. Leaving all OTP registers as dummy sections works and also startup works. So the problem is anywhere with the secured device.

  • 0 in reply to Steven Liechti
    TI__Genius 17370 points

    the secure configurations in OTP may have an issue. You need to review and identify the issue. Unfortunately we cant debug the secure code to identify the issue.

  • +1 in reply to Baskaran Chidambaram
    Prodigy 60 points

    I could solve this issue. If the RAM/flash sectors shall belong to one zone, the GRAMRAMx/GRABSECTx bits in the other zone cannot be 0b11 (like in older DSPs) if the passwords are set (Table 6-1 in TRM).