TMS320F28069: cannot reset the device through watchdog

How is the bootloader programmed into flash? Via JTAG or some other method? 

Please see https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/757590 for some tips.

Hareesh,

The bootloader program is programmed into flash through JTAG. Why do you ask this?

Please provide clear information on the complete sequence of bootloader programming.

1. Bootloader transfers code through which peripheral?
2. Where is the bootloader programmed?
3. From the time the device is powered on, what is the bootloader supposed to do?
4. When and how is the bootloader invoked?
5. Did you read through the debug tips that Lori has provided?

Hareesh,

sorry that my previous describe is wrong:

When the board is not connected to CCS, the code cannot reset the device, so the device will not go to the updated application code to run.

In fact it's wrong, we measured the XRS pin and find it's always toggling, meaning that after the watchdog reset, the device is always resetting for some reason.

Then we tried to debug through Lori's suggestion.

And we tried with our C2000WARE example code.

1. Flash the device  with C:\ti\c2000\C2000Ware_3_02_00_00\device_support\f2806x\examples\c28\flash_f28069
2. Turn off the power
3. Connect CCS and select "load symbols" only
4. 
5. Place a breakpoint at the entry point to flash// I've no idea where should I put it, is it at the start of codestartbranch.asm? 
6. 
7. Is this the correct point to insert the breakpoint? But it's grey.

we measured the XRS pin and find it's always toggling, meaning that after the watchdog reset, the device is always resetting for some reason.

One reason why this happens is because the flash is empty. After programming, did you check the flash contents to make sure it got programmed? Did you check the password locations?

I've no idea where should I put it, is it at the start of codestartbranch.asm?

Yes, but you cannot set a BP at lines 81 or 83. It is likely WD is disabled in your project, so you should be able to set a BP at line 82. Bear in mind this is in flash, so it has to be a H/W BP.

Hareesh,

we tested according to Lori's procedure and we could not reproduce the problem, it behaves the same way as we connect CCS.

The code frame is:

main

{

if(application code is updated), run application code,

if(application code is not updated), run bootloader code(receive new application code through SCI, erase old application code and program new application code, then reset through watchdog)

}

We've no idea how to debug it anymore.

 Hareesh: After programming, did you check the flash contents to make sure it got programmed?

Howard: How to check it? Connect to CCS and read all the memory?

Hareesh: Did you check the password locations?

Howard: How to check it? Connect to CCS and read all the memory? Why do we need to check the password?

Howard,

                Sorry I still don't understand what problem we are trying to solve. There are 2 scenarios: 

1. Normal code execution. This is what application will do most of the time.
2. Code update required. Run bootloader code(receive new application code through SCI, erase old application code and program new application code, then reset through watchdog). 

Important question is how is #2 determined? That is, how does the application know code update is warranted? What decides normal application run versus code update? 

You have not answered my earlier questions:

1. Where is the bootloader programmed? Is the SCI bootloader in boot-ROM invoked or is the SCI bootloader part of flash?
2. From the time the device is powered on, what is the bootloader supposed to do?
3. When and how is the bootloader invoked?