• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 366 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.

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

Roger Bastin
Prodigy 50 points
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

  • 0
    TI__Mastermind 27355 points

    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.

  • 0
    TI__Guru** 114410 points
    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
  • 0
    TI__Guru** 114410 points

    Roger Bastin said:
    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. 

  • 0 in reply to Rahul Prabhu
    Prodigy 50 points
    Hi,

    We had already looked at the external memory settings but we did revisit them and haven't found a problem there. We have also exercised several tests in the failing case where, with an ICE (used without GEL file init), we can read the contents of the "offending" section of memory and save it to file. With the file we confirmed that the data does get loaded properly into the section of memory, the AIS bootloader just seems to stop responding when it comes time to validate the CRC - we don't actually seem to get a CRC failure response, just no response. We can boot and run our DSP image without problems when CRC validation is off, so it would seem the memory is OK since we use it extensively. Also it is very odd that we can have a failure with CRC validation enabled with a certain size section, but then make the section larger, keeping the data the same in the original portion of memory, and then have the CRC check pass without error. We just want to enable CRC validation to ensure the DSP boot is robust but it seems to be faulty for certain conditions.

    Thanks,
    Roger