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.

TMS320C6657: Bootmode (DEVSTAT) read incorrectly

Part Number: TMS320C6657

I am currently attempting to boot directly from NAND, and I'm getting "erratic" results.  The core0 will boot from NAND properly some times, and then other times it will "hang" in the BootROM (apparently).

My bootmode pins are all tied to pullup's/pull downs via resistors and are not driven by any other signal.  

I changed all pull-ups and pull-downs to 1K ohm resistors (which seems like it should be "strong enough" even with internal pull-up/pull-down).

I have tried adding a secondary reset (after coming out of reset initially), but that has not resolved the issue either.  I believe I saw an E2E thread for direct NAND boot that mentioned adding a secondary reset, however I can't seem to find the original forum thread on the E2E pages that I read this suggestions on. 

When I connect via the emulator and step through the assembly (in the BOOTROM) after doing a CPU reset in code composer, The processor appears to read an incorrect value from the DEVSTAT register.  It's reading 0x11807, while my resistor pull-up/pull-downs are setting it to 0x0C03 (Nand, no i2c params, nand block 0 source).   I have also probed these lines with a DMM and the voltages appear to be correct for the desired BOOTMODE.

I am attaching a capture of the reset lines as the device comes out of reset and gets a secondary reset

This is a screenshot where I captured the c6657 reading the wrong BOOTMODE value.  

  • Hi Mark,

    I've forwarded this to the experts. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • Hi Mark,
    Let me ask two questions. First, in the boot sequence diagram, you don't show where the system clock is applied. Can you confirm that the clock is present for the specified time before PORz and RESETFULLz go high? Second, the RESETz signal goes low after RESETFULLz goes high. Can you tell me why that signal is going low?
    Thanks,
    Bill
  • Hi Bill,

    1) The system clock is applied long before any of the resets go active, (same goes for the power supplies).  I have previously verfiied these signals on an O-scope.  My logic analyzer doesn't have the bandwidth to capture the clocks properly, so I intentionally omitted the clocks.   I attached a plot which include my PLL_LOCK signal going valid, which is 25 ms prior to any of the reset signals getting deasserted.

    2) The second reset is in reference to  this thread (I just re-discovered), It's in Rahul Prabhu's reply under "proposed workarounds" - in the second option:

    How to generate c6657 nand boot boottable? 

    3) Interesting fact....If I run the supplied "evmc6657.gel" file's "Global_default_setup()" , do a "CPU Reset" in Code Composer, the board boots properly.  

    I "reverse-engineered" the filename information, and BootLog from another thread referencing the "ROM Bootloader"   

    Here is the "snip" of data form the bootlog section:

    1651 9 8ffa80 0 160 4
    00000004
    0000000A
    00000001
    20B15BA8
    00000298
    0000006A
    20B15BA8
    000000AE
    0000006A
    20B15BA8
    00000071
    00000066
    20B15AF0
    000000C3
    00000000

    Here is the filename Information I parsed:

    =====================================================================
    File Name : BootFailure-Filename.dat
    Magic Number : 1651
    Supported Formats : 9
    Start Address : 0x20b15a40
    Page : 0
    Length : 0x400
    Format : 0x10
    =====================================================================
    [0x20b15a40]../../../../devices/gauss/gaussDsp.c
    [0x20B15A68] ../../../../devices/gauss/gauss.c
    [0x20B15A90] ../../../bootproc/bootproc.c
    [0x20B15AB0] ../../../main/mainemif4cfg.c
    [0x20B15AD0] ../../../main/emifmain25.c
    [0x20B15AF0] ../../../main/nandmain.c
    [0x20B15B10] ../../../main/pciemain.c
    [0x20B15B30] ../../../main/riomain2.c
    [0x20B15B50] ../../../main/uartmain.c
    [0x20B15B70] ../../../main/vusrmain.c
    [0x20B15B90] ../../../main/ethmain.c
    [0x20B15BA8] ../../../hw/nand/nand.c
    [0x20B15BC0] ../../../main/spimain.c

    It looks like something is failing in the "nand.c" portion of the bootloader.  Even though the "DEVSTAT" appears to be getting read as though it's "hyperlink boot" when I reset the DSP in the emulator/ccs studio environment.  

  • Mark,

    C6657 is impacted by the same NAND boot advisory as documented for TCI6614 device, for reference look at the advisory here:
    www.ti.com/.../sprz370e.pdf

    We have reproduced this on our EVMs and have provided the second reset solution that you referenced earlier. This will work only if the DEVSTAT value doesn`t change during the second reset. This solution is only for the EVM. On your custom hardware, you can ensure the the SOC is powering up after the NAND has powered up so that you don`t need to implement the second reset solution. Check the work arounds discussed in the errata document.

    Regards,
    Rahul
  • Hi Rahul,

    I have done the following:

    1) decreased my CORECLKP/CORECLKN frequency to 50MHz

    2) I set the BOOT Mode pins for a 8x multlipler, meaning that should be a 400 MHz Core Clk

    I'm still seeing boot failure, however these are the bootlog errors I'm getting:

    1651 9 8ffa80 0 160 4
    00000007
    0000000A
    00000001
    20B15BA8
    00000291
    00000069
    20B15BA8
    00000291
    00000069
    20B15BA8
    00000291
    00000069
    20B15BA8
    00000291
    00000069
    20B15BA8
    000000B6
    0000006F
    20B15BA8
    00000071
    00000067
    20B15AF0
    000000C3
    00000000

    This seems to indicate that the RBL is missing the "busy flag", however i'm still getting this error:

    #define NAND_BOOT_ERROR_OPEN_GET_FLASH_DETAILS 103

    Any thoughts on this?

  • Can you specify what is the NAND part in question from which you are trying to boot. I recommend that you try booting the image with the C6657 EVM before testing this on the custom hardware. This will give us a data point.

    The boot logs are simply indicating that the function enters NAND main and the nand driver but isn`t able to get the NAND Geometry based on the data obtained from the NAND flash.
  • The EVM was booting with my code package.   The problem here is that things appear to be getting hung up in the RBL, and not even reaching my code.  This appears to indicate that there an issue with reading the NAND in the RBL. Not an issue with the code itself.  

    The NAND Device on our design is: MT29F1G08ABCHC-ET:C

    However this part has been transitioned over to a smaller process which is: MT29F1G08ABBDAHC-IT:D
    The best I can do for a datasheet is: MT29F1G08ABCHC-ET:C (Micron's Site)

  • I looked at the NAND datasheet and it seems to be an ONFI NAND with 1bit ECC requirement.

    Is it possible for you to provide the NAND portion of the schematics. What CS/CE are you using? Are the data or CS/CE only connected between SOC and the NAND? How are you flashing the NAND ?
  • Hi Rahul,

    Changing the PLL settings on the bootmode pins (pulldown to pull-up) had an unintended consequence on our design. After boot, bootmode pins 12 through 10 are used as GPIO outputs, to drive the output enable of some buffers. These buffers allow us to interface to a UPP bus. The problem being with the slower PLL setting required, the pull-down on the bootmode pin, puts the buffer on the UPP interface (with signals shared by the NAND interface), in the wrong state. I was able to jumper things to resolve this issue, and things seem to be on the right track. I need to exercise the fix a bit more to develop some confidence in it. However If it looks good after some time and testing, I will verify the answer.

    I need to focus on a CCSv7 issue, before I get back to this, but I'll check back in shortly.

    Thanks,
    mark