DDTZ and ZSID on z80 in interrupts running.

[jayacotton]

I am finding that the Z debuggers are really unstable with interrupts.

Is this a know problem ?

Aside from the obvious, is there any other work around. The idea of re-flashing every time I want to debug a program is a bit un pleasant, but we do what we have to.

[feilipu]

It may not be related, but the debuggers' RST or interrupt will rely on the correct RAM bank being switched in, and there being enough stack available if the interrupt strikes when HBIOS is doing something.

There is a similar requirement with FreeRTOS, so Wayne and I implemented a HBIOS_MUTEX to prevent interrupts whilst the HBIOS Bank is switched in.

You'll need to reassemble RomWBW with the HBIOS_MUTEX enabled for RC2014 Z180 boards, and similar for SC126/SC130/SC131.

When enabled the boot screen it should look something like this.

RomWBW HBIOS v3.0.1, 2020-04-05
HBIOS MUTEX ENABLED

SC131 Z8S180-N @ 36.864MHz IO=0xC0
1 MEM W/S, 1 I/O W/S, INT MODE 2
512KB ROM, 512KB RAM

ASCI0: IO=0xC0 ASCI W/BRG MODE=115200,8,N,1
ASCI1: IO=0xC1 ASCI W/BRG MODE=115200,8,N,1
MD: UNITS=2 ROMDISK=384KB RAMDISK=384KB
SD: MODE=SC OPR=0x0C CNTR=0xCA TRDR=0xCB DEVICES=1
SD0: SDHC NAME=SL16G BLOCKS=0x01DACC00 SIZE=15193MB

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      ASCI0:      RS-232            115200,8,N,1
Char 1      ASCI1:      RS-232            115200,8,N,1
Disk 0      MD1:        RAM Disk          384KB,LBA
Disk 1      MD0:        ROM Disk          384KB,LBA
Disk 2      SD0:        SD Card           15193MB,LBA

SC131 Boot Loader

ROM: (M)onitor (C)P/M (Z)-System (F)orth (B)ASIC (T)-BASIC (P)LAY (U)SER ROM  
Disk: (0)MD1 (1)MD0 (2)SD0 

Boot Selection?

Not totally sure whether this is related, but it perhaps it helps?

[jayacotton]

Guess I should have been more specific about the configuration.

This machine is Z80 with SC102 and SC104, plus a bunch of other h/w and the 512k rom/ram etc.

The SC102 and SC104 are the only boards that are generating interrupts.

Perhaps the mutex will work for this configuration also. I can try it.

[jayacotton]

well this looks promising (running the .com file) now to flash the rom.....

RomWBW HBIOS v3.1.1-pre.165, 2022-04-02 HBIOS MUTEX ENABLED

RC2014 (DUART) Z80 @ 7.372MHz 0 MEM W/S, 1 I/O W/S, INT MODE 2, Z2 MMU 512KB ROM, 512KB RAM

[jayacotton]

No joy. The problem is still there.

I can/should try a test with interrupts configured off (well fewer) to see if that clears it up.

[feilipu]

No joy. The problem is still there.

OK. I don't know how to fix it then. Sorry. I thought it might be banking related, but perhaps not. :man_shrugging:

[wwarthen]

Hi Jay,

They should work OK. I have used them on occasion.

Exactly which debugger? DDTZ? ZSID? Is it one of the ones I provide on the distribution?

Which OS?

I'm really tied up most of the day, but will respond when I can.

Thanks,

Wayne

[jayacotton]

RomWBW HBIOS v3.1.1-pre.165, 2022-04-02 HBIOS MUTEX ENABLED

RC2014 (DUART) Z80 @ 7.372MHz 0 MEM W/S, 1 I/O W/S, INT MODE 2, Z2 MMU 512KB ROM, 512KB RAM ROM VERIFY: 00 00 00 00 PASS

CTC: IO=0x88 TIMER MODE=TIM16 AY: MODE=RCZ80 IO=0xD8 NOT PRESENT SIO0: IO=0x80 SIO MODE=115200,8,N,1 SIO1: IO=0x82 SIO MODE=115200,8,N,1 DSRTC: MODE=STD IO=0xC0 Sat 2022-04-02 08:45:52 CHARGE=OFF MD: UNITS=2 ROMDISK=384KB RAMDISK=256KB FD: MODE=RCWDC IO=0x50 NOT PRESENT IDE: IO=0x10 MODE=RC IDE0: 8-BIT LBA BLOCKS=0x0003D400 SIZE=122MB IDE1: NO MEDIA PPIDE: IO=0x20 PPI NOT PRESENT SD: MODE=MT IO=0x5C DEVICES=1 SD0: SDXC NAME=SL64G BLOCKS=0x076F5000 SIZE=60906MB

Unit Device Type Capacity/Mode

---

Char 0 SIO0: RS-232 115200,8,N,1 Char 1 SIO1: RS-232 115200,8,N,1 Disk 0 MD0: RAM Disk 256KB,LBA Disk 1 MD1: ROM Disk 384KB,LBA Disk 2 IDE0: CompactFlash 122MB,LBA Disk 3 IDE1: Hard Disk -- Disk 4 SD0: SD Card 60906MB,LBA

