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.

TMS320C6748: Problem with startup

Part Number: TMS320C6748

We are having an intermittent problem with getting the processor to start running our application code on a circuit board of our own design that is based on the LDCK. Most of the time the device starts properly, but sometimes the bootloader seems to load from flash then the system hangs. We are able to verify that the bootloader is running as we set the pinmux to connect clock to gpio6-14 and we see the clock. We have also configured the bootloader to use and check CRC's using the check box in AIS Gen. Is there any way to know if the bootloader has completed successfully? The documentation says it will try three times on any section then abort. What happens when it aborts? Is there any way to have the bootloader raise an IO lead when it completes and calls the entry point to main code or when it aborts so we can get some insight into what is happening.

The power supply sequencing and reset all seem to be fine as the bootloader does start every time. It just doesn't always pass control to our application code. We are using the Windbond DDR2 chip from the LDCK and are using the settings for it from the LDCK config file. AIS Gen is creating the code to set up the DDR2 controller at boot time.

Any input appreciated.

Blair

  • Blair,

    What boot mode are you using?

    Is the layout the same from the C6748 to the DDR2? If not, there might be a need to adjust the DDR2 timing values.

    How does seeing the clock on gpio6-14 indicate that the bootloader is running? It would indicate the DSP is running, but not what is happening, at least from my understanding. Definitely a good sign, but you might be able to explain more to me or your thinking on this indicator.

    To test what the bootloader is doing when it is finished, you can put some code at the entry point that toggles a GPIO pin, or maybe change the pinmux for gpio6-14 to the clock output stops when the entry point is reached.

    You might need to write a very simple small application that does something you can monitor to see what is happening. At least you can find out part of the problem. Then perhaps start adding in the application until you find what is going wrong.

    Those a my ideas. Sorry I do not have answers. This is not an easy problem.

    Regards,
    RandyP
  • Thanks for the reply Randy. The idea about the clock is that the default configuration for GPIO 6-14 is not connected to the clock. By changing the setup of the pinmux using the AISGen tool and seeing the clock show up it gives us confidence that the bootloader is starting and running. If it was not then we would not see clock on the pin. It is not impossible that the DDR2 settings need to be tweaked, but once things do startup, after a couple of resets DDR2 appears to work just fine. We have run code for weeks with no issue and it runs from DDR2, the problem only seems to be at startup. I read an errata entry last night about boot issues and will look into that today. Thanks for the idea about a small bit of code at the start that sets an IO lead. Our main code actually does that when it sets up the IO at the start. It just looks like the boot loader is aborting and we are trying to figure out if there is a way to tell if this is happening.

    Blair

  • Bliar,

    If you are using NAND boot, then please refer to our responses here:
    e2e.ti.com/.../620042

    that issue was related to a NAND boot errata so you should try and see that your boot images are applying the same workaround.

    Hope this helps.

    Regards,
    Rahul
  • We tried that this morning and it fixes the problem, thanks.