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.

TM4C1294NCPDT: Invoke Reset after flashing Application onto Bootloader

Part Number: TM4C1294NCPDT

Hi,

I was wondering if there was a way to invoke a reset after flashing an application onto the bootloader with LM Flash Programmer. Currently we are using a custom board and didn't design access to a reset pin and such.

It uses a working Arduino bridge between the LM Flash Programmer and TM4C chip i.e.

LM Flash Programmer -> UART -> Arduino -> UART->TM4C 

The examples we have used are boot_serial/boot_demo1 examples, we have tried it on the XL booster board by itself and works, we just wanted to transition this onto our custom board. 

I'm deducing from the assembly code that the bootloader looks for a reset ISR before it allows it to flash the obtained application, is there a way around this?

Kind regards,

Tyson

  • Hello Tyson,

    The LM Flash Programmer allows you to reset the target MCU, so make sure that is being selected:

    If that is selected, then the issue is going to be with the Arduino bridge.

    For our boot loader, there are two commands that trigger a system reset that can be sent: COMMAND_RUN and COMMAND_RESET

    If the board is not resetting even with LM Flash trying to reset the MCU, then the Arduino is not sending these commands properly. At that point, I can't offer any advice on how to get the Arduino to do so.

    Best Regards,

    Ralph Jacobi

  • Hi Ralph,

    Thanks for the reply. 

    Yes we have tried with selecting the Reset MCU After Program button but there hasn't been any success with doing this. We also tried using a hardware triggered reset via reset pin and switch however there was no luck there as well.

    I gathered that using the Arduino should be a similar way that the onboard TM4C123x works on the evaluation board, so technically we should be able to.

    Based off the Evaluation board, is the TM4C123x simply used as a bridge to the 1294 chip or is there filtering between USB and the 123 chip?

    Does the TM4C123x manually set the COMMAND_RUN and COMMAND_RESET functions based off the LM Flash Programmer Acknowledgement or does it do this as soon as it sees UART packets coming through?

    Cheers,

    Tyson

  • Hello Tyson,

    I never wrote the source code for the ICDI interface but there is code that executes to handle the programming, it isn't just a pass through.

    I presume that the UART commands for COMMAND_RUN and COMMAND_RESET are received by the ICDI and then it handles using them as needed. LM Flash programmer is setup specifically to work with our ICDI interfaces and with the ROM boot loaders. Supporting other debug probes is not part of it.

    To me the issue clearly is with the Arduino board implementation which doesn't surprise me as I've not heard of that kind of board being used before - all customers who use LM Flash to program non-evaluation boards use another LaunchPad for debug or ROM boot loader. You can see how in this document: https://www.ti.com/lit/pdf/spma075

    Best Regards,

    Ralph Jacobi

  • Hi Ralph,

    Thanks for your response again. 

    I do agree it is the Arduino bridge implementation is the issue here. To give more context, we were planning to implement FOTA through USB and the only way to access the TM4C outside of using the XDS110 we have is the Arduino via USB. 

    Technically it should be possible however without the code of the ICDI interface, I think it would not work at all. Are there any other possibilities for flashing an application to the bootloader via USB with an Arduino Bridge or do we have to look at different avenues for solution for our end?

    Cheers,

    Tyson

  • Hello Tyson,

    Maybe you can look at our sflash application in TivaWare: C:\ti\TivaWare_C_Series-2.2.0.295\tools\sflash

    Usually that is used for USB -> UART over FTDI cable but perhaps it could work with the Arduino? That's my only other suggestion.

    Best Regards,

    Ralph Jacobi