Open dennowiggle opened 2 months ago
Hi,From the looks of it, it could be timing or speed issue? I don’t have F91 but a F92 so can’t test that out. I used to hook up my cheap logic analyzer to pulseview and made a filter for it to see the commands, etc. Then I checked both the original Zilog cable and mine to spot differences. It’s quite a bit of work but it worked in the end.I am busy with a new Agon with a F91. Still have to create the boards and solder them but will probably run into the same problem you described. Then I can debug it better. From a distance it’s difficult to guess what’s wrong. Sorry.Sent from my iPadOn 23 Aug 2024, at 20:06, dennowiggle @.***> wrote: I'm trying to use the AgonElectronHAL on an ESP32 [board = nodemcu-32s] with a new eZ80F91 board I'm bringing up and I am having issues reading multiple bytes of data over ZDI. I see you have quite a few commits for ZDI stability and one issue on the use of out0 vs out. I was wondering if you could provide some pointers on what next steps to take for debugging this issue based on your experience?
ZDSII debug tool works - can read write FLASH and memory to the eZ80F91 board okay. Custom bootloader loaded via ZDS can read and write memory and print the contents over UART, and download registers, so board seems good. I am running at 18.18MHz to mimic EZ80F92 speeds and timing. Faster speeds behave the same too. I can read product id = 8 and revision = 2 which is correct. Reading internal flash memory using ZDI & Electron at 0x0 reads the same data continuously 10000000C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0F0 Reading the registers reads garbage as well - 02C0 in this case.
F=02 N..VA. STAT=.HAMI PC=0002C0 MB=00 IFF=0 I=C0 R=C0 SPS=02C0 (registers)```
Any ideas on how to proceed with debugging ZDI communication would be greatly appreciated?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
Thanks for the feedback. Would it be possible to share your ZDI protocol decoder for PulseView and I can start with my little analyzer.
That's exciting that you are working on an F91 Agon. I couldn't find many designs using the F91 that share info so will be great to have another one. Exciting.
I found a typo below. The second call to zdi_write_registers should contain ZDI_ISL1 for a two byte command.
void zdi_cpu_instruction_out (uint8_t regnr, uint8_t value)
{
// ld a, nn
uint8_t instructions[2];
instructions[0]=value;
instructions[1]=0x3e;
zdi_write_registers (ZDI_IS1,2,instructions);
// out0 (nn),a
instructions[0]=regnr;
instructions[1]=0xd3;
zdi_write_registers (ZDI_IS2,2,instructions);
}
Looking further I realised that out(n),a will not work as the contents of A are placed on the address bits 15->8. Those bits need to be 0. This is an excerpt from the eZ80 CPU user manual for out(n),a, page 269.
The n operand is placed on the lower byte of the address bus, ADDR[7:0]. The CPU
places the contents of the accumulator, A, onto the middle byte of the address bus,
ADDR[15:8]. The upper byte of the address bus, ADDR[23:16] is undefined for I/O
addresses. The CPU next outputs the contents of the accumulator to this I/O address.
An alternate way to out0(regnr), value
is to use out(c),a
as the contents of b=0 are placed on bits A15->A8.
ld a, value
ld bc, regnr,
out (c), a
I now have ESP32/nodemcu and ESP32-S3 working with ZDI to F91.
There were a few issues, mostly on my side. Documenting here in case you want to implement improvements (items 2&3).
My boot code switching between ADL and Z80 mode was wrong which caused the CPU to encounter illegal commands and perhaps enter a strange state,. I added a zdi reset command followed by a break command which helped that issue but I encountered another problem introduced by this change.
ZDI was hanging after reset. I added a 100us delay after issuing a reset command and then polled ZDI_MASTER_CTL on zdi until bit 7 was cleared, waiting 100us between each poll. Accessing ZDI straight after the reset was unstable and caused ZDI to lock up. So far so good. I think this may have been the cause of my original ZDI problem.
I needed to switch back to using the out0(n),a
instruction as the out(n),a
did not work for a > 0, and thus the internal CPU registers were not configured correctly. I erased the internal Flash memory several times with the ZDSII tool (per other closed issue) and each time I could access the CPU over ZDI from ESP32 fine, internal registers seemed configured okay, and I was able to flash a new image using ZDI.
You can close this issue.
I'm trying to use the AgonElectronHAL on an ESP32 [board = nodemcu-32s] with a new eZ80F91 board I'm bringing up and I am having issues reading multiple bytes of data over ZDI.
I see you have quite a few commits for ZDI stability and one issue on the use of out0 vs out. I was wondering if you could provide some pointers on what next steps to take for debugging this issue based on your experience?
10000000C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0F0
Any ideas on how to proceed with debugging ZDI communication would be greatly appreciated?