CCS/TMS320DM642: Not able to debug: Data verification error occured, file load failed.

Daniel,

Indeed you seem to have followed our suggestions at the page and at this point I would start suspecting that something may be physically wrong with the memory itself. 

To thoroughly inspect this, I would perhaps try to do a burn-in or a walk test on the external memory to try and find any inconsistencies with it. Spectrum Digital still has the Board Support Library examples available for download where a SDRAM test is available there.

http://c6000.spectrumdigital.com/evmdm642/

The projects were designed for very old versions of CCS, but they are probably easily imported into a newer version of CCS (I don't think they use DSP/BIOS, which complicates things). At any rate, you could potentially create your own using their routine as a base. 

Apart from this,  I can't really think of any other issues that may be happening in this case, apart from a bad JTAG connection that is corrupting the data transfer (highly unlikely). I thought about cache issues as well, but the JTAG memory load bypasses the cache altogether. 

I will reply back in case I think of anything else that could be relevant. 

Hope this helps,

Rafael

Hi Rafael,

I have new findings about this problem. If I do many retries for debugging, after an arbitrary number of retries the debugging works. The address in the error messages are only increasing are equal (not decreasing). The number of retries can be over 10 before debugging works.

Here is an example:

Click on Debug Symbol (first time):

C64x: File Loader: Verification failed: Values at address 0x00000001 do not match Please verify target memory and memory map.

C64x: GEL: File: C:\PROJECTS\xxxx\xxxx\Debug\example.out: a data verification error occurred, file load failed.

Click on Debug (second time):

C64x: File Loader: Verification failed: Values at address 0x00000001 do not match Please verify target memory and memory map.

C64x: GEL: File: C:\PROJECTS\xxxx\xxxx\Debug\example.out: a data verification error occurred, file load failed.

Click on Debug (third time):

C64x: File Loader: Verification failed: Values at address 0x80000000 do not match Please verify target memory and memory map.

C64x: GEL: File: C:\PROJECTS\xxxx\xxxx\Debug\example.out: a data verification error occurred, file load failed.

Click on Debug (forth time): Now debugging is working

Why do I have this behavior? After debugging works the first time, it is no problem to stop debugging and start debugging again, as long as the hardware with the processor is supplied with power. Once the hardware is power cycled, the procedure as described above is necessary to be able to debug again. Thus, debugging is very time consuming. With another processor from TI (other project) and the same Spectrum Digital emulator/debugger, this problem cannot be reconstructed.

I am looking forward to hearing from you. Thanks in advance!

Best regards,

Daniel

Daniel,

It is quite difficult to pinpoint an exact reason for the subsequent failures, short of linking them to a hardware failure or a bad bootmode.  

The first error message is quite revealing, as the memory address belongs to the internal RAM and should be properly accessible at all times. If the cache is turned off, the Debug Probe should be able to write to this address without problems. Can you confirm that cache is disabled when trying to load code? You can manually launch the debugger and confirm that configuration - check section 7.3.2 of the CCS User's Guide at:

https://software-dl.ti.com/ccs/esd/documents/users_guide/index.html 

The third error message corresponds to the inability to write to external DDR, but that would require proper initialization of the device via a GEL file. Given this seems to be happening at a later stage, I would focus on the reason why the first error is happening first. 

The subsequent launches leading to a working hardware may be due to the fact that each step may be configuring the device little by little until it reaches a stable state. I have seen this in the past, although with not so many steps (typically two). 

I will try to think about additional details that may be contributing to this scenario and report back in case I find anything relevant. 

Hope this helps,

Rafael

Hi Rafael,

thanks for responding to my problem. I tried to launch the debugger manually (launch, connect) and then load the .out File manually with "Program Load" option. I observed the same problems.

Can you please explain me how to disable the cache? I need to know this, to confirm you that cache is disabled.

Thanks in advance.

Best regards,

Daniel

Daniel,

I am not the most knowledgeable about this device, but please check the thread below regarding the methods to enable/disable L2 cache.

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

Hope this helps,

Rafael

Hi Rafael,

I adapted my GEL File using the EVMDM642.gel default file. For example I added the onRestart function which turns off L2. There is no function which explicitly disables L1 and L2 cache. After this adaptations the debugging works after one retry, but unfortunately following error message appears very often:

C64x: GEL Output: GEL Reset DSP3. (OnReset)
C64x: GEL Output: GEL StartUp Complete. (Startup)
C64x: GEL Output: GEL Reset DSP3. (OnReset)
C64x: GEL Output: GEL Prepare Program Load. (OnPreFileLoaded)
C64x: Trouble Writing Register PC: (Error -1141 @ 0x0) Device is not responding to the request. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 7.0.48.0)
C64x: GEL Output: GEL DSP3 Restarted. (OnRestart)
C64x: GEL Output: GEL Program Loaded. (OnFileLoaded)

