soft reset

Evs,

You can use the watchdog timer to perform a software reset.  Something like:

void watchdogReset(void)
{
DISABLE_DOG();

// Set up for reset (in case set up for interrupt):
EALLOW();
SysCtrlRegs.SCSR = 0; // reset, not interrupt
EDIS();

ENABLE_DOG(C28X_WD_DIV_1);

for (;;) ; // wait for your reset
}

Bill,

 Thanks for the suggestion.

I changed it a bit to this:

      SysCtrlRegs.SCSR =0x0;    // Set wdog overflow for device reset.
     SysCtrlRegs.WDCR=0x0;  // Set WDCHK 000 to trigger reset

Only I end up.  at:

3ff4fa:   7625        ESTOP0    

If Im correct that is in the Bootloader Functions eara.

How do I change it that is goes to the correct start address?

Thanks!

The reset works just like a cold boot.

I don't think you're going to be able to use this software reset function in the way you want, that is, connected to the debugger.  FLASH your application, get it working, and then add the software reset.

EVS,

Based on your messages, it looks like you have been successful in reseting the device using WD.

Now, I believe you are expecting your application code (which should be burned in flash) is not being executed correctly but instead you are stuck at 0x3FF4FA.

Did you verify your boot mode pins? Are they configured to boot to flash?

Did you make sure you have mapped your begin function to flash entry point of the device?

Below link should be extremely useful to debug your problem.

http://processors.wiki.ti.com/index.php/C2000_Flash_Common_Issues/FAQs#Running_Code_Standalone

Regards,

Manoj

Hello,

Is there a solution for the CPU halt at 0x3ff4fa?
I am stuck with the same problem. I would like to implement a software reset by watchdog, but the CPU is halted at 0x3ff4fa after the watchdog reset.
I am using an F28069 MCU with SYS/BIOS, executed from flash. The program can start in standalone mode correctly after the power up, so the boot mode and the code start method is correct (with BIOS boot management). It seems like the watchdog reset is somehow different from a powerup reset, and cannot jump to the reset vector.

I would be really glad, if there was a solution, I have never had similar problem with other MCUs.

Thank you!

Peter

Hello,

I have just solved the problem.

I am testing now with a TMS320F28069 control card and base board. On the base board, there is a 14 pin Texas JTAG header, and I checked the nTRST pin on it, which is at 3.3V voltage, even without the debugger. The primary bootloader checks the state of this pin, ans sees that it is in high state, probably because of the on-board emulator. Thus the bootloader starts the emulation boot mode, and checks the EMU_KEY and EMU_BMODE memory locations, and the invalid values cause that the bootloader goes to Wait_Boot state, and probably that is what happened.

I made a workaround in my application code, so I set EMU_KEY to 0x55AA, and EMU_BMODE to 0x000B (Boot to flash), and after I made a reset by watchdog as previously wrote down in this topic, and now the reset works, the program starts correctly afterwards.

This is how I implemented reset now:

DINT;
EALLOW;
EmuKey = 0x55aa;
EmuBMode = 0x000B;
SysCtrlRegs.SCSR = 0x00;
SysCtrlRegs.WDCR = 0x20;
EDIS;
while(1);

I checked the schematic of the TMS320F28069 control card, and there the nTRST pin is pulled down correctly. I have not found the schematic of the docking board, but the source of this problem probably comes from there. It would be good if there was a jumper on the docking station to completely disable the on-board XDS-100 emulator, so it would not affect the nTRST pin.
 

Best regards,

Peter

Hi Peter,

Glad you were able to resolve this. I think you should be able to find the docking station schematics somewhere in ControlSUITE in the directory:

.\controlSUITE\development_kits\~ExperimentersKits\