11-19-2014 03:46 PM
I have a Zynq board that is currently running and whose code was loaded from an SD card. Is it possible to use XDM or XSDB to non-intrusively monitor that the two ARM CPU cores while executing code? I want to read a few memory locations or variables to ensure that they are indeed changing that that everything is working as expected.
I am sure a lot of people would just restart the system in SDK using debug but that would ruin some of the already collected data. Of the two CPU cores, one is obviously working but the other is harder to know if it is doing anything. However, being able to non-intrusively read a memory location would quickly provide the answer that the system is operating as expected.
If anyone can provide a few steps to properly connect to the system using XDM or XSDB and check the memory it would be much appreciated. Bonus if you can help me find the exact memory location of a specific variable used in the C code but my guess is that is more trouble than it is worth becuase the variable will be in the stack.
11-19-2014 05:55 PM
Instead of xmd/xsdb, take a look at the axi jtag master core.
Regarding a variable, you could make it global, volitile and static. Then use objDump on the .elf to view its location.
Or, use compiler attributes, on the variable to assign it to a specific memory region that is then assigned in the linker script.
If using the axi jtag master, it would be easiest to connect it to the ACP so that cache doesn't get in the way.
06-10-2015 12:38 PM
Do you have experience utilizing the ACP with the JTAG to AXI IP. I'm looking to do something similar. This is from a post on another forum
In reading UG585, and UG873 I have some questions relating to the ACP. We would like to use the PL to perform reads of the OCM and block ram attached to the M_AXI_GP ports, in an on-demand or automated fashion using an external debugger that is ran in the PL, in an effort to capture changes in OCM or block ram at certain times. I think we should be ok with non-coherent reads, but we want to make sure that the data when we perform a non-coherent read isn't stale. I would prefer coherent reads, as I believe we desire that latency, and we will not be posing any risk of OCM switch starvation, or cache thrashing due to the low read request count.
Secondly, I was looking to exploit the event bus, possibly just using one of the signals so that the CPU can inform the PL that data has changed in the OCM or block ram.
With the intent explained above, is the approach for using the ACP ideal, or should we investigate other debugging methods? i.e. using the debug access port, FTM, etc?
06-16-2015 12:15 PM
Yes, the jtag to axi IP can be used via the ACP port. And, as long as the PS option PS-PL_Configuration->ACP_Slave_AXI_Interface->Tie_off_AxUSER option is enabled, all ACP accesses will be coherent. If you do not enable this option, then you would have to drive the axi USER and CACHE signals appropriatly to enable coherency.
Personally, I would not use the event bus. First off, it is a toggle interface, and secondly, you would have to use wfe and/or wfi (wait for event/interrupt) to send/receive activity on the event bus.
I presume, with your description, that the address range for the mGP BRAM has been configured as cacheable. Otherwise, there is no issue with respect to coherency because the mGP address range, by default, is configured as a shared device instead of outer cacheable memory.
06-16-2015 01:19 PM
BTW: XSDB does give you access to read/write devices while the processor/s are running.
In XSDB, enter 'connect' followed by targets. Change the target to APU using 'targets 1'. Now you can do reads/writes to peripherals such as your BRAM using 'mrd 0x40000000'. But, mrd does not use the cache coherency logic so if you have BRAM address space configured as cacheable and not write-through then you will read stale data.