• State Answer Suggested
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 1196 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

C6671 package designator and SPI boot issue

Tomek Bialecki
Prodigy 50 points
Other Parts Discussed in Thread: TMS320C6671

We are manufacturing an image engines based on TMS320C6671 (and
plenty of other TI modules). We built a first production series
several months ago without any issues. The first production boards
are booting from SPI and executing simple boot loader code.
The boot loader configures PLL for 1 GHz DSP operation, configures
EMIF-16 interface for co-operation with external parallel FLASH
memory and FPGA, copies portions of the target firmware from FLASH
to the core SRAM memory and finally jumps to the regular firmware
entry address already in SRAM.

Right now, we have just received first 5 boards from a fresh
production lot, where the manufacturer is not able to finish
functional quality check procedure and the entire production is
suspended. The DSP is not able to successfully boot the code from
SPI, even though the code didn't change compared with the previous
production lot.

After removing DSP heat sink, we noticed that processor ICs have
a slightly different marking compared with previous production.
There's a letter "A" in the top-right corner of the package. It's
not directly defined, but we suppose the letter "A" stands for
extended temperature range of the device (CYPA) and manufacturer
bought them by mistake instead of the regular DSP type (CYP). Maybe
the "A" stands for a die revision. A photo is attached. Both
production lots have processors with "YB20" inscription below part
number line, only the "A" letter in the top right corner is
different between two series. The most important question is, can
somebody please decipher the difference in package marking?

After some struggle with power sleep controller, which was required
to enable power for EMIF-16 when booting code via JTAG emulator,
we're able to run the new production boards without problem if the
boot loader code is transferred via emulator and not booted from the
SPI. All further functionality: DDR-3 and other peripherals are
working just fine. The only problem lays in SPI booting. In fact
there are two scenarios of unsuccessful booting illustrated in the
two attached scope waveforms (clock + chip select). Sometimes the
system stops reading from SPI early. Sometimes it reads the entire
boot loader content, sets boot complete pin but still doesn't
execute the boot loader code properly.

