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.

Custom 6670 board troubleshooting

Other Parts Discussed in Thread: TMS320C6670

Hi everyone,

We could use some help trying to figure out what is going on with our 6670 custom board.  We are using a 6670 and it is based off of a previous design.  All the clock signals and power levels seem to be correct, however there are some issues we are having with the board that we could use some help trouble shooting.  We are using a TMS320C6670 Rev 2.0 @ 1.2GHz. Here are some symptoms of  what is going on:

1) Code will not load from I2C in I2C Master boot mode.  The image we have in our I2C eeprom is the same image that works perfectly on a previous version of our board.  The board does start to load, it appears to read like 2-5 128 byte boot blocks (depending on the physical board), but it just stops.  The image also runs completely out of L2SRAM so that DDR3 is not an issue.

2) JTAG instablility.  When booting in No Boot mode, we can load and run small simple applications (i.e. "Hello World"), however as more peripheral support, like DDR3 initializations or SPI communications, the application either fails to load (giving "Trouble Writing Memory Block at ..." errors), or when running we get a "Device core hung ..." error.  When the errors happen, a chip reset seems to be required before we can re-connect, and once that happens, we start getting Memory Write Errors when doing simple memory window editing in L2SRAM, MSMC, or DDR3 (if it was initialized via a GEL file).

3) Non-Core 0 Memory is unstable.  When Reading MSMC memeory or L2SRAM of other cores i.e. (address 0x11800000 or 0x12800000) I can read the memory a couple of time (JTAG or Code), but eventually I get memory write/read errors. So setting a pointer to 0x11800000 and reading/write to that location eventually hangs the processor, exact same code to 10810000 works fine.

Any ideas to help us figure out what are causing these issues would be greatly appreciated.

Thanks,

Erick

  • So after some experimenting here is some more information as to what is going on.

    Core 0's memory access to any of the other cores' L2, MSMC, or DDR3 are the cuprates as to what is causing the issues.  When Core 0 tries to access MSMC, DDR3, or L2SRAM in the other cores, the processor hangs.  This happens in the JTAG memory window when connected to core 0 also.  We've also ran code, that was not attached to the JTAG and the program stalls when a pointer is set and a read/write attempt is made to those memory locations.

    We can run the exact same code accessing all cores' L2, the MSMC, and DDR3 (through code or the JTAG) w/o any issues if the programs are running in (or JTAG is connected to) any of the other 3 cores.  This would lead us to believe that there is only an issue with Core 0's access.

    Those memory locations are not the only ones we have problems with, register access to the XMC and SPI setup registers for example, we are seeing similar results where the register reads/writes hang the Core 0 processor.

    We have 3 boards, w/ 2 6670 on each, and they all appear to act similarly.

    Any help would be greatly appreciated.

    Thanks,

    Erick

  • It's been reported through the local FAE that this issue has been resolved.  I'm going to close this thread.  Please respond back if that is not the case.

    Best Regards,
    Chad

  • Chad,

    The main issue, has been resolved, the PCIESSEN pin on the new board was set high at boot, enabling the PCIe however since we are not using the PCIe, we do not have a clock input to the module.  Setting the PCIESSEN pin low seems to have fixed the majority of our issues. Could this explain what we were seeing? If it does, I don't see anywhere in the data sheets that explain that this module would effect the Multicore Navigator in a way that would harm access to it.  If we could get some sort of explanation for that it would be greatly appreciated.

    Even after this however, we are still running into an issue trying to JTAG a large application into the processor for Core 0.  The application appears to load, however it goes straight into "Running" mode once loaded, and when we halt Core 0, the Program Counter is at the Boot address (0x20B0CA74).  The Core 0 however is not in a hung state, so we can still alter registers and access memory.  This application loads and runs fine on the other cores (1-3), however only Core 0 seems to have this issue.  We can also load and run this application using a secondary bootloader (on Core 0), so it appears to be a JTAG issue with Core 0.  This is a pretty large application, as smaller one seem to load and run fine via JTAG into Core 0.

    Again, any help or suggestions on this would be greatly appreciated.

    Thanks,

    Erick

  • Ok, figured out the JTAG issue, for some reason when the "Reset the target on a program load or restart" check box was checked, it caused the error where the PC would reset the processor after the application had been loaded.

    Not sure why it only affected Core 0 or why the issue didn't cause errors for small applications, but it now works fine w/ any application.

    Would still like to know if there is any documentation we could refer to that we may have overlooked, that could explain some of the problems that we were running into.

    Erick

  • Erick,

    Glad to hear it's working now.  As far as clarification on this last issue.

    Can you tell me how specifically the PC is performing the reset, I can have someone look into why this may have had an issue with the 'Reset the target on a program load or restart'.

    Best Regards,

    Chad