TMS320F28379D: Software reset into bootloader and request firmware update

Hi Dieter, 

The most common method that is generally accepted in the industry is, upon a reset the bootloader waits for a short time period polling for a command from the host indicating that there is a firmware update available.  That command is then acknowledged by the bootloader to initiate the firmware download and flash update.

If there is no command from the host then the bootloader simply launches the application that is already available. 

If there is no application available, or if it is invalid (determined by some application specific criteria) the bootloader simply waits until there is a firmware update available.

If the application firmware is already running and if it has the ability to accept commands from some host, then one of the commands that the firmware could support is "firmware update available"  If such a command is received then the application can just branch/jump to the bootloader.  

If the application is totally independent, once launched and there is no external communication at all then we would have to think about an alternate solution...but no possibility of external communication is rare. 

Please let us know if these ideas help...and if you have a specific case where none of the above will work for you. 

Regards,

Krishna

Hello Krishna,

thank you for the answer. Of course we thought about just branching to the bootloader code. But this would mean to bring the controller in a state, as it would be just after cold boot: Disablinging interrupts and DMA, deinitializing peripherals, stopping the CLA, perhaps clearing RAMs, ramp down the PLL, ...
A software or watchdog reset would do that all for us. But there is still the problem of the RAMs initialized by the bootROM code.

And yes, the bootloader could just listen for a period of time for any commands after any reset.
But we are looking for a method that keeps the bootloader a simple as possible.

Any idea left?

Regards
Dieter

Hi Dieter, 

Can you point me to where you see what you stated here: 

              The refernce manual states that all memories are initialized by the bootROM code. 

Have you actually seen the clearing of memories upon reset and if so which ones?

Thanks,

Krishna 

Hi Krishna,

this is about the RAM init:

and this is about the open question how to force a software reset:

So "trap 0" seems not to be the right way.

Regards
Dieter

Hi Dieter, 

Sorry about the delayed reply...we are looking into what you have reported and will get back to you shortly.  In the mean time, if you have any new findings on your side please let us know. 

Regards,

Krishna

RAM gets initialized only in Power On Reset. It doesnt get initialize in XRSN (watchdog) reset. So you can store flags in RAM and use it in the next cycle. Just make sure the location is not touched by any other code.

So the RefMan doesn't tell the whole truth - fortunately for our issue.

This should be corrected in the next document version. Thank you.

Hi Dieter, Please let us know if your issue is resolved.  We will follow up on the documentation on our side. Regards, Krishna 

Hello Krishna,

now I had the time to test your suggestion to use the watchdog reset.
Unfortunately the RAMs are all initialized with 0.
I tested RAMM0, CLA1_MSGRAMHIGH, RAMLS0, RAMD0, RAMLS3 and RAMGS13. All the same behavior.

I found this explanation also in the chapter of the watchdog in the RefMan:

So it seems that the RefMan tells the truth and not only Power On Reset initializes the RAMs.