• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 376 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.

TM4C123GH6PM: Processor Locks Up During Update Process Using ROM-Based Bootloader

Mpekatsa
Prodigy 90 points
Part Number: TM4C123GH6PM

Hello all,

Currently i'm developing a ROM-based bootloader using UART0 on the TM4C123 processor. So far, i have managed to update the firmware using a script i developed in Python. However i have seen that sometimes when i cut the power (intentionally) during the update process, i'm not able to continue the update from where it left and i have to re-program the device using the LM Flash Programmer.

It seems that the device locks up after the DOWNLOAD_COMMAND is sent and remains locked until the update process finishes (which is totally understandable to me). Nevertheless, i'm still struggling on how to recover the update process either from where it left or start the whole update from the very beginning. Also, when the update process starts i have put as APP_START_ADDRESS the 0x0000 and as far as i know, starting from this address will erase the entire flash. Thus, if something happens after sending the DOWNLOAD_COMMAND, then the target device is 'bricked' and i cannot reprogram it using the script i developed but only with LM Flash Programmer using ICDI interface.

So, my main question is how can i recover the UART communication with the target device and instruct the bootloader to continue or restart the update process? The situation of power or any other failure during remote update process could be 'catastrophic' (depending on the application), so i'm trying to figure out how i can put the device into 'recovery' mode and start over with the update process.

Thank you in advance for your help (and sorry in advance if i couldn't communicate my issue completely, i will try my best to give more explanation if needed :) )

  • 0
    TI__Guru**** 191886 points

    Hi,

      The ROM bootloader will first check if there is a valid stack pointer and the reset vector at 0x0 and 0x4. If these two locations contain non-F values, then the bootloader thinks that there is already an application present. It will just jump to the application. However, your bootloader process didn't complete successfully due to the power loss, the application program image is only partially programmed. You are left in a state where the application does not run and the bootloader does not start since it thinks the application is already there. I don't really see a solution for this. 

      I will suggest you try the flash-based bootloader instead. In the flash-based bootloader you can enable runtime CRC checking. Please see below excerpt or go to the TivaWare bootloader user's guide for detail. 

     

  • 0 in reply to Charles Tsai
    TI__Guru*** 135355 points

    Hello Charles and Mpekatsa,

    The Flash Boot Loader should be the best solution, but there is another possible method here though not as simple as using the Flash Boot Loader. Using BOOTCFG can allow the ROM Boot Loader be forcefully invoked via a GPIO state. The process here would be to commit the BOOTCFG with a specific GPIO to check the state of, and then have a push button or a test point that is able to assert that specific signal. The challenge here is the signal assertion. But if you are just looking for a way to recover ROM Boot Loader operation in rare cases where a button can be pressed to do so or something like that, then this would be an option.

    Details for BOOTCFG can be found on Page 581 of the Datasheet.

    The other tricky aspect here is that this would require initially loading the BOOTCFG register with the right value which would be an added step in the process as that would also require loading a program, but you could load a very small one with basically zero chance of power loss during. All the program would need to do is configure BOOTCFG and then invoke the ROM UART Boot Loader again.

    Anyways, I still second the idea of using the Flash Boot Loader but wanted to mention this other option.

  • 0
    Guru 55913 points

    Mpekatsa said:
    when the update process starts i have put as APP_START_ADDRESS the 0x0000 and as far as i know, starting from this address will erase the entire flash.

    Perhaps you can CCS debug and view the FLASH memory contents that did or did not get written? I recall seeing TM4C1294 Flash Boot loader scrambling FTP client data transfers from the network after DMA descriptors were introduced to EMAC0. So network transfer speed or timing may be part of the issue at hand. 

    Mangling FTP data never seemed to occur with Stellaris EMAC data transfers, seemingly CRC would be a good option to add.  

  • 0 in reply to Charles Tsai
    Prodigy 90 points

    Hi Charles,

    Thank you for your reply. (Also thank you Ralph and BP for your replies as well)

    Your suggestion answers my question to be honest. I don't see any other solution on recovering/unlocking the processor if something happens during the update process.

    The only solution that worked so far  when using ROM-based boot loader (as I mentioned before) is to reprogram the processor with LM flash programmer or with the IDE. However, this could be extremely inconvenient if we want to perform remote update of the firmware, since we might not have physical access to the board. So, a flash-based boot loader that will reside at the beginning of the flash, will do the job.

    Thanks again for your replies :)