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

TMS320C6748: Bootloader - CRC fails repeatedly on a few PCBs

Steve Jewell
Prodigy 60 points
Part Number: TMS320C6748

I had 22 boards built and of those 22 this problem only occurs on 5 of the boards.  I bootload the TMS320C6748 as a SPI slave with an .ais file generated with the AISgen tool.  The microcontroller firmware that runs the boot up (SPI master) is the same on all 22 boards.  The .ais file is the same on all 22 boards.  I have verified that the .ais was successfully loaded onto all of the boards and is being written to the C6748 accurately.  

All of the initial handshaking is ok on all of the boards.  Following this several execute function commands are called.  Then CRC checking is enabled.  This is followed by several section loads and CRC checks.  That goes OK on all of the boards.  This continues to function OK until I get to the 4th section load and CRC check.  The 4th section load is at a significantly higher address than the previous 3.  At this point the 5 bad boards always report back an invalid CRC value.

I can't figure out why I have this problem on a limited set of boards.  What could have occurred during assembly on those few boards that the C6748 communicates perfectly fine on the bad boards until a section load at a higher address.  It doesn't seem like an assembly problem.  The firmware and .ais code are identical so I don't think there is a problem with that.  The good and bad boards both have the exact same part markings on the C6748 so I'm assuming they're the same silicon revision etc.  Those are:

TMS320

C6748EZWT

63A80ZW GI 450

527 ZWT

Has anybody encountered something like this before or have an idea what my problem could be?

  • 0
    TI__Guru**** 161600 points
    Hi Steve,

    I've forwarded this to the design team. Their feedback will be posted here.

    Best Regards,
    Yordan
  • 0
    TI__Guru** 114410 points
    When the Enable CRC checkbox is selected, AISgen adds extra commands in the AIS to check for errors while transferring/loading the application data. For master boot modes, the bootloader calculates the CRC over each section of the application data and checks it against the expected value from AIS. In case of an error, the bootloader loads the section again, re-calculates the CRC and checks again with the expected value. If a CRC error is found in three successive attempts, the boot process is aborted.

    Enable CRC ---> Section Load --> If Error --> Again Section Load ( the loop continues)

    For slave-boot modes, the external master reads the calculated CRC from the device and validates it against the expected value from AIS. In case of an error, it is up to the external master to decide how many times it wants to retry loading the section before reporting failure.

    We would recommend that you add a loop on the micro-controller that will retry the loading if CRC failure is reported. If you are booting this at high SPI speeds, you can also attempt to boot at slower speeds and see if that makes a difference. You can also try inserting some delays after section transfers to allow for better synchronization in the data transfers.

    Can you also clarify what you mean by higher memory. Is the code being loaded in DDR in section 4. If yes, then you may need to run memory tests on those devices to make sure that DDR has been initialized correctly and there is no issue with the timing configuration. Also another place where we have seen such similar failures is noise on the power lines that cause a data corruption that results in CRC failure.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Prodigy 60 points
    Thanks for your answer Rahul, to clarify a few things...

    The failure always happens at the same CRC check, on the same set of boards, no matter how many times I try to loop and reload the data to that section of memory. The CRC check never fails on the other boards. This doesn't sound like a random data transfer error to me. If that were the case I would expect it to happen intermittently and probably across all of the boards. I will try slowing down the SPI clock signal but considering that the problem doesn't exist on most of the boards, and communication is consistently good in the beginning with the problematic boards, I'm doubting this will fix the situation.

    To clarify about "higher memory", I mean higher memory address. The first 3 section load commands go to addresses 0x1182ece8, 0x1182f1e8, and 0x1182f400, respectively. Those all work. The problems occur on the bad board set when there is a section load to address 0xc7e052c8. I'm not sure if that address would put the data into DDR or not. I'll look into that and try to run a memory test.

    I'll also look into noise on the power line but I would assume that would also produce more random results with CRC errors.
  • 0 in reply to Steve Jewell
    TI__Guru** 114410 points
    YEs, the location 0xc7e052c8 is in external memory so this could be an issue with DDR initialization or timing.

    Regards,
    Rahul