• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 951 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C1290NCZAD: max uart firmware baud rate

DavidVescovi
Genius 5470 points
Part Number: TM4C1290NCZAD

I would like to use the factory on-chip firmware boot loader to reflash.

I am using a dedicated high speed UART0 channel.

I know the firmware auto bauds but I also read it uses the internal PIOSC as its peripheral clock.

This would seem to me to limit the baud rate you could use in this configuration.

I want to use 937500 baud which is an acceptable baud rate when it uses the 120mhz sys clock as the peripheral clock which is how it is configured for normal operation.

Does the on-chip boot loader uses the system clock for uart peripheral clocking if the 120mhz system clock is running when it enters the factory boot loader firmware via the programmed BOOTCFG gpio pin?

Is 937500 baud acceptable in this mode?

DV

  • 0
    Guru 117855 points

    Pardon - interested outsider here - if I may - firm/I have experienced a similar desire by 3 different clients - all using ARM M4 MCUs.   (yet just one from this vendor - others run @ 180MHz)   Thus the (so limited) sample size - from which I'm working - may not provide more than a "hint" of what may be expected.   (yet I believe (some) value shines thru...)

    In summary - clients each discovered that maximizing baud rate - w/out doubt - reduced the robustness of such boot-loads.    As I recall - even cable/type lengths & equipment power & ground connections - had the ability to wreak havoc!    Our advice (fairly obvious) was to perform a well measured, statistically viable, test series - and employ that means to "best answer."    Note too - for even greater robustness - we urged clients to (even then) drop to the "next lower" standard baud rate!   

    One client "protested" (we were "all ears") claiming the high speed was required to reduce battery drain.   Yet - the energy equation must note higher currents @ higher speed!    And - what is the "energy cost" of multiple, repeated, failed boot-loads?      That client's engineer had NO Answers - we DID!     Rarely does "advance, in-depth study/preparation lose (to hunch/opinion) in such debate...)

    In boot-loading - robustness - not speed - should be, "top dog!"

  • 0 in reply to cb1_mobile
    Genius 5470 points
    In my case the UART IS NOT connected to a PC and there are NO interposing level translators, drivers or cables.
    I know all these factors effect selection of a reliable baud rate. In my case the UART is DIRECTLY connected to the host by approx. 0.5 inches of PC board copper!
  • 0 in reply to DavidVescovi
    Guru 26105 points

    Hi,

    Please take into account the flash writing time, typ 100us, max. 300us - see full specifications at the end of user manual. This uses more power than uart module. So you may lower the baud rate or even use another flashing method (JTAG/SWD).

  • 0 in reply to Petrei
    Genius 5470 points

    I am not interested in programming time, it can be what ever it is.
    I do not want to run at higher baud rate to lower flashing time, I want to run at the higher baud rate because that is the speed the channel runs at when it is normally running (non flashing mode).

    I.E. that is the normal host to controller baud rate.