• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 82 subscribers
  • Views 1062 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.

F28835, Bootloader design query

richard payne
Genius 4640 points
Other Parts Discussed in Thread: CONTROLSUITE

Hi

I'm working on hardware design and manager request for possibility to invoke bootloader mode by firmware/software in such way to avoid dependancy of using hardware link which upload bootloader code into F28335 Memory. If this is the case, please explain how. For exampke I connect to UART (SCI) and send command to invoke bootload mode, it would jump to (say) Sector H or ROM (bootloader code?), which contain ROM or custom bootloader and then take over UART for data transfer from PC to FLASH (Sector A-F). Is this possible solution?, what the best material to read abut this?. I seen quite lot of material in website. 

I'm getting a gist that the hard link that set Bootloader from SPI via EEPROM (during power up) actually mean downloading the bootloader application code into RAM and then run it, not necessary running bootloader mode where SPI is used to transfer program data.

Can you confirm which is which?

  • 0
    Genius 4640 points
    I believe I was looking for F28335 update firmware via CAN bus or UART bus solution, can you help?. I'm I correct this is nothing to do with boot load and pins?
  • 0 in reply to richard payne
    TI__Guru* 95315 points

    Richard,

    Not sure what you mean by "I'm I correct this is nothing to do with boot load and pins?". It has everything to do with the  boot-load pins. I suggest you read thru the Boot-ROM user guide to understand the flow of things. I also strongly urge you to read SPRABV4A. The whole app.note is about flash programming using the bootloaders.

     

  • 0 in reply to Hareesh Janakiraman
    Genius 4640 points

    Thank for Hareesh, I had a read on SPRABV4A and other materials. 

    The issue with this method defined in the SPRABV4A that it requires access to pin to make the link before POR. This pins will not be accessible for firmware update due to potting inside a sealed unit. Only CAN or UART port is available. My aim is to do the following. NB: In producton we use JTAG to install initial firmware. 

    (1) Issue command (CAN or UART) to enable firmware update, it cancel any existing operation mode confirmed this operation mode

    (2) Issue command to define program metadata and proceed this operation, a firmware updater (I would not call this bootloader) is transferred to RAM and it then clean the FLASH. It send ready for program data file message

    (3) PC send program data file and write to FLASH (using RAM as buffer page)

    (4) When completed, perform verify, CRC and report success, it do soft reset, otherwise it ask for repeat process 

    Is this possible in F28335?. I assumed FLASH API library cover all of these thing?, if not what additional code needed?

    I can see the snag that if firmware update is damaged or partially completed, then it impossible to update firmware unless we take out the board from sealed unit. Is there way around this?

    R. 

  • 0 in reply to richard payne
    TI__Guru* 95315 points

    Richard,

                I understand your situation better now. So, your product will not have access to boot-mode select pins and those pins will be permanently configured to boot from flash. This is OK. One idea would be this: You could send a control word (thru CAN or SCI) to signal the MCU that a firmware upgrade is warranted. The MCU could then terminate the application gracefully, write a checkbyte at a known RAM location and force a reset (thru the Watchdog). Upon reset, the value of this checkbyte could be read to determine whether to continue with the application or the flash re-programming process. If it is the latter, the application could do a function call to the appropriate function in the boot-ROM. From that point, things proceed like a normal “flash programming leveraging Boot-ROM functions” scenario. You could freeze one sector in flash (where code control jumps to upon reset and where the checkbyte is read), meaning that sector is never disturbed after it is programmed once. This should enhance the chances of recovering the device should some problem occur in the process of flash programming.

  • 0 in reply to Hareesh Janakiraman
    Genius 4640 points
    Hi Hareesh

    Can you please extend this answer if possible with demo program or such example we can try out. Perhaps explaining more details what you mean by checkbyte (not familar with this Jargon). Maybe step by step with more technical implementation details.
  • 0 in reply to richard payne
    TI__Guru* 95315 points

    Richard,

                I regret I do not have any demo program to share, but I can elaborate a bit with the following steps:

     

    1. Power-up and normal operation

    2. A firmware update is warranted, so the host (CAN or SCI compatible) sends a unique “Control word”. The CAN (or SCI) ISR interprets this control word and the 28xx MCU device recognizes that the host is requesting a firmware update.

    3. MCU terminates the application gracefully and writes a 16-bit check-word to a known RAM location. This could be a unique value like 0x1234. A reset is then forced thru the WD. (Since 28xx is a native 16-bit device, better to use check-word than check-byte. All it is is a value that indicates to the MCU whether to proceed with running the application or start the firmware update process).

    4. Upon reset, MCU always checks this known RAM location to determine whether firmware update is warranted.

    5. Since it reads the correct check-word, it does not proceed with running the application, but initiates the boot-load process.

    6. It does this by initiating a function call to the appropriate loader in the boot-ROM. You could load the symbols for the boot-ROM from the project included in Controlsuite. (C:\ti\controlSUITE\libs\utilities\boot_rom\2833x). The symbols will help you determine exactly where in the boot-ROM you want to jump into.

  • 0 in reply to Hareesh Janakiraman
    Genius 4640 points
    Thank Hareesh, much clearer, however where can I find out about these "control word" that F28335 trap this. What page in document cover this topic?
    Is there way for F28335 firmware to "insert"these control word into SCI or CAN stream. I like to send one ordinary command to close certain operation and then invoke "Control word" in....is this possible?, if so how.
  • 0 in reply to richard payne
    TI__Guru* 95315 points
    The "control-word" is something you make up. It is not covered in any document. Just to reiterate, the method I proposed is just an idea. There may be other ways to achieve your objective (of being able to update firmware without having to change the boot-mode jumpers). Also, when you choose the "control-word" you should choose a sequence of words that would seldom occur as part of normal communications.

    I presume you want to test this method without an external host. The SCI offers a loopback mode and CAN offers a self-test mode, where in you could have these modules send data to themselves. You could transmit a control-word thus.