• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 28 subscribers
  • Views 647 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DLPC350: System bricked after loosing power during firmware update, skipping bootloader update.

Anders Guldahl
Intellectual 385 points
Part Number: DLPC350

How can we implement a safe updating procedure for the main firmware? When using the Lightcrafter GUI to update main firmware, skipping bootloader update, it seems there is still a small chance that a power-cut at the wrong time will brick the unit. Reading out the flash-data over jtag confirms that the bootloader is still in place, but the system does not boot correctly, and does not enumerate on usb so we cannot fix this without a jtag adapter. 

Our observations so far:
* Only bootloader in flash, the rest 0xFF, works ok.
* Bootloader + some random part of main firmware in flash, system is bricked, need JTAG to recover.

What part of the main firmware does the bootloader check before launching the main firmware? 
Is it possible to modify the update-procedure to eliminate/reduce the possibility of a bricked unit after aborted update?

  • 0
    TI__Mastermind 20045 points
    Hello Anders,

    I will look into this. Could you confirm what firmware and GUI version you are using?

    Thanks,
    Kyle
  • 0
    Prodigy 20 points
    Hi Anders,

    This is the purpose of the Boot-Hold signal which is usually a jumper on most boards. It will keep the DLPC350 from fully booting (or attempting to) on power up and instead remain in the bootloader. If you lose power during an upgrade, the bootloader will still be available and the embedded DLPC350 will not try to jump into the new code section until you remove the jumper. You do need to skip the bootloader during the update to be safe which you already stated you were doing.

    Best Regards,

    James H.
    Embedded Systems Engineer
    Keynote Photonics
  • 0 in reply to James Headley
    Intellectual 385 points

    ok, thank you for the answer. Only issue with that is that in an integrated system where the PCB is not easy to get access to, we then need a separate microcontroller to toggle the hold_in_boot pin. Seems like TI have made quite an effort to make the formatter able to act as a standalone system with all the GPIO-pins etc. and usb-connection. A bit unfortunate then to require an external mcu to make safe firmware upgrades. Anyway, we're implementing an external mcu on the next revision, so we can use that. Thanks for the help.