• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 101 subscribers
  • Views 266 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320C6655: SPI stops clocking

Mitch Mandler
Prodigy 160 points
Part Number: TMS320C6655
Other Parts Discussed in Thread: TM4C129ENCZAD

We use a TMS320C6655 DSP in our design and we configure it for SPI boot mode.  We have a TM4C129ENCZAD micro-controller sending the DSP code to the the DSP as an SPI slave device.  Most of the time, everything works fine and the DSP code gets sent and executed without an issue.  But occasionally, I will see cases where it seems like the DSP stops clocking the SPI bus in the middle of loading the DSP code.  I believe the DSP stops clocking the SPI bus because the TM4C129ENCZAD is stuck waiting for its TX FIFO to not be full.

Why would the DSP stop clocking the SPI bus?  Has anyone seen this before?

  • 0
    TI__Guru** 114410 points

    Mitch,

    We have not seen the issue with booting the C6655 device from SPI NOR flash devices. Can you please explain the boot setup for us to provide guidance. What is the DEVSTAT setting used ? What is the value of the program counter when the DSP stops the clock or hangs? Can you provide scope shots of working vs non working test case? Is the SPI connected in 4 pin mode and when the clock stops, do you see the CS to be low but clock doesn`t occur?

    For SPI boot, I believe SPI clock is sourced from PLL in bypass state so DSP PLL should be running at input clock. Are you sure there is no issue with clocking of the DSP. Please indicate why you think the DSP stops the clock  because of the TM4C129ENCZAD waiting for TX FIFO to be full. Is that something that you noticed as part of the debug that the clock stop occurs during this state.

    Regards,

    Rahul

    PS: the ROM code for C665x devices is available for reference here:

    http://software-dl.ti.com/sdoemb/sdoemb_public_sw/rbl/1_0_C6657/index_FDS.html

  • 0 in reply to Rahul Prabhu
    Prodigy 160 points

    Hi Rahul,

    Thanks for clarifying that you have not seen any issues like this on C6655.  We have actually started to think this issue is a manufacturing issue with our board so we are working with the board manufacturer now and I had to send the board exhibiting this issue back to them.  So I can't look into the Program Counter when this happens or provide scope shots at the moment.

    To clarify some of your other questions:

    1. DEVSTAT should be set to following:
      1. LENDIAN = 1
      2. BOOTMODE = 0x806
    2. We are using 4 pin mode
    3. This is the boot parameter table we are using:

      uint16_t DSPBoot::m_boot_param_table[] =
      {
      0x2800, // 0: Length of 0x28 bytes.
      0x0000, // 2: Checksum U16 is unused
      0x3200, // 4: Boot mode of 0x32 (50) indicates SPI boot
      0x0000, // 6: Port Num
      0x1840, // 8: PLL MSW: Enabled, multiplier of 24, Pre-divider 0 (divide by 1)
      0x0100, // 10: PLL LSW: Post-divider 1 (divide by 2)
      0x0100, // 12: 1-Load boot records from the SPI (boot tables)
      0x1000, // 14: Address Width: 16 bits
      0x0400, // 16: NPin: 4-pin SPI
      0x0200, // 18: ChipSel 0
      0x0100, // 20: SPI Mode 1
      0x0000, // 22: C2T Delay 0
      0xe204, // 24: DSP freq 1250MHz
      3 << 8, // 26: SPI freq MHz
      0x0000, // 28: SPI Freq KHz
      0x0000, // 30: Read Addr MSW
      0x0004, // 32: Read Addr LSW
      0x0000, // 34: Next ChipSel
      0x0000, // 36: Next Read MSW
      0x0000, // 38: Next Read LSW
      };



    We are using these parameters from an spiboot.c file for the DDR configuration:

    #pragma DATA_SECTION (emif4Cfg, ".emif4Cfg")
    const BOOT_EMIF4_TBL_T emif4Cfg = {

    BOOT_EMIF4_ENABLE_MSW_pllCtl | \
    BOOT_EMIF4_ENABLE_MSW_sdRamTiming1 | \
    BOOT_EMIF4_ENABLE_MSW_sdRamTiming2 | \
    BOOT_EMIF4_ENABLE_MSW_sdRamTiming3 | \
    BOOT_EMIF4_ENABLE_MSW_ddrPhyCtl1 | \
    BOOT_EMIF4_ENABLE_MSW_sdRamRefreshCtl | \
    BOOT_EMIF4_ENABLE_MSW_sdRamOutImpdedCalCfg | \
    BOOT_EMIF4_ENABLE_MSW_sdRamConfig,

    BOOT_EMIF_ENABLE_SLSW_config0 | \
    BOOT_EMIF_ENABLE_SLSW_config6 | \
    BOOT_EMIF_ENABLE_SLSW_config7 | \
    BOOT_EMIF_ENABLE_SLSW_config8 | \
    BOOT_EMIF_ENABLE_SLSW_config9 | \
    BOOT_EMIF_ENABLE_SLSW_config10 | \
    BOOT_EMIF_ENABLE_SLSW_config18 | \
    BOOT_EMIF_ENABLE_SLSW_config19 | \
    BOOT_EMIF_ENABLE_SLSW_config20 | \
    BOOT_EMIF_ENABLE_SLSW_config22 | \
    BOOT_EMIF_ENABLE_SLSW_config12 | \
    BOOT_EMIF_ENABLE_SLSW_config23 | \
    BOOT_EMIF_ENABLE_SLSW_config21, /* Config select slsw */
    0, /* Config select lsw */

    3, /* pllPrediv */
    40, /* pllMult */
    2, /* pllPostDiv */

    0x62477AB2, /* sdRamConfig */
    0, /* sdRamConfig2, dont care*/
    0x0000144F, /* sdRamRefreshCtl */
    0x1333780C, /* sdRamTiming1 */
    0x30717FE3, /* sdRamTiming2 */
    0x559F86AF, /* sdRamTiming3 */

    0, /* lpDdrNvmTiming, dont care */
    0, /* powerManageCtl, dont care */
    0, /* iODFTTestLogic, dont care */
    0, /* performCountCfg, dont care */
    0, /* performCountMstRegSel, dont care */
    0, /* readIdleCtl, dont care */
    0, /* sysVbusmIntEnSet, dont care */
    0x70074c1f, /* sdRamOutImpdedCalCfg, dont care */
    0, /* tempAlterCfg, dont care */

    0x0010010F, /* ddrPhyCtl1 */

    0, /* ddrPhyCtl2, dont care */
    0, /* priClassSvceMap, dont care */
    0, /* mstId2ClsSvce1Map, dont care */
    0, /* mstId2ClsSvce2Map, dont care */
    0, /* eccCtl, dont care */
    0, /* eccRange1, dont care */
    0, /* eccRange2, dont care */
    0, /* rdWrtExcThresh, dont care */

    0x87A0047F, 0, 0, 0, 0, 0, 0x33, 0x3A,
    0x2C, 0x2C, 0x21, 0, 0xAF00002, 0, 0, 0,
    0, 0, 0xB7, 0xB1, 0xA4, 0xA4, 0x98, 0x200,
    0, 0, 0, 0, 0, 0, 0, 0,

    0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0
    };

    I am new to this project and I asked/web searched as to where this DDR3 configuration data came from and it looks like we just got it from a TI example ZIP file.  I am having problems finding documentation as to how to interpret what those values actually do though.  From web searches, it looks like a lot of people use that same exact configuration so is that correct?  Does that need to be tailored for the specific DDR3 part we are using?

    Thanks,

    Mitch

  • 0 in reply to Mitch Mandler
    TI__Guru** 114410 points

    Mitch,

    The DDR configuration structure is a pre-defined structure in C665x ROM code which we publish in tiboot.h bootloader folder in Processor SDK RTOS software here. You can locate that in the folder :

    pdk_c665x_2_0_xx\packages\ti\boot\ibl\src\device\c665x\tiboot_c665x.h

    If you have the C665x boot example, the example should also have the tiboot.h. We published the table in C667x datasheet but don`t seem to have this in the C665x datasheet. There is a literature bug that we are tracking for this issue. the structure used is tailored for the DDR3 used on the EVM and needs to be modified to be used on custom platforms.

    Generally using the ROM code for DDR configuration is not recommended since the DDR initialization has changed since the ROM code was created when the silicon was created. We recommend that you boot into MSMC then initialize DDR and then copy the rest of your application into DDR for better control.

    Regards

    Rahul