Because of the Thanksgiving holiday in the U.S., TI E2E design support forum responses may be delayed the week of Nov. 21. Thank you for your patience.

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.

TMS320F28377S: Boot Mode Selection

Part Number: TMS320F28377S


I am using a target based on a tms320F28377S which is designed "Get / Flash" boot mode. When I load a code to the device, I get an error in this boot mode (screenshot given). But when boot mode is changed to "SCI" boot mode, the code is loaded to the device. Why cannot I load the code to the device in "Get / Flash" boot mode?

Also if a device was used in a boot mode, can it be used in a different boot mode again?

C28xx_CPU1: GEL Output:
Memory Map Initialization Complete
C28xx_CPU1: Error occurred during flash operation: Timed out waiting for
target to halt while executing wr_pll.alg
C28xx_CPU1: Error writing the PLL values (Flash algorithm timed out).
Operation cancelled.
C28xx_CPU1: Perform a debugger reset and execute the Boot-ROM code (click
on the RESUME button in CCS debug window) before erasing/loading the
Flash. If that does not help to perform a successful Flash erase/load,
check the Reset cause (RESC) register, NMI shadow flag (NMISHDFLG)
register and the Boot-ROM status register for further debug.
C28xx_CPU1: File Loader: Memory write failed: Unknown error
C28xx_CPU1: GEL: File:
D:\Ph.D\14-Programming\MCU1U57V1.6\Flash_Option\MCU1U57V1.6.out: Load
  • Hi Enes,

    When there is no code in the flash, and if the flash boot is chosen, upon power-up, after the boot process, control will jump to flash and CPU will start fetching illegal opcodes (since there is no code in flash).  This will cause ITRAPs/reset and as a result, you connection won't be stable.

    When you choose SCI boot mode, boot code will wait in a loop looking for data on the SCI bus, hence it won't cause any ITRAP.

    Thanks and regards,


  • Hi Vamsi,

    Thanks for the answer.
    Got it, but I still have a few questions about it.

    1)then everyone using this controller has to do this when loading code for the first time? or do they?

    2)If the connection is unstable when there is no code in the flash, why do I have to do SCI mode again when loading code for the second time?

  • Hi Enes,

    1) If the connection happens before the reset (or in between the resets), then it should be fine.

    2) Can you check if the application is causing any resets?

    I will assign this to our system control expert to help you further.

    Thanks and regards,


  • Hi Vamsi,

    Thank you for your answer and help. 

    i will check reset port , but i am not sure that there is reset because the board is running alone, it does not connect to any pcb where there can be noise.

    i look forward to see your advices... i need them so much now...

  • Hi,

    Can you try below step -

    • After connecting to CCS, issue reset from CCS (Reset CPU) and then click on "Run". 
    • After CPU halts (If CPU does not halt  automatically, do it manually), try to load the code. 

    Let us know if this helps.


    Vivek Singh

  • Hi Singh,

    i will try it tomorrow.

    i will set boot mode as sci or wait mode to connect to mcu with loading code.then try your steps..

    But i could not understand,how it will helps us to solve our problem? What will we understand with this steps?

  • As per my understanding you are facing issue with Get Boot (Flash Boot) only so I would suggest to try these steps with Get Boot itself.


    Vivek Singh

  • But the main problem is connecting to mcu with this mode(Get Boot),as you say to connect to mcu, i have to change boot mode again(as sci or wait)..

  • Hi,

    From below statement, I thought you have issue with loading code and not connection. 

    When I load a code to the device, I get an error in this boot mode (screenshot given).

    May be you are launching a debug session which connects to CPU and also loads the code. If yes, then you can split this into two step process. Ist connect to CCS by launching the target configuration file manually and connecting to CPU (click on CCS icon "View" and select "Target Configuration" view and there find the target configuration file -> *.ccxml file inside your project then right click on ccxml file and launch it)  and then follow the step I mention to load the code.


    Vivek Singh  

  • Sorry, there is missunderstanding in here.. i can not load code to mcu without changing boot mode. if i change boot mode to sci or wait mode, i can load code to mcu and run. So there is not any problem if i change boot mode...

    Yes as you say i am doing on debug session which connect and load code.i will try what you say..

    But i think the problem is that why i can not load code on debug session? Why am i using this issue? Because my previous designs schematic is same as this one, i did not have any problem on that design. i have used that one with "Get boot" and it allways worked without any problem.

  • As suggested by Vamsi, you need to check the XRSn pin status on both working board and non working board in "Get Boot" mode.

  • okay, i will try it tomorrow. and I will report the situation

  • Hi Vivek,

    I checked the XRSn pin status and I send a scope screen. As shown in scope, when the target power up in Flash Boot mode, the XRSn pin goes the low state during the code loading process. and there is not any distortion on 3.3V. But when target power up in SCI boot mode, XRS pin do not goes low state and the code is loading without any problem. 

  • Hello again Vivek,

    In XRSn pin, I have pull up resistor and capacitor. I changed the value of this resistor 10K ohm to 1K ohm and  also I changed the value of capacitor 100nF to 10uF. The distortion on this pin was decreased as shown given scope screen. But the problem is still.

  • 1K ohm pull will be low. Generally XRSn should not go low during code loading process. You mentioned 3,3V rail is ok but what about 1.2V ?

  • Hi Vivek,

    I have good news.

    You are right, the problem was 1.2V. We think that the power on reset occure while code loading. It droped up to 1V. I fixed the problem in 1.2V source, and the power on reset problem was fixed.

    Thank you for your support.