• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 83 subscribers
  • Views 2170 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.

TMS320F28034PNT BootROM

Ricky Zhang
Genius 9520 points

Other Parts Discussed in Thread: CONTROLSUITE

Hi, Champs,

My customer is using TMS320F28034PNT for long time in motor inverter application, and the latest silicon revision they are using now is Rev. A.

For a fresh device, they have developed a customized bootloader to program it and it works for years successfully, but recently they have some boards  failed the programming while some of them work well.

The basic programming flow is as following:

They use SCI boot to run TI BOOTROM and transmit customer bootloader to RAM for running following the data stream TI BOOTROM requires, with the end of an executable file, the PC should jump to RAM and execute their codes which perform SCI baud rate modification, read customized bootloader version, call FlashAPI erase and program function as well as transmitting the application codes' image.

What we found now is, for those boards work well, all these procedures can be executed successfully and the device can be programmed as expected, while for those failed boards, although the customized bootloader's image was transmitted successfully, it can not be executed as the PC won't jump to related RAM.

Some tests we have completed are:

1. Monitor the data stream of customized bootloader transmitting in both "good" and "bad" boards, and found they are identical;

2. Customized bootloader codes will firstly perform a SCI baud rate modification command, but it's failed to execute, then we commented these lines to execute next command of reading customized bootloader version, it failed either, which indicated that customized bootloader codes to be placed in RAM were never executed;

3. We then sent another data of 'A' from PC software after the customized bootloader was transmitted, we got a response from F28034 BOOTROM with identical response of 'A', which means the BOOTROM is still running even if correct image's data stream transmission was done successfully.

As the hardware set-up and PC software as well as the customized bootloader image are completely identical, but only found some boards work while some boards fail (and earlier boards worked well all the time for years), we suspected that the BOOTROM in some devices are not working as normal, could you please advise what further debug should we do, or what other information would be required for you to analyze this issue? Please do not hesitate to let us know.

We also wonder if there're ways to verify the RAM contents, PC information and device information in emulation mode, can customer do it when running BOOTROM? Please advise.

Best Regards.