Did the boot procedure change between non-"A" and "A" devices? Any
description of this change? Our SPI boot device is not a typical
FLASH memory, so it may be a problem. However it works in tens of
devices from the previous production and in none of the five devices
we received right now, so a specification of the timing or a hint
what are the most common design errors in the SPI booting area would
be very useful.

  • 0
    TI__Mastermind 28085 points

    Hi,

    For my understanding, Your First production boards are mounted non "A" DSP devices and it booting form SPI successfully. Second/Fresh  production boards are mounted "A" DSP devices, it is not booting form SPI. Is it correct?

    I will check with DSP SOC team for difference between non-"A" and "A" devices and get back to you.

    Thanks,

  • 0
    TI__Guru** 116630 points

    Hi Tomek,

    Just to clarify, the same ROM bootloader is used on devices of all temperature range so that shouldn`t be an issue. Can you specify what atypical Flash memory is used for Flash boot. Is the processor type the only change betweeen the boards that could potentially impact the SPI interface.

    After the boot fails have you tried to connect to the device without a GEL file and see where the Program counter is at.  Is it still stuck in the ROM memory space or is it in the secondary bootloader code space. In order to get a status of boot and your PLL configuration at boot, can you run the scripts from this debug GEL file(use the C6678 version) provided in the following wiki and provide us a dump.

    Regards,

    Rahul

  • 0 in reply to Ganapathi Dhandapani95
    Prodigy 50 points
    Ganapathi.

    Yes. That's exactly the case. Previous production boards don't have
    the additional "A" mark on the chip surface and all boot correctly.
    The new production all have the "A" symbol and all fail during every
    boot attempt. There's a consistent difference. Therefore we ask for
    the meaning of the inscription. We believe, that the different kind of
    the DSP is revealing our bug. Knowing how the chips are different
    would help us to isolate the problem.
  • 0 in reply to Tomek Bialecki
    TI__Mastermind 46460 points

    The 'A' is not the silicon revision.  That is reflected in the '20' in the code under the part number.  This is a PG2.0 device.  What was the revision of the silicon in the initial batch of boards?

    I have requested an explanation for the 'A' on the top of the package.  I will post an explanation when I have it.  The guess that it stands for Extended Temp is probably correct.

    Please provide a zoomed-in image of the SPI transfer showing the clock and data alignment and signal integrity.  The initial accesses when the boot table is loaded are the most critical.  Also, provide a similar capture from a working board.

    Tom

     

  • 0 in reply to Rahul Prabhu
    Prodigy 50 points

    Rahul,

    R> Just to clarify, the same ROM bootloader is used on devices of all
    R> temperature range

    Yes. The same ROM bootloader is used on devices of both kinds: both
    temperature ranges if the "A" really stands for the extended
    temperature range (which still isn't directly clear for me, so please
    confirm).

    R> Can you specify what atypical Flash memory is used for Flash boot.

    We don't use a typical FLASH module. We use a part of programmable
    logic, which mimics Micron N25Q128A or similar type of quad FLASH.
    Since it's not a typical memory I would expect a potential source of
    problems in the incorrect implementation of the SPI protocol in our
    logic. Still, it consistently works with the "non-A" DSPs while it
    doesn't with the "A" marked ones.

    R> Is the processor type the only change betweeen the boards that
    R> could potentially impact the SPI interface.

    Theoretically yes. However, it's a new production lot: the
    manufacturing robots are fed with freshly purchased components. This
    means, there may be some other, unintended difference in the five
    devices causing problems.

    R> After the boot fails have you tried to connect to the device
    R> without a GEL file and see where the Program counter is at.

    The problem is, CCS won't allow us to connect through JTAG after an
    unsuccessful SPI boot attempt. We get a whole range of different
    errors reported: -1180, -1143, -1144 and -1178. However, if we disable
    SPI boot mode via Boot Mode Pins - we are able to connect CCS through
    a JTAG emulator without problems - and run bootloader code without
    issues.

    I'm still fighting with executing the Shannon System Debug GEL file
    when booting from FLASH is disabled. The script can be loaded and
    displays "Success" status but doesn't output anything to the console
    after reloading. It may still take some time to master it.

    Thanks.

  • 0 in reply to Tom Johnson 16214
    Prodigy 50 points

    Tom.

    T> What was the revision of the silicon in the initial batch of boards?
    The old ones seem to be PG2.0 as well. The text on the initial batch
    is following:
    DSP
    TMS320C6671CYP
    YB20-22ZESF9
    (c) 2010 TI 2 CYP G1

    T> Please provide a zoomed-in image of the SPI transfer showing the
    T> clock and data alignment and signal integrity.
    Since it's a BGA to BGA connection, we don't have the data pins
    directly available for a scope measurement. If other methods fail, we
    may duplicate data signals and generate copies on some spare FPGA pins
    to prepare requested waveforms.

    There's another idea we want to check first. Since the DSP never
    fails to read the first portion of data from the SPI, but fails in
    different moments afterwards; we may have some incorrect entries in
    the Boot Parameter Table (incorrect SPICLK edge for probing data, PLL
    config out of range, wrong SPI chip select mode, etc). Anyway, the
    "non-A" DSPs are able to cope with the potentially incorrect parameter
    table, while the new ones cannot. Is there any manual/documentation
    for the romparse .map file structure? This could help in our
    verification.

    Thank you.

  • 0 in reply to Tom Johnson 16214
    Prodigy 50 points

    OK. We identified, what's causing the "A" variant of the DSP not to
    boot properly. Boot Parameter Table PLL settings were copied from
    a reference hardware configuration and were not adapted to our 1 GHz
    unit with a 100 MHz oscillator. Putting proper values to the romparse
    .map file fixes our problem. Still, there are two open questions.

    1. What's the difference between "A" and "non-A" variant of the 6671
        processor? Ganapathi and Tom promised an explanation. Is it
        possible, that the PLL configuration from the Boot Parameter Table
        is ignored in one of the variants and interpreted in the other:
        therefore incorrect PLL multiplier doesn't harm the boards from
        a previous production? The effective difference is very
        distinctive: tens of boards from the previous production - boot
        with the incorrect PLL settings without problems while none of the
        five "A" boards from the current production ever booted until we
        fixed the PLL configuration in the Boot Parameter Table.

        a) Marking on the DSPs living through incorrect PLL config:
            *
            ti                         DSP
            TMS320C6671CYP
            YB20-22ZESF9
            (c) 2010 TI 2 CYP G1

        b) Marking on the DSPs failing to boot with wrong PLL config:
            *                            A
            ti                        DSP
            TMS320C6671CYP
            YB20-37ZCQ49
            (c) 2010 TI 2 CYP G1

    2. Some application note or user guide for the romparse application
        would be very useful. We cannot find an explanation of the .map
        file syntax and parameters. Is it available online?

    Thank you.

    Tomek.

  • 0 in reply to Tomek Bialecki
    TI__Mastermind 46460 points

    Tomek,

    Glad to hear that you got it working.  I am waiting for an answer regarding the 'A' on the package from our Production Engineering team.

    Tom

     

  • 0 in reply to Tomek Bialecki
    TI__Guru** 116630 points

    Hi Tomek,

    The romparse utility is provided in source under the MCSDK path mcsdk_2_01_02_06\tools\boot_loader\ibl\src\util\romparse. The IBL documentation doesn`t seems to not cover anything regarding the utility so it looks like you will need to check the source for understanding. We have filed an bug report regarding this in the past to get it fixed but that doesn`t seem to be resolved yet.

    I have posted documentation specific to the PLL fields in the romparse .map file in an e2e thread earlier. Please take a look and let me know if that doesn`t match your understanding.

    Regards,

    Rahul