CCS: JTAG issues & scripting console

Hi Guy,

Guy Mardiks said:

almost every time i am trying to load a code for on of  IPU M4 i get a JTAG verification error on address 0. trying to reload the same program succeeds with no problems.

Can you reproduce the issue with debug server logging enabled and provide the generated log?

http://processors.wiki.ti.com/index.php/Troubleshooting_CCSv7#Debug_Server_Logging

Guy Mardiks said:

I don't know how can i resolve this problem and have no idea what is causing it. this is a real issue as it prevents me from being able to use scripts to load several cores (script halts when the error happens)

Does the above issue happen just from a script or when you manually do it from the IDE also?

Guy Mardiks said:

Sometimes the scripting engine stop functioning and currently the only way to able to work with scripts again is to restart CCS.

Is there a way somehow to restart/reinitialize the scripting engine/console?

Sorry, but this is a known limitation. If the script gets stuck somewhere, it *may* be possible to terminate it if you press CTRL+C rapidly in the console. But that does not always work. Closing the Scripting Console and reopening it does not help either (as you probably noticed already). You usually need to restart CCS

Thanks

ki

Hi,

I reproduced the issue and the log file is attached,

the exact error i received:

Console output:

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

Cortex_M4_IPU1_C0: GEL: File: IPU1_C0b/Debug/IPU1_C0b.out: a data verification error occurred, file load failed.

JS console output:

Error loading "IPU1_C0b/Debug/IPU1_C0b.out": File: IPU1_C0b/Debug/IPU1_C0b.out: a data verification error occurred, file load failed.

i get these immediately after sending the loadProgram command.

This issue appear both when using JS and when manually from IDE.

I did saw that a lot of time, if i disable the autorun - means load will only load and not try to start running (till main) then the load passes fine and then when i can let it run with no errors. after some more tries it seems autorun disable only reduced the probability of the error to happen but it still does...

Thanks

Guy1104.ds.log

Thanks Guy,

Can you try enabling full data verification in the debugger options and see your reloads are still successful? You can access them from the debugger options:

Do you have the IPUs in a sync group?

Regarding one of your older comments"

Guy Mardiks said:

this is a real issue as it prevents me from being able to use scripts to load several cores (script halts when the error happens)

To workaround this, you can have your script catch the exception and handle it appropriately to prevent script termination (probably have the handler reload the program). This way it won't break your automation.

http://software-dl.ti.com/ccs/esd/documents/users_guide/sdto_dss_handbook.html#exception-handling

Thanks

ki

Hi,
Thanks I will try but can you please tell me how to enable it also from a debug script (it is easier to reproduce with a script as the issue happens in random)

Thanks
Guy

Hi,
We have found the syntax for the script to change verification options:
debugSession.options.setString("VerifyAfterProgramLoad", "Full verification");

At first it seems to behave better but after a few more tries it finally happened again (this time on a "manual load" but verification was set to full), so it does not seem to resolve the problem.

Can you please elaborate on what these options are - what does it actually do and explain more about the verification process?

Another issue I am having is that from some reason loading one of the M4 cores takes forever (can get ~1min) with no apparent reason. also it seems that the slow load happens when loading from script, while if loaded manually it mostly loads pretty much immediately (but it could be a coincidence).

Can you please help with this issue too - this really hinders our work.

Thanks
Guy

Guy Mardiks said:

At first it seems to behave better but after a few more tries it finally happened again (this time on a "manual load" but verification was set to full), so it does not seem to resolve the problem.

When you say it behaves better, do you mean that the first load will sometimes succeed? And when the problem does come back, does it mean that the first attempt will fail but the second always succeed?

Anyway it is interesting that full verification will make it behave a bit better.

Guy Mardiks said:

Can you please elaborate on what these options are - what does it actually do and explain more about the verification process?

Verification, in this context, refers to the debugger comparing the contents of what was loaded to memory vs the contents of the file. It is verifying if the data was written to memory correctly. The default debugger option is "Fast" verification. It just checks a few key locations for differences. "Full" checks everything. We don't default to "Full" because it takes longer. I would expect that "Full" verification would catch more issues.

