DSU ACTIVE signal asserted after 22 clock cycles of assertion of DSUBREAK signal

1

Hello everyone, I have the Leon3 processor together with the debug support unit DSU3. As mentioned on pages 223 and 224 of the user manual (https://gaisler.com/products/grlib/grip.pdf) the core goes into the debug mode when the DSUBREAK(DSUBRE) signal is asserted. And when the DSUBRE signal is asserted, the DSU ACTIVE (DSUACT) signal should also be asserted.
However DSUACT signal becomes 1 after an inconsistent amount of cycles as you can see in the picture below. Is there a way to make it more consistent or is there another way to know that the core really stopped (maybe an internal signal)

Any small advice is appreicated :smiley:

dsubre_and_dsuact
dsubre_and_dsuact1540×570 93 KB

2

dsubre_and_dsuact2
dsubre_and_dsuact21594×621 125 KB

3

Hi!

I think you will have some varying delay depending on what the processor is doing at the time, if the processor pipeline is being held by the cache controller because the LEON3 is in the middle of an AHB access (cache miss / store etc) it can not break until the hold condition has ceased could take some extra time. So I think it is this way by design. The DSUACT should be an indication that the processor actually stopped.

Why is this a problem?