CCS/TMS320F28379D: "IcePick_C_0: Trouble Reading Memory Block at 0x0 on Page 0 of Length 0x320" problem

Did you make any changes to the ccxml or were the changes only within the application itself? When does the error occur? It is as soon as you load the application or does it only happen at a certain point in the code?

Are there any other issues? Code hanging? Jumping into the weeds?

Whitney

Thanks for reply.

Did you make any changes to the ccxml or were the changes only within the application itself?
No, I didn't make any changes to the ccxml.

When does the error occur? It is as soon as you load the application or does it only happen at a certain point in the code?
It occurs when I run in debug mode.

Are there any other issues? Code hanging? Jumping into the weeds?
So far I haven't found other issues yet.

I don't know what conditions would trigger the error. What does the message mean?

Thanks for the additional information. Is that the full error message you're seeing in the console? Is these more to it containing an error code? Here's a good resource for troubleshooting connectivity issues:

Whitney

There is the print screen above. I can run the program in debug mode.

There are no descriptions of the error message in the link. And it doesn't answer my question.

What does the message mean? How to fix it?

As it says, the debugger is having trouble accessing that region of memory. Do you have a variable in the Expressions or Graph windows that correspond to that region? Do you get the same error if you start a new workspace and copy the project over? Sometimes this error is accompanied by a longer error message that gives a hint to the possible reason but apparently not in this case.

What kinds of edits did you make?

Whitney

Thanks for the suggestion.

It seems that the message comes out with the Graph windows. If I close the Graph windows, there are no error messages in the console.

But I didn't make changes to the configure of the Graph.

I Import the configure from the example "fcl_f2837x_tmdxiddk_graph1.graphProp" and "fcl_f2837x_tmdxiddk_graph2.graphProp".

What are the reasons and the background that led to such a condition?

Thanks for your patience. I'm still not sure what's causing this. I've talked to the authors of the original project and they haven't run into this issue before.

Can you send me your .map file? Were the graphProp files were working before you tried editing the project? What edits did you make? Changes to the C code? Changes to the cmd file?

Whitney

The attachment are the .map file and cmd files.

I didn't see the error before I tried editing the project.

Both C code and cmd file have been changed.

iddk_f28379d.7z

(sorry, I hit the answered button by accident)

I found my F28379D and loaded the project, including the graph properties file. 

When the error happens, are you able to open a memory browser and point to the address configured in the graph? This should display some data that is also reflected in the graph view. (the screenshot below shows this process - the data is not real as I don't have the exact development kit)

One difference between the error message in your screenshot and the original project is the variable being graphed is not located at 0x0 but at other addresses (the one below is at 0xB320, which corresponds to the file fcl_f2837x_tmdxiddk_graph2.graphProp). Perhaps you are trying to plot data from another variable?

Also, if you modified the graph properties to point to a variable and not a pointer or array, you need to pass its address (&) instead of the variable name alone. 

That should allow you to further debug this. 

Hope this helps,

Rafael

Did you find something abnormal in .map file and cmd files?

It seems that the memory browser is fine. But the error message are same as before.

The graph properties are arrays, I think this is not the cause of the error.

Hi,

Please apologize for the delay and thanks for sending the photograph. I just noticed you were using CCSv9.2 and the Dual Graph. 

Can you try to set the Start Address as &DBUFF_4CH1 and &DBUFF_4CH2 instead? Or set to the actual addresses 0x1A362 as shown above for DBufF_4CH1). I wonder if the graph tool is somehow using the value of 0x00000000 of these arrays. 

One additional detail: I just noticed you are using the Dual Graph. Could you try to use the Single Graph instead? This way you can better isolate the root cause of the problem.

I vaguely recall that a few problems with the Dual Graph were still outstanding, but I couldn't locate the relevant discussions. I will update this thread in case I find anything relevant. 

Regards,

Rafael

Hi,

I tried to set the Start Address as &DBUFF_4CH1 and &DBUFF_4CH2 (or 0x1A362 and 0x1A4F2), but there was no difference in the result.

Then I used Single Time Graph, the error changed. How come? The PrtSc are as below.

Hi,

Thanks for sending the screenshots. This may well be a problem on the graph view itself, although I can't reproduce it here in various versions of CCS I tested. 

The direct address should have solved the problem with the variable definition, but did you try passing the address with the single graph as well? Alternatively, are you able to plot the same variable on an unmodified example code? Maybe the change of memory regions could present issues that I am not aware. 

At this point I would start to suspect that either a temporary file may be getting in the way of a proper display or this specific feature was somehow corrupted. 

You can try to clear the temporary files and/or configurations by checking section 9.7 of the CCS User's Guide at:

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

If the feature itself is corrupted, a reinstall is required. Alternatively, you can try to install CCS in another directory (they can coexist) and use a different workspace. This way you don't disrupt your existing development environment. 

Regarding the error messages, the value of 0x320 is equal to 200 samples (Acquisition Buffer Size) of 4 bytes each (Dsp Data Type), while the 0xc8 corresponds to 200 samples of 1 byte. That seems to be a problem located in the tool itself. 

At any rate, I am not entirely sure what else to try in this scenario. My tests covered a range of versions and therefore I can't see anything intrinsic to the tool. I will report back in case I find anything relevant. 

Hope this helps,

Rafael