• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 271 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.

TM4C1231D5PM: ROM bootloader Issues with Version 7 silicon

Brian Bailey66
Prodigy 40 points
Part Number: TM4C1231D5PM

I have a product that has been running the TM4C1231D5PM successfully with silicon version 6. We just got new boards in with version 7 parts and are now having problems entering the ROM bootloader from erased parts. Swapping a V6 MCU onto the new board works fine.  Swapping a V7 MCU onto the older board does not work, so the problem follows the V7 MCU. 

Application: The MCU is booted by a host processor and if there is no program, the host processor resets the MCU, sends the autobaud sequence, pings the MCU, and then proceeds to update the firmware through the ROM bootloader. This process is used to program factory new MCUs and has been working well.

The autobaud bytes are sent with no delay between them and the ping command is send immediately after that.

With v7 silicon, the MCU does not respond to the autobaud bytes or the ping command. Testing shows that adding a delay (~2mS) between the autobaud bytes fixes the issue.

I would like some clarification on why the version 7 silicon behaves differently before this goes to production. Is there any documentation that clarifies the timing requirements for autobaud and subsequent commands?

  • 0
    TI__Guru**** 158915 points

    Hi Brian,

      This is the first time I've come across a reporting like yours. I have a launchPad with version 7 MCU silicon. I just do a ROM bootloading using both the LM flash programmer and the sflash.exe utility. In both cases, there is no issue booting the MCU using the ROM bootloader. I have the auto-baud rate enabled.

    Using sflash.exe

    Using LM flash programmer.

      Can you please answer me some questions?

      - Are you seeing the issue with v7 on only one MCU all the v7 MCUs you have?

      - Can you try either the LM flash programmer or sflash.exe on your v7 MCU? Do you see the problem? I want to know if this is download tool related. 

      - Can you try to use your host processor to boot a TM4C123 LaunchPad with version 7 if you have one? I want to know if this is board related. 

      

  • 0 in reply to Charles Tsai
    Guru 92251 points

    Charles Tsai said:
    I have a launchPad with version 7 MCU silicon. I just do a ROM bootloading using both the LM flash programmer and the sflash.exe utility.

    Charles, is it possible you could use a scope or LSA to measure the delay between the auto-baud rate bytes from your test?

    Just mentioning that since Brian mentions a delay between the auto-baud rate bytes makes the problem go away, and when a PC is using a USB-to-serial adaptor not sure what the delay between bytes is.

  • 0 in reply to Charles Tsai
    Prodigy 40 points

    Chris, thanks for the reply.  To answer you questions:

    We've tried to program 31 assemblies and 2 of them were successful.  This led me to believe it was a timing issue.

    I could try the LM flash programmer (with some creative connections) but others don't have issues with it so I have not.

    To determine whether it was board or MCU related we have done the component swaps and the problem follows the V7 MCU. So new board, old board, V6, and V7 - the V7 silicon is the common denominator.  All other combinations work.

    Here are some scope captures of the issue:

    First, the V7 silicon with no delays between or after the autobaud bytes:

     

    Here's the V7 silicon with 2mS delays after each autobaud byte.  It's zoomed out so the decode doesn't read out bu you can see from the traces that the MCU bootloader ROM responds.  It also sucessfully programs.

     

    For completeness, here's the V6 silicon with no delays.

    Had this happened during my initial development I wouldn't have though much of adding the delay to make things happy.  I'm really just looking for some reasoning on why the silicon version has any affect on this.  I haven't been able to find anything documenting the timing requirements.  I suspect this is largely because not many people are running the bootloader from a host processor.

  • 0 in reply to Brian Bailey66
    TI__Guru**** 158915 points

    Hi Brian,

      Thanks for providing the captures. I don't know there is a difference between rev6 and rev7 in this regard. Perhaps there is some update the ROM bootloader between rev6 and rev7 that I'm not aware of. I will need to consult with someone who may know. I will try to get back to you.

  • 0 in reply to Charles Tsai
    TI__Guru**** 158915 points

    Hi Brian,

      Earlier you said, out of 31 assemblies you have two of them working. If the failure was due to the ver7 then I tend to think that all 31 assemblies should fail. What baud rate from the host processor are you generating? Can you try different baud rates, perhaps slower baud rate like 115200 or slower? Will it make a difference? If possible, could you use the LM flash programmer running on the PC? I'm unable to find anyone who can explain the difference between v6 and v7 in this regard at this moment. I will try to ask around. In the meantime, if the delay you have is working, I will suggest you stay with it. 

      I find this post that may bring some insights. 

  • 0 in reply to Charles Tsai
    Prodigy 40 points

    Hi Charles,

    I've been through the silicon errata looking for v7 issues that are not present in v6.  There were only 3 issues and they were all EEPROM related so nothing there.  The Boot ROM update is a good possibility.  Hopefully you can find someone in the know on that.

    I agree that 29/31 board failing is interesting.  My interpretation was that something must be on the edge of the functional range, thus the timing theory. The host processor is set to 115200 baud when interacting with the ROM bootloader so it's already quite slow.

    Ultimately it works with the added delays and that's what I'll have to release. I was just hoping to get an explanation for the difference.

    Thanks for taking the time to look into this!

  • 0 in reply to Brian Bailey66
    TI__Guru**** 158915 points

    Hi Brian,

      I will mark your post as resolved for now. If I come to know the reason the between the two version in regard to adding delay after the auto baud bytes, I will report back to the post. 

  • 0 in reply to Charles Tsai
    Prodigy 40 points

    Thanks for your assistance.