LMFlash vs RTS and DTR serial signals

Hello Nlen,

TM4C does not require DTR and RTS signalling. However it is not clear from the post that how have you connected the FT232 to the TM4C device. In TM4C on completion of the flash download and after a Reset Request is made by LMFlashProgrammer, the CPU makes a software reset request

Regards
Amit

Hi Amit,

I understand that the TM4C does not require DTR and RTS signaling.  I want to use DTR and RTS as RESET and ISP signals from USB.  Here is part of my small custom board showing the FT232 and how DTR and ISP are connected to RESET and ISP respectively. If LMFlash Programmer would not affect The DTR signal, I would be able to use DTR as a RESET signal from the USB port without having to use the push buttons to put the TM4C in bootloader mode or perform a reset.  This board was originally designed to be used with a NXP microcontroller the NXP flash programmer (Flash Magic) is using DTR and RTS for this purpose. I would really like to continue using this strategy with the TM4C.

Hello Nien,

I am not sure what ISP signal stands for.

However for the reset DTR will be a driven signal, from the FT232 device, unless the flow control is disabled in the FT232 device. The LMFlashProgrammer tool does not know about how the flow control is hooked up on board, so it will handshake with the FT232 which in turn will handshake with the Device.

Regards
Amit

Hi Amit,

ISP is the original NXP signal name. TI does not really give a name to this signal. I refer to the page 551 of the spec sheet for the TM4C1231H6PGE device. It's the GPIO defined into BOOTCFG register to force the device to the bootloader mode. In my case, it is connected to PA0/U0RX. When attempting to program with LMFlash, I make the following sequence with the 2 signals :

1. Set RESET and PA0/U0RX ACTIVE
2. Set RESET INACTIVE (PA0/U0RX remains ACTIVE)
3. Set PA0/U0RX INACTIVE

The TM4c is then in bootloader mode and listening to the serial UART connection. I do this with the 2 push buttons displayed in my previous post.

Concerning the FT232,  you seem to tell me that the FT232 is reponsable for the DTR signal being driven during the serial communication.  I was always under the impression that it was the serial port configuration which was responsable for driving the DTR signal.  If flow control is disabled in the serial port configuration (Not in the FT232 registers), then the FT232 has no reason to drive that signal.  At least this is the behavior I observe when using Flash magic with my NXP device.  DTR is not driven and the microcontroller does not reset. I did not change the FT232 default configuration since I use it.

More preciseley, with LMFlash, I observe that when initiating flash programming, DTR and RTS are set to ACTIVE both at the same time in the beginning.  Then, RTS will TOGGLE INACTIVE and programming will start.  DTR remains ACTIVE steady for the whole programming process.

When using UNIFLASH as you suggested for my other post, I observed that DTR is not Driven during the first part of programming which seems to work (Up until 30%).  Then I get an error for which I ignore the cause.  I have posted my log in my other post but here it is again :

[14:31:32] Begin Writing flash memory operation.

[14:31:32] Loading program at 0x0: C:\z\LabTestsFullImage_1.90.bin

[14:31:55] ERROR >> Cortex_M3_0: <!>Serial Communication exception: Timeout expired

[14:31:55] ERROR >> Cortex_M3_0: GEL: File: C:\z\LabTestsFullImage_1.90.bin: Load failed.

[14:31:55] File: C:\z\LabTestsFullImage_1.90.bin: Load failed.

[14:31:55] Operation Writing flash memory returned.

If I was able to perform a full programming with INIFLASH, it could be my solution because DTR is not driven and I should be able to set the TM4C in bootloader mode using the signals from serial port by programmation.

Best Regards

One more thing :

Another solution which was suggested to me by a collegue is that I could configure a different signal of the FT232 as an output. The serial port only has 2 outputs but the FT232 has apparently 4 pins which can be configured as outputs. I will need to reprogram my FT232 in order to do this and make a small hardware modification on my interface board to link this different output to PA0/U0RX instead of DTR. While trying this solution, I will double check if really I can disable flow control from within the FT232 or if it's really LMFlash that is responsible for driving the DTR signal in the first place. I'll let you know how it goes.

Nien

Hello Nien,

I think the problem is that PA0 which is one of the boot loader pins (UART boot loader) if configured to be a GPIO may not be reverting back to UART function thus stopping the boot loader. You may want to check if you can use another pin on TM4C123.

Regards
Amit

Hi Amit,

I may not understand properly what you mean. If this pin would not revert to UART functions, I would never never be able to program the TM4C with LMFlash. Not even after opening/closing the COM with Realterm. Or maybe you meant that for the UNIFLASH application stopping at 30%?

I am sceptical but curious so I will try to configure a different pin to BOOTCFG. However, in order to reprogram the BOOTCFG register, the reset init sequence seems like a real pain. Would you have a software tool already availlable to reprogram the BOOTCFG register?

My team is reluctant to change this because it would mean a PCB revision for our product for which development is well advanced.

Meanwhile, I continued my FT232 exploration and I am now using a different signal than DTR for the reset of the TM4C. I modified my interface board to connect CBUS3 pin in I/O mode to The reset of the TM4C. Therefore I am no longer affected by LMFlash driving the DTR signal.

A change of plan had me assigned to something else so it may be a while before I get to test a different GPIO configured in BOOTCFG

Best Regards
Nien

Hello Nien,

The 30% status may be an indication of UNIFLASH engine operation and not necessarily 30% of the download.

Nienscecco said:

1. Set RESET and PA0/U0RX ACTIVE
2. Set RESET INACTIVE (PA0/U0RX remains ACTIVE)
3. Set PA0/U0RX INACTIVE

I was referring to PA0 being used as Boot Cfg.

Regards

Amit