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: Intermittent problem booting from flash

Part Number: TMS320C6748

We have designed a board using a TMS320C6748EZWT3 DSP which boots from NAND flash. We have seen intermittent problems with booting from flash and on one board in particular it fails to boot in one out of three tries. We have probed the EMA_WAIT_0 pin connected to the flash chip and it appears that the bootloader is accessing flash in both a successful and a failed boot for the same length of time. Is there any way to determine if the bootloader has failed to load the code from flash? What does it do if, for example, there are uncorrectable errors?   

  • Bernie,

    Although I do not have any answers, I wanted to at least offer some thoughts or comments and questions to help with debug. I am not familiar with the bootloader to be able to tell you what the response to errors would be.

    Since the EMA_WAIT_0 pin indicates that the bootloader is reading the NAND for the correct amount of time in both cases, the implication to me is that the NAND reads are not returning an error until possibly the very end of the final section being loaded. An interesting test would be to add another section to the NAND contents of some program code in a different section (like .text_test) that would be long enough to detect the extra length on the probe of EMA_WAIT_0. If the failing case still reads the same length of time as the passing case, then it is successfully reading all of the original NAND contents plus the new dummy .text_test section.

    How do you observe that the boot failed?

    Do you have JTAG/CCS connected to the board and can observe the boot process and the loaded code after the boot process?

    The easiest way I can think of to compare the result of the bootloaded code is to halt the processor after the boot and do a memory save of the full program space to a text file. Then repeat that for a failed case and do a text compare between the two. You may need to read the CCS tutorial on hardware breakpoints or do a search on TI.com to find how to set and use them, although I am not sure they can survive a hard reset. Otherwise, you might have to put a B $ at the entry point of your code, or a BKPT instruction, to get the emulator to stop as early as possible after the bootload.

    My expectation of the bootloader's behavior is that it would copy the NAND contents as it reads them in, and then there is a checksum at the end. If that fails, it might try reading again, or it would just hang - my guess would lean toward reading again, which would not be indicated by the EMA_WAIT_0 signature. Perhaps the bootloader document will shed some light, or another more official reply here.

    Please let us know what more your learn or discover.

    Regards,
    RandyP
  • Bernie,

    There are many ways to debug this issue. you can capture the device state using a Debug GEL file we provide when the NAND boot fails and report us the Program counter to look at :
    processors.wiki.ti.com/.../OMAP-L1x_Debug_Gel_Files

    The details of the NAND boot for this device is provided in the C6748 Bootloader USer guide:
    www.ti.com/.../spraat2f.pdf

    If the Bootloader comes across uncorrectable errors, it will mark the block bad and try to find the boot image in upto the next 32 blocks.

    I would also like to make you aware that C6748 has a minor NAND issue where it doesn`t correct errors if they are caused in the spare area. Please check the silcion errata. the work around is to use the latest AISGen tools which apply a patch that resolves this issue.
    www.ti.com/.../sprz303h.pdf (Check Advisory 2.3.24)

    Regards,
    Rahul
  • Thanks Rahul and Randy. It appears that this problem was due to Advisory 2.3.24. After applying the patch the issue appears to be resolved.