• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 32 subscribers
  • Views 590 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.

Field Upgrading the LM4F232H5QD

Charles Smith
Prodigy 140 points

     I'm reading through the docs on Bootloader operations for our eval boards of the  LM4F232H5QD - specifically the ROM libraries.  We need to have the capability of upgrading our micros in the field via the USB connection.  I see that we can place the board in the USB DFU protocol mode from within a running application which is good. I also see where if the first two bytes of the Flash are empty, it automatically goes into USB DFU mode - is this right?

 

     Also, what would happen in the third scenario where a user is field upgrading the chip (via USB DFU mode) and they lose power part way through the process.  As result, the First two bytes of the Flash are not empty and the application has not been fully loaded.  Would this in turn cause the device to now be "bricked" ?  Or is there a way to work with this condition?

  • 0
    TI__Expert 7555 points

    Hi Charles,

    The Stellaris family of microcontrollers certainly allows for field updates via the USB connection (via the USB DFU).  To address some of your questions:

    If the first two words of the MCU's on-board flash memory are blank, the MCU will enter the ROM-based bootloader after a reset.  Blank memory is defined as all bits being high (the typical state for blank flash memory).  This information can be found in the LM4F232H5Qd ROM User's Guide. 

    Were you planning on implementing a ROM bootloader or a flash bootloader?  In the StellarisWare folder, there are some sample projects that utilize the flash bootloaders.  If you were planning to implement a flash bootloader, these may be helpful.  They can be found in the EK-LM4F232 board folder.  If you plan to use the ROM bootloader, I can look for some more information on that approach.

    To address your third scenario: when flash memory is erased, all of the bits in a block are set to 1 (high).  Since those first two words in flash should never be anything besides all 1's, you shouldn't face a lockout.  I'd like to see if the Stellaris team has any comments on this, however.

    Regards,
    Walter

  • 0 in reply to Walter Schnoor
    TI__Expert 7555 points

    Charles,

    I wanted to follow up with some comments from the Stellaris experts.

    1. The USB DFU mode is currently not supported in the ROM bootloader.  Therefore, to implement USB DFU, you will need to create a flash bootloader (see code examples above).  This bootloader should be placed at the beginning of flash.  Placing it at the beginning of flash will prevent entering the ROM bootloader after a reset, which is the behaviour you desire since you want to enter your flash bootloader after a reset.

    2. When user is upgrading the chip via USB DFU, the application already gave control to the boot loader, therefore if there is a power fail the boot loader should be smart enough to detect that the application was not fully programmed (checksum or Key at the end of the flash) and stay in the boot loader. At this time the user could re-start the upgrade.

    Please let me know if this needs any clarification.

    Walter

  • 0 in reply to Walter Schnoor
    Guru 117855 points

    @ Walter:

    Thanks for this - detailed and helpful.  Believe one issue remains - with a valid update, "in residence" (proper - w/in MCU Flash) how does one then, "Update the previously installed Update?"

  • 0 in reply to cb1_mobile
    TI__Mastermind 30085 points

    Hey cb1,

    I don't fully understand the question but I think I know what your asking, but let me know if I'm not close. :)

    cb1_mobile said:

    How does one then, "Update the previously installed Update?"

     
      Basically, the bootloader would be called from the application when the applicationrecognizes when a specific command or sequence is sent via the USB.  This also allows the USB to be used as a standardly during the application.  When you update in this situation, you wouldn't overwrite your flash based bootloader.  The bootloader would need to skip the section of flash it, it's self, is located.  There are other ways of doing this as well of course.
     
     
     
    @Charles (and future readers), for you last question, if some how the chip lost power during programming and the first 2 bytes are not empty, then the stellaris is going to start running code at that point, whatever that code might be.  If these were empty, then the ROM based bootloader would be triggered (which unfortunatly wouldn't help you in this case Charles). 
     
    If you are using the bootloader for field updates to the chip and the ROM based bootloader wasn't triggered, then you would be locked out.  The chip wouldn't truely be bricked though, and could still updated/erased via JTAG.  In your Flash based bootloader, you could make more sophisticated checks, such as a check sum and other things to hopefully reconize that there was a failure and auto trigger bootloading.   
     
    EDIT: Made some small corrections in this post (1/11)
     
    Thanks,
    JD
  • 0 in reply to JD Crutchfield
    Guru 117855 points

    Ciao J.D.-

    Thank you - earlier post by Walter did not detail the potential for Updating a valid application program - installed correctly w/in the MCU's flash.  (hope this description is more clear)

    Your mention of a "specific command - or sequence" suggests that indeed - our field users may "update" an existing application program with a newer one - thru correct use of the command or sequence you've noted - even when their MCU board is thousands of miles from our facility.  (and use of JTAG/SWD is not an option)

    Believe that is the "missing link" from the earlier (still helpful) post - again thanks...

  • 0 in reply to cb1_mobile
    TI__Mastermind 30085 points

    Right cb1. 

    The "magic packet" as we'll call it, would have to be set up in the application itself.  You just have to call your Flash based bootloader, or one of our ROM based ones, from the application once the "magic packet" has been detected.

    I attached the boot_demo_eth.c for the LM3S9D96.  It's an example showing a "magic packet" triggering and Flash based ethernet bootloader.  It might be a decent reference for some to look at.

    Thanks cb1 for taking time to be so active on the forums!

    Regards,

    JD

  • 0 in reply to JD Crutchfield
    Guru 47900 points

    @ J.D.

    Once again - xtal clear - now even this reporter, "gets it."   (and how rare is that!)  Further - just love your, "Might be a decent reference..." superb understatement. 

    In now immortal words of one Bartholomew Simpson, "Nobody saw me, I didn't do it, you can't prove it."  Still, damn judge would not accept my, "Non Compos Mentis" plea - "work release" stipulates that I "haunt" this/other ARM forums...

    Your detailed and caring, focused response acknowledged - and much appreciated - merci mon ami...