• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 892 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 and ROM Bootloader Auto Baud Support

Richard Bland
Expert 2050 points

I understand that the auto baud detect function is bypassed if I enter the ROM_Bootloader with a call to ROM_UpdateUart (having made sure that the serial port, it's pins and clocking are correctly setup before the call). I find this means that Auto Baud Support must be Disabled in LMFlash and the baud rate set to match - in this case 115200 baud. This is all fine and works nicely.

However if I force entry to the ROM_Bootloader on reset by holding a GPIO pin, I believe the auto baud detection function is run and therefore the support should be Enabled in LMFlash. This is fine too, however I find it only works if I set the baud selector to 38400 or below. Why does this selector have any effect when the system is "auto bauding"?

I am using an LM4F Launchpad.

Thanks

Richard

  • 0
    TI__Expert 6310 points

    Hi Richard,

    I can clarify a little bit about what the auto baud feature is doing.

    On the host side, when auto baud is enabled, the following events happen:

    1. PC configures its UART to the baud rate set in the "Baud Rate" drop-down.
    2. Assuming the PC has the right COM port, it immediately sends a burst of data equating to a pulse train (eg. 0x5555 or 0xAAAA), and waits for a response.
    3. The MCU detects these pulses on the UART lines, and compares the pulse frequency with its internal oscillator.
    4. The MCU then uses this data, and attempts to set a clock divisor for its own UART to match the PC's UART frequency.
    5. The MCU sends an "ACK" packet over UART at the newly configured frequency.
    6. If all goes well and the frequencies match, the PC should receive the "ACK" and start sending application data to the MCU, still using the frequency from the drop-down.

    Based on this procedure, it makes sense that the baud rate drop-down could affect the boot loader performance if the frequency is too high for the MCU to match. That being said, all of the frequencies we make available (110 up to 460800) should work. Also, it's a little strange that you are getting different results for an erased MCU and a BOOTCFG-enabled boot loader. Both should be capable of the same baud rates.

    I gave the BOOTCFG version a try on a LaunchPad here, and I was able to program across the full range of frequencies without difficulty. This makes me suspect that something else might be going on in the system. Maybe you could try a few different USB cables, double check your BOOTCFG pin against the settings, and make sure that the UART is still working normally for non-boot purposes.

    If you're still seeing issues, can you give me a description of your test procedure and the error messages that LM Flash gives you when it fails? Also, the complete part markings from the main MCU on your LaunchPad may be helpful.

    Regards,

    Christian

  • 0 in reply to Christian Jolivet
    Expert 2050 points

    Hi Christian,

    Thanks very much for your reply. It now makes sense that the PC selected baud is the one the auto baud tries to match.

    I can confirm that the uart works perfectly in my application at 115200 baud, and that if I enter the bootloader by calling ROM_UpdateUART() I can program fine at 115200 baud.

    I can also confirm that the BOOTCFG register is programmed correctly and that holding the selected pin causes the Bootloader to be run, but it does seem that in this case I can only get successful communication at 38400 baud and below. As this is only a "get out of jail card" it doesn't matter as long as it works!

    I have cut the tx/rx traces to the USB virtual com port on the LaunchPad and wired to an rs232 driver connected on a standard 9pin serial port cable to my PC. I found the FTDI driver supplied by TI to be very unreliable - it would only receive a few bytes before stopping - simply wiring up the rs232 fixed the problem.

    regards

    Richard