• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 102 subscribers
  • Views 370 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.

Original question:

File Loader: Verification failed: Values at address 0x00000000C3000000

SM320DM6446-HIREL: Issues with XDS200 & loadti on Linux box: failing with File Loader: Verification Failed

Shawn Standfast22
Intellectual 400 points
Part Number: SM320DM6446-HIREL
Other Parts Discussed in Thread: CCSTUDIO

Hi,

Thanks for looking at my issue.  First, a little background on what we are trying to do; we are developing a test stand that will be used to verify production processor boards that contain SM320DM6446-HIREL processors on them.  The idea is that the test stand will automate the testing and programming of new production processor boards.  We currently have a manual setup for doing this which will be replaced by this automated test set.

The current manual process uses a Windows based machine and connects to the Spectrum Digital XDS200 emulator through loadti, which is launched via a .bat file.  This downloads and runs test application software into the DDR2 memory of the Unit Under Test (UUT) to verify UUT functionality.  This process has worked well for several years.

The new automated test set duplicates this process, but runs the loadti application from a Python script on a Linux box.  This is what has been giving us trouble.  We are regularly seeing a communications error with the JTAG device.  This is the error message that the software developer sent me:

***** DSS Generic Loader *****

 

START: 14:29:13 GMT-0600 (CST)

 

Configuring Debug Server for specified target...

Done

TARGET: Texas Instruments XDS2xx USB Debug Probe_0

Connecting to target...

testEnv.outFiles: /home/devel/PycharmProjects/LPEFD_SRA/MemTest.out

Loading /home/devel/PycharmProjects/LPEFD_SRA/MemTest.out

SEVERE: ARM9_0: File Loader: Verification failed: Values at address 0x87FFB000 do not match Please verify target memory and memory map.

 

SEVERE: ARM9_0: GEL: File: /home/devel/PycharmProjects/LPEFD_SRA/MemTest.out: a data verification error occurred, file load failed.

 

SEVERE: File: /home/devel/PycharmProjects/LPEFD_SRA/MemTest.out: a data verification error occurred, file load failed.

SEVERE: Error loading "/home/devel/PycharmProjects/LPEFD_SRA/MemTest.out": File: /home/devel/PycharmProjects/LPEFD_SRA/MemTest.out: a data verification error occurred, file load failed.

Error code #4011, /home/devel/PycharmProjects/LPEFD_SRA/MemTest.out load failed!

Aborting!

SEVERE: ARM9_0: Unable to terminate memory download: NULL buffer pointer at 0x320

 

 

END: 14:29:18 GMT-0600 (CST)

We are running the exact same .OUT and .GEL files on this machine that we have been successfully running on the Windows based machine.  For some reason this Linux box is giving us trouble.  The issue can persist for many attempts, but eventually we can sometimes get the .OUT file to load correctly. (usually after several attempts at restarting the machine and/or un(re)-plugging the XDS200 from the USB port).  And surprisingly, once the programmer connects once, we never have any trouble with connection issues again until we shutdown the test set.  This is important because during a full UUT test, we power-cycle and load new .OUT files at least a dozen times per board.  I've asked which specific flavor of Linux we are running and will update here when I have that information.  We've verified that the XDS200 has the latest firmware loaded.  We also do not use the DSP core on the DaVinci, just the ARM.  Also, I know this error message calls out MemTest.out, but it is not restricted to just this specific .OUT file.  This just  happens to be the first test that the test set tries to run.  We get the same error if we try and run other test programs as well.

Any help you can provide for correcting this issue would be greatly appreciated.

Thanks,

Shawn

  • 0
    Intellectual 400 points

    I just received confirmation that the test set is running Ubuntu 18.04 LTS if this helps.

    Thanks,

    Shawn

  • 0 in reply to Shawn Standfast22
    TI__Guru 50170 points

    Hi, Shawn,

    DM6446 is an old device. We do not have any collateral or resource beyond what you see on the product folder. You may search the E2E forum for archived posts of previous discussions which may help address your questions. For more info on DM6446 support, please see the FAQ in 

    https://e2e.ti.com/support/processors/f/791/t/813421

    Rex

  • 0 in reply to Rex Chang
    Intellectual 400 points

    Hi Rex,

    Thanks for the response. I have searched several places for information I can use to figure out what is going on with this setup and the closest I've come to finding anything that relates to our issue is the situation described in the original posting I asked this related question to. I do think it is not related to the DaVinci specifically, and is more of an XDS200/LOADTI/Linux compatibility issue.  The solution described in the original poster's situation was to separate the connection/programming steps instead of running them from the debug button.  That works fine if debugging inside CCS but can this be applied to loading with loadti and DSS?  If so, can you point me to instructions for how to do this?

    I've also noticed that there seems to be several known issues with the XDS200 and linux so I was curious if what we're seeing could be related to one of the many linux/USB connectivity problems documented. The information I've seen on your site doesn't cover our situation exactly so I was coming to the experts for advise.

    Thanks,

    Shawn

  • 0 in reply to Shawn Standfast22
    TI__Guru 50170 points

    Shawn,

    I'll check around with other group on xds200 and Linux compatibility.

    Rex

  • 0 in reply to Shawn Standfast22
    TI__Guru**** 168994 points

    Shawn,

    The ARM9 core of the DM6446 device requires adaptive clock. Do you have this set up in your CCS?

    This could potentially cause problems in code load, especially if the TCLK is fixed and set to a high value (the default 10MHz). 

    Regarding the Linux and XDS200, there were indeed several problems with certain firmware revisions, as mentioned on  the troubleshooting section of the XDS200 page at:

    https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds200.html 

    However, using CCSv9.3.0 and the latest firmware 1.0.0.9 on Ubuntu 16.04 and 18.04 has been working quite well.

    Below follows attached the .ccxml file that I configured with adaptive clocking. Unfortunately at the moment I don't have my DM6446 board easily accessible to perform testing. 

    Hope this helps,

    Rafael

    00_test.ccxml

  • 0 in reply to desouza
    Intellectual 400 points

    Hi Rafael,

    Thanks for the response. I'm pretty sure we've got adaptive clock control enabled in our .ccxml as well but I will verify with the software developer. Recall were aren't using ccstudio directly to load with in third machine, just  DSS via LoadTI.  I will also verify which version of ccstudio is installed on the test set and make sure it's v9.3.0 or newer.

    Thanks again,

    Shawn

  • 0 in reply to Shawn Standfast22
    TI__Guru**** 168994 points

    Shawn,

    Shawn Standfast22 said:
    Recall were aren't using ccstudio directly to load with in third machine, just  DSS via LoadTI.

    Yes, but even the loadti will require a .ccxml file that accurately describes the hardware.

    At any rate, please let me know the outcome of this scenario. 

    Regards,

    Rafael

  • 0 in reply to desouza
    Intellectual 400 points

    Hi Rafael,

    Our .ccxml file was already using the adaptive clock feature so that wasn't the issue.  But ee think we have it figured out. The Windows development machine we wrote the software on was using CCS v9.x.x, but the linux based test set that actually executed the software was running CCS v8.x.x.  We upgraded the version of CCS on the test set and that seems to have stabilized our ability to connect to production hardware.  Thanks for your help.

    Regards,

    Shawn