OpenCores
no use no use 1/1 no use no use
problem while debugging orpsoc
by sedora on Jun 25, 2013
sedora
Posts: 2
Joined: Dec 20, 2012
Last seen: Jul 11, 2013
hello,
I'm trying to debug orpsoc on a virtex-6 FPGA board.I used the ml501 branch and made a few modifications. Now I can use GDB and or_debug_proxy to debug the physical target, but there's a problem.
After I loaded a program to the ram using GDB , I checked the contents in the ram to see if I have successfully loaded the program, but I found that sometimes a few instructions is lost in the memory. I checked the or_debug_proxy, it has a CRC verify mechanism. However, the debug proxy didn't report an error about the instruction lost. The instrution lost seems to be occurred random, and sometimes the contents in ram is fully correct.
Now I'm very confused about this problem, does anyone have some ideas ?

Thanks.
RE: problem while debugging orpsoc
by julius on Jun 25, 2013
julius
Posts: 363
Joined: Jul 1, 2008
Last seen: May 17, 2021
Hi

The CRC mechanism is on the link between the PC and the debug interface block in the FPGA design. That will ensure the data got into the FPGA OK, not that it got into the RAM OK. The proxy doesn't separately verify writes to RAM. I'm not sure of an easy way to do that (GDB has a mechanism but I don't think our proxy supports it). You can do a binary dump back to your PC of what you just downloaded using the "dump binary" command like:

(gdb) dump binary memory /tmp/dump.bin 0x0 0x100000

Use Google to learn more about that command if you need.

Corrupted data downloaded to the RAM could be several things. Quite likely it's an issue inside the design, such as timing problems on the memory controller's interface to the memory (I presume you're using a DDR2 controller or something.) Or it could be plain old timing problems inside the FPGA design itself (maybe in the memory controller, but potentially on the bus between the debug unit and the memory controller).

Or the design could be fine timing-wise but broken functionally - so is anything else a master on the bus which could write junk into RAM when it's not supposed to? Is it bad software? You could check by doing an image verify after downloading (by using the binary dump) and after running.

It's a difficult problem to debug, but welcome to the world of FPGA development ;)
no use no use 1/1 no use no use
© copyright 1999-2025 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.