RTOS/TM4C1294NCPDT: Programming the TM4C

Hi Priya,

After the code is programmed it is stored in the flash memory. The flash is a non-volatile memory which means it retains the content of the memory even after power off. Is this your question?

Charles,
There is the JTAG interface and the uart serial port (FTDI interface) through which the custom board can
be programmed. If the uart interface is used, is it possible to re-program the chip? The MCU got locked and
we don't have the means to erase the flash through the FTDI interface as can be done through the JTAG with
the LM flash programmer.

Thanks,
Priya

Priya,

 What do you mean it is locked out? Are you using the ROM-based UART bootloader or the flash-based UART bootloader?

 You can configure the BOOTCFG register so that the bootloader will download your application firmware when your specified GIO pin changes state. Please refer to the datasheet for details.

Register 68: Boot Configuration (BOOTCFG), offset 0x1D0

Note: Offset is relative to System Control base address of 0x400F.E000.

Note: The Boot Configuration (BOOTCFG) register requires a POR before the committed

changes take effect.

This register is not written directly, but instead uses the FMD register as explained in “Non-Volatile

Register Programming-- Flash Memory Resident Registers” on page 613. When this register is

committed, the new value cannot be read back until after the power cycle. This register provides

configuration of a GPIO pin to enable the ROM Boot Loader as well as a write-once mechanism to

disable external debugger access to the device. At reset, the user has the opportunity to direct the

core to execute the ROM Boot Loader or the application in Flash memory by using any GPIO signal

from Ports A through H as configured by the bits in this register. At reset, the following sequence is

performed:

1. The BOOTCFG register is read. If the EN bit is clear, the ROM Boot Loader is executed.

2. In the ROM Boot Loader, the status of the specified GPIO pin is compared with the specified

polarity. If the status matches the specified polarity, the ROM is mapped to address 0x0000.0000

and execution continues out of the ROM Boot Loader.

3. If the EN bit is set or the status doesn't match the specified polarity, the data at address

0x0000.0004 is read, and if the data at this address is 0xFFFF.FFFF, the ROM is mapped to

address 0x0000.0000 and execution continues out of the ROM Boot Loader.

4. If there is data at address 0x0000.0004 that is not 0xFFFF.FFFF, the stack pointer (SP) is loaded

from Flash memory at address 0x0000.0000 and the program counter (PC) is loaded from

address 0x0000.0004. The user application begins executing.

Charles,
I don't know the specifics of the bootloader code, I don't have that firmware. Using the FTDI interface, Stellaris firmware was downloaded on a TM4C board. Is this likely to cause permanent damage to the board? The board would not re-program on the FTDI interface. It was re-programmed using JTAG. This board is not responding to the custom application. It was in the past. A new version of TM4C firmware was loaded; no response to application, Stellaris firmware was loaded, old version of TM4C firmware, no response to application again.
Thanks,
Priya

Priya,
I think I'm a bit confused as to what debug probe you have on your device. On one hand you talk about JTAG and another you talk about FTDI. Normally FTDI is used as a USB to JTAG and/or USB to UART converter. I think you have a custom board, correct? What JTAG-based debug probe do you have for your board? You said you are using the FTDI interface via the UART serial port to download the code. When I asked you if you are using the UART bootloader you said no. This is where I'm confused. If you don't have a flash-based bootloader running then how do you download your code via the UART port? Or are you using the ROM-based bootloader that already comes with the TM4C chip? In any case, your question is how to program/erase the flash again via the UART. My earlier answer is that if you can instruct the bootloader to update the firmware by configuring the BOOTCFG so that GPIO pins can be used to start the firmware update even if the flash has already contained your old firmware.

Both probes were tried to program the board. The FTDI probe is used with an internal firmware programming tool which must have the bootloader code in it, I can find out on Monday. This combination has been used to program stellaris custom boards already in production. It could also program one version of the TM4C firmware in the past successfully.

The new custom board has the TM4C. In error, the FTDI interface was used to program stellaris code into the TM4C custom board. Is this likely to damage the board? It will help greatly if you answered this question. The FTDI pins are mixed up between the stellaris and TM4C.

The JTAG interface connector was put together by jumper wires with an obsolete debug board, this was tried to fix the programming problem today. This helped program the board successfully when the FTDI interface would not do so anymore. However the custom board is not responding to the application with either programming method.

Your response is much appreciated.
Thank you,
Priya

Charles,

Thank you for your reply. I don't have the schematic in front of me now, but I think the FTDI rx

and tx pins are in different order between the Stellaris and TM4C. System clock for Stellaris is

80 MHz and TM4C 120 MHz. At this time, only one TM4C board is available, more have been

ordered.If the MCU is bricked on this board, it can be replaced. Let me know if you have further

comments.

Thanks,

Priya