Ricky Zhang

  • 0
    TI__Guru 55700 points
    Are you saying the "bad boards" from both custom bootloader (or) SCI bootloader (from BOOTROM) had the communication established and hex file was successfully downloaded onto the device?

    Also, has the customer tried A-B-A swamp check?
  • 0 in reply to Manoj Santha Mohan
    TI__Genius 9520 points
    Yes, Manoj, the communication has been established and the codes were successfully loaded to RAM for running, but the BOOTROM seems to be kept running without jumping to entry point.
    We didn't perform swap tests as this seems to be apparently a BOOTROM issue.
  • 0 in reply to Ricky Zhang
    TI__Guru* 95315 points

    Ricky,

     

    1. Did the problem start after switching over to rev A?
    2. Does a "bad" device recover after (repeated) power-cycling?
    3. Is there anything common across the failing devices, such as the same LTC?

     

    Yes, you should be able to connect the emulator to examine the RAM/PC etc. You should be able to load the boot-ROM symbol library to facilitate debug

     

  • 0
    TI__Mastermind 19810 points

    Ricky Zhang said:
    3. We then sent another data of 'A' from PC software after the customized bootloader was transmitted, we got a response from F28034 BOOTROM with identical response of 'A', which means the BOOTROM is still running even if correct image's data stream transmission was done successfully.

    Ricky,

    on above, I believe you are saying that a character A is echoed back at the baud rate set by SCIBOOT in Boot ROM. It could happen only in below two cases. 

    1.> Device got reset after starting the downloaded application and went back to SCI BOOT. Can you try sending any other character other than A and see if that gets echoed back? if it doesn't then device got reset and AUTOBAUD didn't succeed. Character A is used for Autobaud lock in SCI BOOT in ROM. So it is confusing to tell if device got reset or not.

    Also you can monitor XRSn pin to see if device got reset.

    2.> The other reason why application didn;t start could be that , the SCI BOOT in boot ROM thinks it didn;t receive the last block of data completely yet. There must be some characters missing, were you able to analyze the Echoed characters back from SCI BOOT in ROM and see each character sent is echoed back?

    Also as Hareesh suggested, you should be able to run the boot ROM using EMUBOOT with debugger connected (load ROM symbols OUT FILE from C:\ti\controlSUITE\libs\utilities\boot_rom\2803x\2803x_boot_rom_v1\Release).

    If you can reproduce the issue on any of the bad boards with debugger connected then finding the problem could be quick.

    Hope this helps.

    Best Regards

    Santosh Athuru

  • 0 in reply to Hareesh Janakiraman
    TI__Genius 9520 points

    Hareesh J said:

     

    1. Did the problem start after switching over to rev A?
    2. Does a "bad" device recover after (repeated) power-cycling?
    3. Is there anything common across the failing devices, such as the same LTC?

    1. They have switched to Rev. A for long time and it only appeared recently for this lot;

    2. No, this is consistent failure. Bad boards always failed to run after BOOTROM;

    3. Same LTC materials have both good and bad boards. I still need to get the exact LTC information.

    Best Regards,

    Ricky Zhang

  • 0 in reply to Santosh Athuru
    TI__Genius 9520 points

    Santosh Athuru said:
    on above, I believe you are saying that a character A is echoed back at the baud rate set by SCIBOOT in Boot ROM. It could happen only in below two cases. 

    1.> Device got reset after starting the downloaded application and went back to SCI BOOT. Can you try sending any other character other than A and see if that gets echoed back? if it doesn't then device got reset and AUTOBAUD didn't succeed. Character A is used for Autobaud lock in SCI BOOT in ROM. So it is confusing to tell if device got reset or not.

    Also you can monitor XRSn pin to see if device got reset.

    2.> The other reason why application didn;t start could be that , the SCI BOOT in boot ROM thinks it didn;t receive the last block of data completely yet. There must be some characters missing, were you able to analyze the Echoed characters back from SCI BOOT in ROM and see each character sent is echoed back?

    Yes, I'm saying the echo back, and will ask customer to try another character. While actually we don't think the device gets reset, the reason is, if the downloaded application codes start to run, it should be able to respond the command from PC software to modify the baud rate or feedback the software version, as this is the 1st function to be executed in the communication after application codes' transmission.

    For the 2nd possibility, as stated in my original post, we believe the last block of data had been transmitted completely, since we did capture all the data stream in serial for both passed and failed scenarios, and made the comparison to ensure they are all identical.

    Santosh Athuru said:
    Also as Hareesh suggested, you should be able to run the boot ROM using EMUBOOT with debugger connected (load ROM symbols OUT FILE from C:\ti\controlSUITE\libs\utilities\boot_rom\2803x\2803x_boot_rom_v1\Release).

    If you can reproduce the issue on any of the bad boards with debugger connected then finding the problem could be quick.

    It's good to know we can leverage BOOT ROM symbols to do the debug, question is, if we can track where the PC is, and unfortunately it does pause in BOOTROM after transmission with completed image (and last block of data), what else should we check or can we say it's a BOOTROM issue?

    Best Regards,

    Ricky Zhang

  • 0 in reply to Ricky Zhang
    TI__Mastermind 19810 points

    Ricky Zhang said:

    It's good to know we can leverage BOOT ROM symbols to do the debug, question is, if we can track where the PC is, and unfortunately it does pause in BOOTROM after transmission with completed image (and last block of data), what else should we check or can we say it's a BOOTROM issue?

    Ricky,

    The fact that you are able to get an echo back after you think the board hit a problem is that SCI Baud rate is still locked , yes lets check the PC and make sure it is in boot ROM. But you can do below debug as well if you are able to reproduce the issue with the bad board with emulator connected.

    If device isn't reset and SCIBOOT is still communicating with host then definitely the boot ROM thinks that not all the data of last block is received. for it to call exitboot and branch to the entry address.

    I would suggest you to do below on a bad board on bench

    1.> load ROM symbols

    2.> do a debug reset

    3.> put a break point after loading ROM symbols in SCIBOOT, where it returns the EntryAddress.

    4.>  set EMUBOOT to SCIBOOT and EMUKEY as per TRM of your device

    5.> run device

    6.> run host program

    7.> does it hit the break point, if yes then you can do assembly step through and branch to the application entry point and at this point Add symbols from your applicaiton COFF that is just loaded and run. 

    8.> if it doesn;t hit the break point as said in #7 above, then pause the core. Take a memory dump of all the RAM and compare it against the RAM dump you would get after loading the applicaiton though CCS (or from a board that passes). if you see difference in any locations then findout what those locations are used for and what could be causing the locations to have wrong data - I would assume that there are some bytes that are lost or misread.

    Hope this helps.

    Best Regards

    Santosh Athuru

  • 0 in reply to Santosh Athuru
    TI__Guru 55700 points

    Ricky,

    As Hareesh / Santosh suggested, you need to connect to device (may be using WAIT BOOT if needed). Load the boot rom symbols and debug to understand why it doesn't jump to RAM.

    That is the most efficient way to understand what is going on?

    Regards,

    Manoj

  • 0 in reply to Santosh Athuru
    TI__Genius 9520 points

    Manoj, Santosh,

    Thanks for your advice and here is an update for this issue. I think we can close this post now, with your great support. Thank you so much.

    Before we discuss what happens in customer board/software and what's the debug result of loading BOOTROM symbols, I want to clarify two more facts that I just learnt this week when on-site support:

    1. Customer software can successfully program ALL new fresh devices in factory and this issue only happened when the control board needs to be re-programmed in their end equipment products, which means much worse environments like un-stable/clear power supply with noise, and small current (e.g. some cases they're using USB cable from PC to power up the device);

    2. The image to be loaded to RAM for running is not a single one that is used to perform the flash operation, but with an extra one before that, to unlock the device. The reason they didn't combine both to one is that, they are two separate steps and unlock the device procedure applies to all legacy C2000 devices, while their host program is to handle many C2000 devices' programming like F28232, F2808 and F28034 etc.

    When we loaded the BOOTROM symbols to debug, we found the first time PC will be running through M0 where unlocking the device function is executed, and then it went to transmit customized BOOTLOADER application code and it failed to run.

    We did see that F28034 responded to host program that "I have received your data successfully" but it failed to write to Lx RAM, as the RAM content returned all 0's , which lead us to doubt whether the device is still locked and finally we did find the unlock procedure was failed, although they get success in the communication, while the CSM register did told us that SECURE bit is 1.

    Considering the fact how this failure occurs and the conditions it might have, we do believe the CSM was damaged or the password was programmed with other unknown data, so we suggested customer to monitor this procedure and have some improvements in the power supply.

    Best Regards,

    Ricky Zhang