• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 1669 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.

TM4C 123GXL ,Flash bootloader, UART1

Yen Hung Liu
Prodigy 50 points

Hi, every one

  I use TM4C123GXL for a flash bootloader demo. I customized the Tivaware bootloader code to use UART1 as the port. My host device is a raspberry pi and I use pyserial(python serial module ) to send the bootloader command packet what I saw in the Tivaware Bootloader User's guide. My question is as below :

At the first, there is only the customized bootloader code locating at 0x0000.I can send ping,get_status,download and send command from the raspberry pi.When I reset TM4C123gxl,it will start from the bootloader and go to the application which will flash the on board for a while and jump to bootloader(via jumpBootloader()).

I add the UARTstdio in the bootloader so I can debug the code from another uart port on my PC.After the jumptToBootloader() happen, I found every command can't get a response. I found it seems like the buffersize is not enough and this caused by a wrong reading of the first byte of the packet.For example, in ping command,the first byte should be 0x03 but the TM4C123GXL read it as 252 which causes the buffer too small.

Does anyone know what may be the cause of the issue??
really appreciate for any help

  • 0
    TI__Guru**** 244380 points
    Hello Yen,

    The following forum post has the Application Note on Serial Boot Loader

    e2e.ti.com/.../471520

    There are flowcharts and better description of what is the flow the boot loader must go through. Can you please use this as reference?

    The next thing to note is that without seeing the boot loader code you have and any waveform of the transaction it would rather be speculative assist. Can you confirm that the UART1 is set for 8N1 @ 115200 bps correctly and on the bus the bits are being sent at 115200bps. This can be easily deciphered by looking at the first RX start of frame from the target device and checking if the bit time is indeed ~8.68us

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 50 points
    Hi Amit,
    I change the setting of the system clock in the application (I modified the boot_demo1 to only flash the on board LED for a while and go to bootloader) from
    ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_PLL |SYSCTL_XTAL_16MHZ |
    SYSCTL_OSC_MAIN);// original
    to
    ROM_SysCtlClockSet(SYSCTL_USE_OSC | SYSCTL_OSC_MAIN |SYSCTL_XTAL_16MHZ );

    Now I can use every command after gotobootloader(). Do you have any idea about this?

    sorry , I didn't know how to "looking at the first RX start of frame from the target device and checking if the bit time is indeed ~8.68us".
    Can you describe this detail?
    Thanks again, really really appreciate your help
  • 0 in reply to Yen Hung Liu
    Guru 117855 points

    Yen Hung Liu said:
    looking at the first RX start of frame from the target device and checking if the bit time is indeed ~8.68us".

    If I may - I'm (somewhat) experienced EE - may save (both) you & Amit some time/trouble.

    Amit's suggestion requires that you employ an oscilloscope to monitor the serial signal's "timing" and voltage levels when input to your MCU's UART_RX pin.

    Bit time is the duration (in µS) of each of the (usual) 10 bits which encompass a serial "byte."   You may best measure this timing by sending the unique chars: 0xAA or 0x55.   (either cause the bit pattern to consistently alternate - (0-1-0-1 etc.) which eases your measurement as each individual bit clearly transitions.)  If you've properly set the baud-rate - each of those bits should measure at/around 8.68µS.   Note: neither 0xAA nor 0x55 are "legal" boot-loader commands - they are to be used ONLY for confirming the serial bit-time - per Amit's direction.   (after their use - & bit-time measure - remove them)

    As you note that you can (now) "Use every command, after gotobootloader()" it appears to me that - if that statement proves correct - your baud rate is NOT the issue.   (i.e. if those commands are sent & acted upon properly - your baud rate appears acceptable)

    Amit's App Note is highly detailed - really excellent - yet boot-loaders are complex.   It usually pays to read that note several times - listing each/every point w/in your chosen boot-load method - and test/verifying (then checking off) each step along the way...

  • 0 in reply to Yen Hung Liu
    TI__Guru**** 244380 points
    Hello Yen

    ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_PLL |SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN);

    TM4C123 has a max frequency of 80MHz when using the PLL and that requires SYSCTL_SYSDIV_2_5 and not SYSCTL_SYSDIV_1

    As a result of the actual system clock and reported system clock are no longer same and hence peripheral like UART which use async channel may not work.

    Regards
    Amit
  • 0
    Prodigy 50 points
    Many thanks to Amit and cb1_mobile , You really help a lot. TI NO.1
  • 0 in reply to Yen Hung Liu
    Guru 117855 points
    Thank you as well, Yen.

    Suggest that - should you still have issues - you dial down (slow) the UART (and your remote device) during test & development. (for years - the "world turned on 9600" - that speed is far more forgiving - most always may be "coaxed to work!") Bon chance, mon ami.