• TI Thinks Resolved

TMS320C6746: Are there any known issues with ROM Bootloader CRC validation checks of DSP data sections in external DDR2 memory?

Part Number: TMS320C6746

Design Summary:

-Our TI C6746 image is downloaded in SPI slave mode using the AIS bootloader protocol. SPI is running @ 1MHz.

-The Image is produced using "AISgen for D800K008" tool from TI (version 1.13).

Problem:

The download and boot of the DSP seems to be fine without CRC validation enabled in the AIS image. When we enable CRC validation we consistently see failures during the AIS boot for a couple of sections of DSP data in external memory. The failures do not seem related to the contents of the data being loaded (various data patterns fail, even all 0s or all 1s) but they do seem to be dependent on the size of the data section being loaded - greater than ~40K but less than ~80k. To help narrow down the problem I now use a simple utility that can create any sized section at any desired address with also the standard ROM BL commands at the start of the simple AIS file (i.e. function commands for PLL & DDR config, plus CRC enable). Below are two samples of using this utility and trying to AIS load the DSP, first sample uses a section @ 0xC0000000 length 60000 bytes, the second just changes the length to160000 bytes. In both cases the data loaded is the same, just more data for the second case:

Failure with 60000 bytes:

Nov  9 12:43:18 [info] kernel: ais_boot: dsp-firmware: Loading section...
Nov  9 12:43:18 [info] kernel: ais_boot: dsp-firmware: Loading 60000 byte section to address 0xc0000000
Nov  9 12:43:19 [info] kernel: ais_send_data: exiting with status 0
Nov  9 12:43:19 [info] kernel: ais_boot: dsp-firmware: Performing Opcode Sync command 5: 0x58535902...
Nov  9 12:43:19 [info] kernel: dsp-i2c: Transition from AIS OS Completed state to AIS OS Started state
Nov  9 12:43:19 [info] kernel: dsp-spi: Transition from AIS OS Completed state to AIS OS Started state
Nov  9 12:43:19 [warn] kernel: AIS:dsp-firmware: Opcode Sync aborted after 10 consecutive I/O failures

Success with 160000 bytes:

Nov  9 12:40:10 [info] kernel: ais_boot: dsp-firmware: Loading section...
Nov  9 12:40:10 [info] kernel: ais_boot: dsp-firmware: Loading 160000 byte section to address 0xc0000000
Nov  9 12:40:11 [info] kernel: ais_send_data: exiting with status 0
Nov  9 12:40:11 [info] kernel: ais_boot: dsp-firmware: Performing Opcode Sync command 5: 0x58535902...
Nov  9 12:40:11 [info] kernel: dsp-i2c: Transition from AIS OS Completed state to AIS OS Started state
Nov  9 12:40:11 [info] kernel: mi:tel-dsp-spi: Transition from AIS OS Completed state to AIS OS Started state
Nov  9 12:40:11 [info] kernel: AIS:dsp-firmware: Opcode Sync passed after 1 consecutive I/O failures
Nov  9 12:40:11 [info] kernel: dsp-i2c: Transition from AIS OS Started state to AIS OS Completed state
Nov  9 12:40:11 [info] kernel: dsp-spi: Transition from AIS OS Started state to AIS OS Completed state
Nov  9 12:40:11 [info] kernel: ais_boot: dsp-firmware: Requesting CRC...
Nov  9 12:40:11 [info] kernel: ais_boot: dsp-firmware: CRC passed!
Nov  9 12:40:11 [info] kernel: ais_boot: dsp-firmware: Performing Opcode Sync command 6: 0x0...
Nov  9 12:40:11 [info] kernel: dsp-i2c: Transition from AIS OS Completed state to AIS OS Started state
Nov  9 12:40:11 [info] kernel: dsp-spi: Transition from AIS OS Completed state to AIS OS Started state

I've also tried the failing case, but with internal memory (0x11800000) as the location address and it passes fine and CRC validation is successful. Additionally I've verified that actual CRC failures get detected as such and CRC failure logs are generated so I believe its not actual CRC failures causing the problem.

Questions:

1) Are there any known issues with ROM Bootloader CRC validation for external memory that might be a clue to what we are seeing?

2) When CRC checking is enabled does the ROM bootloader in the DSP continuously update the CRC for the section being loaded as data arrives from the SPI bus or just calculate the CRC in a block after the entire section is loaded?

Any insight or suggestions for this problem would be much appreciated.

Thanks,

Roger

  • Hi Roger,

    Our expert on this subject is out of office today, we should have a response for you tomorrow.

    In the meantime, please see if this thread provides any assistance.


    Sahin Okur
    Applications Engineer

  • Roger,

    I have checked with the ROM author and can report that there is no known issue with the CRC calculation in ROM boot loader based on tests that have run with C674x and OMAPL13x devices which use the same ROM source. There are several customers in production with SPI slave boot.

    The region where you are loading the sections is external DDR2/mDDR region, is it possible that your external DDR memory is not initialized correctly and is causing these CRC errors. Since you are not seeing CRC failures loading into onchip memory, it may indicate some issue with your external memory initialization.

    As an experiment, I would connect to the chip when the boot fails loading code into DDR memory and then run a DDR diagnostic, read write program to check for integrity of your external memory and associated configuration. When connecting to DSP after the fail ensure that you remove the GEL file in the target configuration as the GEL will override the EMIF settings applied using the AIS configuration.

    Regards,
    Rahul

    --------------------------------------------------------------------------------------------------------------------------------------
    Please click the
    This resolved my issue button on this post if the responses on this E2E thread answers your question.
    --------------------------------------------------------------------------------------------------------------------------------------

     

  • Roger Bastin
    2) When CRC checking is enabled does the ROM bootloader in the DSP continuously update the CRC for the section being loaded as data arrives from the SPI bus or just calculate the CRC in a block after the entire section is loaded?

    When CRC checking is enabled, the address and size arguments are fed into the CRC update function in that order. After the section is fully loaded to memory, the section data is fed into the CRC update function beginning at the specified address. The same also applies to section fill command. 

    --------------------------------------------------------------------------------------------------------------------------------------
    Please click the
    This resolved my issue button on this post if the responses on this E2E thread answers your question.
    --------------------------------------------------------------------------------------------------------------------------------------