Graph Tools Limitation?

Hello

For the last screenshot,what happens if you manually refresh the graph?

Thanks

ki

We got the same result on a manual refresh… same data, same plotting error.

Can you export the contents of memory for all of readBuf starting at 0x20000208) to a file? A *.dat file would be the easiest. You can do this from the Memory Browser view:

https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_debug-main.html#load-and-save-memory

zip the file and attach it to this thread.

Thanks

ki

plz see files attached

audio_samples_CC_graph_issue.zip

Thank you for the data file.

I plotted the same graph and I do not see an issue.

See my screen below:

Note that DSP Data Type is 16-bit (2 bytes). The Index Increment is also set to 2, meaning that only every other 16-bit value is used (meaning 2 bytes skipped). Hence there is one sample per 32-bit. Hence if 0x20000208 is the start address, 0x20000608 would represent the 256th sample. It is at this address that the value goes from 2232 to -4208. This seems to align with what the graph is displaying.

We do see the same as you -- the graph tool correctly reflects the data in the I2S buffer. 

Discontinuities in the data appeared to be caused by a breakpoint. We resolved this by removing a breakpoint. We're no longer getting data-glitches. 

But, now we only see correct data (and correct graph) on pausing execution the first time. 

We're finding that we're getting glitches in the buffer and graph if we continue execution, and then pause a second time. 

Any ideas?

johny radio said:

We're finding that we're getting glitches in the buffer and graph

Unlike the original reported issue, the actual memory buffer contains the wrong data in this case?