TMS320F28377D: Failed to boot through UART

If it is online debugging, I can use the "CPU Reset" on the interface to make it run boot and app normally, but the problem I described above occurs when it is powered on again after power failure.

Hello,

Just to clarify, are you saying that when you start up the device initially, you are unable to flash and run your program, but when you then follow this with a CPU reset, you are able to flash and run the program successfully? Could you elaborate more on what occurs/what you see when it fails upon power-on? 

The Flash boot entry point is always 0x0008 0000 as per the device documentation. As I understand it, the boot rom jumps to code at 0x80000 consistently and there is no issue with this. You are seeing problem when jumping from bootloader to the start of the application (at 0x088000). Am I correct?

Also could you please clarify the difference between these two cases? They both seem to imply you are loading the application project through debugger, but in one case you are unable to run your bootloader?

Marvn Arcangel said:

①Upgrating my app project through the xds2xx onboard debug can make both my BOOT and APP projects work normally;

②Upgrating my app project through the xds2xx onboard debug fails to make my BOOT project run.

Best Regards,

Allison

Hi Allison,

Thanks for your reply!

I'm sorry to make the mistake. Actually,case ② is "Upgrating my app project through Uart fails to make my BOOT project run".

As regard to the failure of the device initialization, the details will be described below:

When all the initalizations are executed and the chip has run into main loop, I designed different blink ways of my 2 LEDs. In my bootloader project, GPIO 25 toggles the state of a LED per second; and in my application project ,GPIO 25,26  toggle states of 2 LEDs ,and the LEDs blink in different frequencies.

Besides, if the update is through Uart, when upgrate succeeds, CRC value of whole upgrate file will be written to a specific address. Once I power up the chip, it will caculate the CRC value of application's flash data and compare it with the CRC value in the specific address. If they're the same, bootloader would jump into application, otherwise ,it will always stay in the bootloader.

Thus, when I see all the LEDs are off, I know that the CRC check is passed, and the chip is stuck somewhere in the process of bootloader jump to app.

And the following is concerning the "CPU Reset".

Recently, I upgrade through Uart in DEBUG mode. After the upgrade is successful, I cannot jump to the app immediately. In this case, if I click "CPU  Reset", boot and app can run normally. After the power failure and restart, there is no way to run the program again until I load bootloader.out once more.

I'm confused that since all the data(through onboard debug and through Uart) is the same, why the jump alwas fail?

Best Regards,

Xu

Xu,

From your 1st post: 

Marvn Arcangel said:

BEGIN : origin = 0x080000, length = 0x000002 /* Flash sectors */
FLASH_BOOT : origin = 0x080002, length = 0x007FFE /* on-chip Flash */

codestart : > BEGIN PAGE = 0, ALIGN(4)

The cmd configuration of the APP project is as follows:
FLASH_APP_BEGIN : origin = 0x088000, length = 0x000002 /* on-chip Flash */
FLASH_APP : origin = 0x088002, length = 0x017FF4 /* on-chip Flash */

codestart : > FLASH_APP_BEGIN PAGE = 0, ALIGN(4)

I think you are using a custom bootloader and always setting the boot pins to boot to flash?  Can you confirm?

Assuming this is correct, can you comment on how you decide if you want to execute the bootloader or the main application?  Do you wait for a UART time out, and then branch to the main app code?

On boot up, depending on the boot pin config, the C28x core will look at a specific address(in the case of flash default boot this is 0x80000) for the address where the main code resides.  I think somewhere in flash boot you make a decision if you need to use the bootloader or should execute the application, this should jump to 0x88002 if the application is executed, and NOT 0x88000.

Can you also make sure you've included codestartbranch.asm in the project?

If you want to attach your map file that may help as well.

Best,
Matthew

Hi Matthew,
Firstly, I judged that it was in flash mode based on the states of GPIO72 and GPIO84, and I measured through the oscilloscope that they were always high.
Secondly, as I describe here:

guanya xu said:

Once I power up the chip, it will caculate the CRC value of application's flash data and compare it with the CRC value in the specific address. If they're the same, bootloader would jump into application, otherwise ,it will always stay in the bootloader.

But maybe it's not a complete description. There are 4 situations for bootloader jump to application.

• Passed CRC check.
• 30s time-out. If there is No upgrate message from upper computer through Uart in 30s,bootloader will jumo to application.
• Upgrate succeeded through Uart.
• Upgrate failed. I will copy the backup data into FLASH_APP section,and then bootloader will jump to application.

And thirdly, I cannot understand why the address should be 0x88002. Just form my perspective, jump to 0x88002 rather than 0x88000 skips _c_init. Does it means the initalization is not necessary to the switch between bootloader and application?

Finally, I confirm that I've included codestartbranch.asm in the project ,cause when I debug with "Memory Browser",I could see these words at 0x88000 or at 0x80000.

Besides,two .map files are attached at the end.
Thanks for your reply!

Best Regards,

Xu

boot_map.txtapp_map.txt

Hi Matthew,

I've tried as you suggested and make bootloader jump to 0x88002. But the result may not correspond to our design.

I found that when it will jump to app,then the chip get reset.To make sure what I see,I measure the state of TRST,and every 30 seconds,there is a reset record in the screen.
The photo I also attach at the end.

Regards,

Xu

Hi Xu, Matthew is out of the office until Tuesday, you should hear back from him then.

Hi everyone,

I've been testing my code for the last few days. Now there is a new development:
When I said I couldn't run my BOOT project after the reset, I wasn't accurate. In a recent debugging, I found that it will execute part of the initialization procedure after repowering, but from a certain statement, once running at full speed, the DSP will enter the NMI interrupt; If the contents after this statement are stepped, the DSP will not enter the NMI interrupt. However, if the single-step debugging "step into" is switched to the full-speed running "Run", the DSP will immediately enter the NMI interrupt.
I learned from the manual that NMI interrupts are non-maskable interrupts at the hardware level. But I am very confused, why I load the APP through the burner, does not trigger an NMI interrupt, but loading through the Uart will trigger an NMI interrupt?
Looking forward to your reply!

Regards,

Xu

Xu,

Sorry for the long time between posts.  You were correct in your last response to me, jump to 0x80000 was the correct thing to do as this contains the call to code_start_branch.asm which needs to set everything up correct for the C28x core/environment after boot.

Is it possible that your flash WS is getting set incorrectly based on your PLL setting?  If we are at full 200MHz then flash needs to be set to 5WS.  If the WS get set to something lower then the execution from flash memory may be unpredictable.

When we are connected to the debugger, there is a GEL file that is also taking care of some of the setups when we connect/load/reset in CCS.  This might explain why CCS connected upgrade is passing, but UART is not.

Best,

Matthew