• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 622 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28379D: Prevent a register or RAM initialised by the boot ROM

VIKTOR SOUKAL
Prodigy 30 points

Part Number: TMS320F28379D

Hello,

I'm designing a custom bootloader for this specific MCU and I'm struggling to find a support for traditional approach described as follows:

1. after POR, MCU executes boot rom routines and jumps to loader located at 0x80000. It figures out it was POR and jumps to bootloader code, e.g. at 0x80020

2. assuming there's no pending reprogramming request, bootloader figures out the flashed application is correct (e.g. at 0x82000), writes a magic value into either a register, which maintains its value through non POR resets or to dedicated memory NOT initialized by the boot rom and performs software (watchdog) reset

3. after reset, the loader figures out it was a software reset thus the magic value is valid and jumps to the application entry point instead of bootloader's one

It seems all RAMs are always initialised by the boot ROM after any reset (unlike to e.g. piccolo devices), including WDRST therefore it's not possible to pass any information through resets. There doesn't seem to be a register, which is not initialised after reset either.

Can you please suggest intended approach for this device?

Thank you.

Viktor Soukal

Ricardo Prague

  • 0
    TI__Genius 17370 points

    The way it is typically done is to wait on peripheral boot loader say SCI (uart) for predefined time. If a new image is sent then it is updated on to flash. Otherwise it proceeds to run existing image in flash.

    The other way to do is to connect an external resistor and cap to GPIO and control the boot mode through that. We have published an app report recently on this approach - http://www.ti.com/lit/an/spracn1/spracn1.pdf

  • 0 in reply to Baskaran Chidambaram
    TI__Guru** 117431 points

    Hi,

    3. after reset, the loader figures out it was a software reset thus the magic value is valid and jumps to the application entry point instead of bootloader's one

    Does your bootloader reads the magic value to know if it's valid or invalid or if it's SW reset (WD reset) then it assumes magic value is valid. If it's IInd case (which I think may not be) then you can always read the RESC register to know if reset was due to WD.

    If it's the Ist case (bootloader reads magic key) , then you are right that on this device all the RAMs are initialized to 0x0 by BOOTROM hence RAM can not be used to store the magic key. We do have few registers which are not cleared on WD reset and can be used for this purpose if not using the HIBERNATE mode on this device.

    Basically if you are not using the HIBERNATE feature of this device then you can store the magic key in HIBBOOTMODE [31:8] (please leave value in [7:0] bit field to default) register  and use that.

    Hope this helps.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 30 points

    Hello Vivek,

    Thanks for your reply. Since I don't need hibernation feature, the HIBBOOTMODE register is exactly what I was looking for.

    Regards,

    Viktor