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.

LMFlash.exe Build 1613 Open COM known known problem?

Other Parts Discussed in Thread: LMFLASHPROGRAMMER, UNIFLASH

Hi everyone.

I use LMFlash.exe build 1613 to program a TM4C1231 microcontroller though the UART port.  I connect to the UART through a custom USB-to-serial adapter based on a FT232 chip from FTDI.

I noticed that when first attempting to program the flash memory of the microcontroller, I always get an "**ERROR** Failed to synchronize baud rate with the board!".  If I open the COM port with another software (Realterm) and then close it, After that LMflash can sync with the TM4C1231.  Enabling or disabling auto baud does not solve anything.  On a first attempt to program, It will not synchronize unless I open/close the port with Realterm before.

I also tried opening and closing the port with other softwares. For example if I use Labview To Open/Close the port before LMFlash.exe, it does not work.  Realterm always clear the glitch though.

1. Has anyone observed the same situation?

2. Could you think of a certain option that Realterm sets by default so that it makes possible for LMflash to work?

My OS is Windows 7 pro.

I would like to get rid of this situation to be able to set an automated test sequence with TestStand

- Program flash memory with a test firmware using lmflash.exe command line interface

- Execute electric tests

- Program flash memory with latest firmware release using lmflash.exe command line interface

Thank you in advance

Nien

  • Hello Nien,

    I have used the FT232H with LMFlashProgrammer to download code with UART but never seen an issue. Can you

    1. Take a snapshot of the settings
    2. Can you check the default COM Port Settings?

    Regards
    Amit
  • Hi again Amit,

    Not sure if you mean the settings within Flash Programmer or within my device manager... Here is a snapshot of both.

    My OS is in french but basically this is default windows settings

    baud: 9600, Parity: None, Stop bit: 1, Control Flux: None

    When programming with Labview or LMFlash, I will open the port and set the settings to Baud rate: 115200, Parity: None, Stop bit: 1, Control Flux: None just like it is in LMFlash settings. I am able to program with LMFlash after an open/close of the COM with Realterm. And I am able to program the TM4C with Labview using the LMFlash.exe command line interface after I was able to sucessfully program it once with the GUI LMFlash.

    Regards

  • Hello Nien,

    That should never be the case. The LMFlashProgrammer does not a COM port application to be opened so that it can begin communicating, unless there is a driver issue. Can you check if the UNIFLASH application also behaves the same way?

    Regards
    Amit
  • You are right : I am never able to open my COM21 with Realterm and LMFlash at the same time.  I open the port with Realterm, then close it. And after that LMFlash will sync with the TM4C.

    As you suggested, this morning I tried UNIFLASH. It behaves the same apparently.  On first programming attempt, it doesn't work.  I get a timeout error like this log :

    [14:02:41] Begin Writing flash memory operation.
    [14:02:41] Loading program at 0x0: C:\z\LabTestsFullImage_1.90.bin
    [14:02:46] ERROR >> Cortex_M3_0: <!>Serial Communication exception: Timeout expired

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

    [14:02:46] File: C:\z\LabTestsFullImage_1.90.bin: Load failed.
    [14:02:46] Operation Writing flash memory returned.

    At this step, LMFlash doesn't work either.  If I open and close the port with RealTerm, then LMFlash works and so will UNIFLASH, but not as good as LMFlash because I am not able to perform a complete programming. UNIFLASH will start programming and does not update the progress bar while it programs.  I can see the RX and TX leds flashing on my USB-to-Serial interface board.  At some point, the LED Rx and Tx stop flashing and the progress bar get updated to the value 30%.  1 second later I obtain an error. Here is the log :

    [14:01:07] Begin Writing flash memory operation.
    [14:01:07] Loading program at 0x0: C:\z\LabTestsFullImage_1.90.bin
    [14:01:30] ERROR >> Cortex_M3_0: <!>Serial Communication exception: Timeout expired

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

    [14:01:30] File: C:\z\LabTestsFullImage_1.90.bin: Load failed.
    [14:01:30] Operation Writing flash memory returned.

    Thanks

    Nien

     

  • Hello Nien,

    I think the issue is related to the manner in which the bootcfg in the other post is being used. I would suggest we fix the hardware issue first before reverting to this.

    Regards
    Amit
  • My next step is to use a COM sniffer to analyse all the properties which are set by default when Realterm opens the port. It may give me a hint to what has to be explicitly set to serial properties before using LMFlash or UNIFLASH.
  • Hello Nien,

    That may be worth the investigation. Please note that the COM sniffer has to be passive.

    Regards
    Amit
  • Here is my conclusion on the matter :

    After investigation, with a sniffer on the serial port I could see that Realterm sets DTR and RTS 'Unasserted' by default while Labview and other serial software I compared when opening the COM port set DTR and RTS 'Asserted' by default. That was the only difference I could notice. Even if I forced LabView to set DTR and RTS by default to 'Unasserted' when opening the port, I could not make LMFlash.exe synchronize with the TM4C. I also noticed that if open/close the port with realterm so that LMflash.exe start working fine, as soon as I change a property of the serial port with LabVIEW or another software than Realterm, LMFlash.exe stop synchronizing properly.

    I didn't want to spend more time on the matter so my solution was to add realterm to my library of tools and from Labview, I use realterm.exe command line properties to open/close the port before launching LMFlash.exe. This works just fine as if I was doing it manually myself. Now I have a Flashing tool useable from Teststand and providing me all the automation I needed to program the TM4C at will without any intervention of the operator.

    I did not know about the realterm command line properties until last week. It was the easiest work around solution.

    Best Regards
    Nien