RC2014 (DUART) Boot Loader

Boot [H=Help]:

C>b:ddtz mathtest.com DDTZ v2.7M by CB Falconer. CPU=Z80 Next PC Save 4A00 0100 73

If I try to run to breakpoint it never hits it. Although I have evidence that it got to the target code. If I try to trace up to the target, the system locks up at requires a hard reset.

[wwarthen]

Thanks Jay. I will try to repro this. Need a little time -- very busy today.

-Wayne

[jayacotton]

Well, I flashed a non timer interrupt imode 1 version and still no joy. Must be a problem with my code.

[wwarthen]

Hi Jay,

I did some cursory testing. Basically, I started DDTZ with a program name specified. Then I used G, to run until a breakpoint is hit. This seemed to work. Next, I used T1000 to interactively trace through 1000 instructions of the program. This also seemed to work fine.

It sounded like you were setting a breakpoint and then trying to trace until the breakpoint is hit. I'm not sure how to do that. Trace just runs for X instructions. I don't see a way to stop on a breakpoint.

Did my testing generally do what you are trying to do?

Also, I do expect that it will not be possible to trace into direct HBIOS calls. The bank switch will swap page zero and the debugger will lose the RST 7 setup. BDOS calls are automatically bypassed by the debugger, so those are not an issue.

Thanks,

Wayne

[jayacotton]

DDT, DDTZ, SID, ZSID all the the same thing on all versions of CP/M. With or without the Timer Int running, and the mutex etc.

The will ignore the break point, or hit the break point and freeze.

I think the bug is in my program, but I do not yet know where. The other symptom is that the code can't printf a long. However my test case for that bug works.

Was hoping to catch a buffer overrun or a stack tangle, but I think I will need a better tool.

[feilipu]

Try z88dk-ticks. It will work with simple CP/M programs, but probably not your interrupt handler. At least code flow and stack balance can be tested using cycle accurate trace that you can capture and review.

The debug trace capture will show you where things were executing when it crashes. Or up to a breakpoint.

[jayacotton]

Here is my latest crash report. It did hit the breakpoint, and the attempt to trace 1 step, crashed.

C>b:ddtz mathtest.com DDTZ v2.7M by CB Falconer. CPU=Z80 Next PC Save 4A00 0100 73 -g,2f0 9511 Math Board Test Program. V0.1A2 (John Monahan 2/4/2022) Please note all values need to be 16 bit HEX numbers. (R) Reset the AM9511 Chip (+) Add two 16 bit numbers. (XXXXH + YYYYH=ZZZZH) (-) Subtract two 16 bit numbers. (XXXXH - YYYYH=ZZZZH) (M) Multiply 16 X 8 bit bit number. (XXXXH X YYH=ZZZZH) (D) Add two 32 bit numbers. (XXXXXXXXH + YYYYYYYYH=ZZZZZZZZH) (X) Multiply 32 X 16 bit bit number. (XXXXXXXXH X YYYYH=ZZZZZZZZH) (C) Convert 32 bit number to floating format (E) Convert floating format to 32 bit number (S) Get the square root of a floating point number (ESC) Quit Please enter command > +*02F0 C0Z1M0E0I0 A=00 B=3C49 D=D76C H=3A3C>2E35 S=D762>D370 P=02F0 POP B

-t C0Z1M0E0I0 A=00 B=3C49 D=D76C H=3A3C>2E35 S=D762>D370 P=02F0 POP Bdec2flt ÁáåÅå!Z9å!·>å>Íë*ÁÁÁ!]9å! 0.000000 00000000 HL 0000 DE 0000 BC 3c53 00000000 dec2flt æ
É> ÅÕåOÍ 0.000000 00000000 HL 0000 DE 0000 BC 3c53 00000000 dec2flt %08lx 0.000000 00000000 HL 0000 DE 0000 BC 3c53 00000000 ŒDE 0000 BC 3c53

0008 #F*· 0001ÿ

[jayacotton]

This is interesting. The crash is associated with the printf. (or console output). I should try the test with all printf's disabled....

[jayacotton]

z88dk-ticks does not report a problem with stack balance.

Also, disabling the printf's in the code did not make a difference.

Latest crash Please enter command > +02F0 C0Z1M0E0I0 A=00 B=3BF1 D=D76C H=39E4>2E35 S=D762>D370 P=02F0 -t C0Z1M0E0I0 A=00 B=3BF1 D=D76C H=39E4>2E35 S=D762>D370 P=02F0 POP B02F1 C0Z0M0E0I0 A=BF B=0248 D=006C H=39E5>302E S=D768>D73E P=02F1 POP H -t C0Z0M0E0I0 A=BF B=0248 D=006C H=39E5>302E S=D768>09F2 P=02F1 POP H C><<<<<<<<<<<<<<here was a spontaneous reset....

[jayacotton]

z88dk-ticks works great! found one bug already.

[wwarthen]

Well, I am not sure what to do with this one. I have not been able to create a failure scenario on my system.

@jayacotton, it sounds like you have found a way to do your debugging.

Do you think there is a RomWBW issue here?

Thanks,

Wayne

[jayacotton]

I think we should close this. Don't think is specific to RomWBW but might be of interest to create a debugging wiki somewhere.