You could also try "No" verification and see if the error is a false positive by trying to run the application when first loaded. If it is always successful, then there is some issue with the verification process that first time

Guy Mardiks said:

Another issue I am having is that from some reason loading one of the M4 cores takes forever (can get ~1min) with no apparent reason. also it seems that the slow load happens when loading from script

It is hard to say with more details. Try enabling verbose logging and attach the log to this thread.

Thanks

ki

Hi, Thanks.

When i said "Seems to behave better" i meant that on the first tries we have done it was loaded successfully but then, after a few more i got the error again - so it was just random - basically it did not change anything and the behavior is the same.
so far the second load was always successful so i am using your suggestion with the try - catch block and that at least enables me to run the script.

I will try with no verification and let you know what comes up .

B.T.W
the verification error is always for address 0, also if from the memory browser ask to look at address 0 and then do the load it always (it least so far) was always successful too. it behaves as if something in the debugger's memory map was not properly loaded.
I tried do a read from zero in the script before the load but that did not help but it could be that the read i made in the script is a different operation than the one made when reading with the memory browser.

As for the slow load,
i tried,again, to start from a clean workspace and it seems to be loading faster now.

Thanks
Guy

Guy Mardiks said:

I will try with no verification and let you know what comes up .

Please let us know the result of this. Thanks

ki

Hi,
I have tried a few times with "no verification", and so far, at least, there were no errors from the JTAG and the code seemed to be executing fine.
But i must stress that there is no way to be sure that it is ok since:
a) the error appeared in random - there were times that i got no issues at all ...
b) if something is actually not written properly there is no way to know what this may cause - which is a concern in its own (the upside about it is
that i hope it is only a JTAG issue )

Do you think someone will be able to take a look at the verification process to try get a clue as to what is happening and what may cause it to fail without a real reason (could it be that the verification process itself may corrupt the memory)?

Thanks
Guy

Thanks for trying. This is what I was suspecting also. This issue has appeared in the past (false positive on the verification error), which is why I suspected the same is going on here.

Guy Mardiks said:

Do you think someone will be able to take a look at the verification process to try get a clue as to what is happening and what may cause it to fail without a real reason

Yes, it is important to get to the root cause of this issue. If you can provide a reproducible test case, that would be great. It doesn't have to be your real application, just a simplified version - or anything that can reproduce the issue. I would just need the executable file to load.

Guy Mardiks said:

(could it be that the verification process itself may corrupt the memory)?

No, the verification does not write to memory, only read.

Thanks

ki

Hi,
I cannot (for obvious reasons) attach my application but if i will be able to create a sample project that the problem can be reproduced on it, i will attach it .

In the meanwhile, from your description about this being somewhat known problem, will it be safe enough to set the configuration to no validation as a default?

Guy

Guy Mardiks said:

I cannot (for obvious reasons) attach my application but if i will be able to create a sample project that the problem can be reproduced on it, i will attach it

Actually, a simple, generic test case is often the best. Thanks!

Guy Mardiks said:

In the meanwhile, from your description about this being somewhat known problem, will it be safe enough to set the configuration to no validation as a default?

Yes, the program loader is quite reliable. Almost all the data verification errors I've gotten were either user error or caused by some strange environment issue at no fault to the loader.

Hi,
I have not yet had the time to try and make a small sample project that reproduced the problem but i did notice something:
I am not sure if this indeed says anything or just a coincidence but when i used NO Validation i got lots of time, when trying to start the cores an error that device is at HARD fault and needs to be reset, again i am not sure if this indeed related but i raises concern that perhaps the validation error is not bogus and JTAG did not wrote correctly the image.

How plausible do you think it is ?

Guy

Hi Guy,
Just following up on this thread - were you able to create that small sample project? This will be most helpful with our analysis.

Thanks
ki

Hi,
Sorry, so far i have not succeeded reproducing it on a sample project, but i will keep try (maybe find out what triggers this) ...