• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 35 subscribers
  • Views 902 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.

TPS65982 boot problem

Joe Rizza
Prodigy 150 points
Other Parts Discussed in Thread: TPS65982

There are two TPS65982 devices on this board. Second device is a slave to the first. The first board came up fine, loaded firmware from the flash, and the second device loaded over the UART, so we know the design is correct. Trying to debug the other boards that BOOT, but will not load the application from flash.

The device recognizes the SPI flash, and both images, but then it says both are invalid. I have looked at some of the debug routines, but the only information I have found is how the device goes into debug mode when it boots with a fault. What I don't know is HOW to use the debug features to see what is going on. I even isolated the two devices, shutting down the first, and strapping the second one as the master and connected it directly to the flash. Still will only boot, but will not load the application.

8.4.7 in the datasheet tells me what happens to the SWD interface if there is a problem, but it doesn’t tell me how I can use it, or how to decode it. I am trying to figure out where the 'load from prom' is failing, and why. I’ve programmed AND verified the flash image in the prom with Flash Center directly, so I know it’s good, and it is also a known good image file.

  • 0
    Prodigy 150 points

    I also don't see anything on SWD_CLK or SWD_DATA after it fails to load from the flash, as indicated in Figure 68 of the datasheet.

  • 0 in reply to Joe Rizza
    TI__Expert 6280 points
    Hi Joe,

    The SWD pins are for internal debugging only. Could you share the binary you are loading on to the flash (Configuration Tool Project)?

    Jacob
  • 0 in reply to Jacob Ontiveros
    Prodigy 150 points

    I'm not sure what difference the firmware image makes, if I know it's a good image and works on other boards. It won't tell you why a particular board starts to load the image, and then just stops.

  • 0 in reply to Joe Rizza
    TI__Expert 6280 points
    Hi Joe,

    I just want to make sure you have correct header on the binary that is on the non booting board. By any chance to you have something else connected to the SPI lines when starting up the system.

    Jacob
  • 0 in reply to Jacob Ontiveros
    Prodigy 150 points
    It is the same binary that I'm putting on the "good" boards. Sometimes I have an Aardvark on the SPI bus, but I've tried several ways. Even if I only access via the I2C to verify if the device is booting or not. The problem is, I don't know what is on the SPI bus. I know the startup sequence in general, but I can't figure out where the boot process is failing, how it decides the image is bad, etc.
  • 0 in reply to Joe Rizza
    TI__Expert 6280 points
    Hi Joe,

    I need some more information in order to help out. The reasons the boot process may fail is with binaries that have their header corrupted, something else (SPI Master) is attached to the SPI lines during boot, toggling of the VIN_3V3 supply during startup, some manufacturing error, etc.

    For more information on the booting check the firmware user's guide below (Section 3/4)

    www.ti.com/.../slvuah7b.pdf

    Jacob
  • 0 in reply to Jacob Ontiveros
    Prodigy 150 points
    OK, I'll keep looking because right now the part boots, but it never goes to the SPI interface, whereas last week I could capture the boot process off the SPI (up until the point that it stopped). We might have to try replacing the devices on these two boards.
  • 0 in reply to Joe Rizza
    Prodigy 150 points

    What I determined was that the Application Customization Tool create a bad image file. I created both the FULL image file and the LOW image file at the same time- same date and time stamp, but the full image file is too small, and the data is in the wrong place. There is data where the pointer should be. I recreated the full image file and compared to the low image file, and it looks like it was properly created this time. 

    If you give me your email, I can send you both copies of the files to look at. 

    The reason I think some of the boards worked is that the low image file must have been used to program them. It looks like the low image file should be 64k and the full image file should be 192k, but instead in this case the full image file was 64k and the low image file was 192k. There is still only one valid image in the low image file, confirmed after bootup of the application, and the full image file was created corrupted.

  • 0 in reply to Joe Rizza
    TI__Genius 16370 points
    Joe, Which version of the tool are you using? Is it creating the faulty images every time you try saving the binaries? I'm surprised since we never observed this problem earlier, and would like to get to the bottom if there's indeed an issue.

    BR,
    Praneet
  • 0 in reply to Praneet Kumar
    Prodigy 150 points

    I think it was version 2.8, and I did recreate it and it was fine, so it's certainly odd that it created it wrong that one time. I just upgraded to 2.10 as well.