Do you have any idea what is wrong? Do I have to disable L1 and L2 cache in any other function as well?

Best regards,

Daniel

Daniel,

One question: to help further isolate the root cause of the issue, did you try to launch the debugger manually but without a GEL file? This could give additional hints about the state of the JTAG connection and the device itself. 

Another aspect that occurred to me: can you enable the option Reset the target on a connect and launch the board? This may trigger a CPU reset that can put the device in a more stable condition before connecting (and even running the GEL routines). Details can be seen at section 7.2.4 of the CCS User's Guide linked before. 

During the instability, you can disconnect all cores and issue a "Reset Emulator" to try and recover the JTAG state machine. This is usually not needed, but at this point I would try everything. 

Details about the reset  can be found at the Reset Types page at:

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

If that does not bring a reliable operation, I am starting to suspect again that something may be wrong with the JTAG connection itself - that would be confirmed if, after connecting to the device correctly, the connection is showing some sort of instability (by moving cables and such).

You could try to issue a continuous data transfer using the low-level JTAG utility dbgjtag and then wiggle the cables to see if this can expose any problems. Check step 6 of the Hardware checklist section of the Debugging JTAG page at:

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

Hope this helps,

Rafael

Hi Rafael,

I tried both possibilities, with the automatic debugging option and with manually launching the debugger. Connecting the debugger always works fine. Errors occur once the software is loaded to the device with "Program Load".

By playing around with the .GEL file either the "Device is not responding to the request." or the "Verification failed" error occurs, but the "Verification failed" error now normally needs only two tries until debugging works.

The JTAG connect seems to be ok after testing it.

Best regards,

Daniel

Hi, Daneil,

Unfortunately, the CCS group worked with you doesn't know what the cause it can be. We, the device group, do not have any collateral or resource beyond what you see in the DM642 product folder. You may search the E2E forum for archived posts of previous discussions which may help address your questions or issues. For more info on TMS320DM642 support, please see the FAQ in 

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

 Regret the inconvenience and lack of guidance on this.

Rex

Hi,

I found the problem. The video ports write into memory during loading the program, that is why the verification fails. But actually I do not understand this.

I expected that during program load, the cores are halted and therefore everything is frozen. Furthermore I had the "Reset_VideoPorts" functions in the "OnPreFileLoaded()" function, but this does not have any effect. I have to manually launch the target configuration, connect to the target and before loading the program I have to manually call the GEL script "Reset_VideoPorts" via hotmenu. This procedure is very inconvenient and time consuming.

Can you please explain this behavior and maybe do you have any hint for improving/accelerating my debugging procedure.

Thanks in advance.

Best regards,

Daniel

user4990587 said:

I found the problem. The video ports write into memory during loading the program, that is why the verification fails.

Ah, that is helpful info. The verification likely fails because the memory is changed after the program load but before (or during) the verification process.

user4990587 said:

expected that during program load, the cores are halted and therefore everything is frozen.

The target itself is halted. But I would imagine that other peripherals can still be active and access memory during this time.

user4990587 said:

Furthermore I had the "Reset_VideoPorts" functions in the "OnPreFileLoaded()" function, but this does not have any effect.

What does this function do? Also note that not all GEL actions are synchronous. It could be possible that the action was not yet completed when the program load is done.