SD card with PIO protocol error

[grafzahl12345]

Hello, i try to use SD card with the 4PIO card on the SBC V2-005i (4,8 & 10 Mhz) , but i all ways get an command error at boot up.

My config at sd.asm

SD_DEVMAX .EQU 1 ; NUMBER OF PHYSICAL UNITS (SOCKETS) SD_IOBASE .EQU $A1 ; IO BASE ADDRESS FOR SD INTERFACE SD_OPRREG .EQU SD_IOBASE ; OUTPUT PORT (OUTPUT: CS, CLK, DIN) SD_OPRDEF .EQU %11111111 ; OUTPUT PORT DEFAULT STATE SD_INPREG .EQU SD_IOBASE ; INPUT REGISTER SD_CS0 .EQU %00001000 ; SELECT SD_CLK .EQU %00010000 ; CLOCK SD_DI .EQU %00000001 ; DATA IN (CARD <- CPU) MOSI SD_DO .EQU %10000000 ; DATA OUT (CARD -> CPU) MISO SD_CINIT .EQU TRUE ; INITIALIZE OUTPUT PORT SD_DDR .EQU $A3 ; DATA DIRECTION REGISTER SD_DDRVAL .EQU %11100110 ; DATA DIRECTION REGISTER VALUE SD_INVCS .EQU TRUE ; INVERT CS

pin layout

shield signal PIO-Port D10 CS PB3 D11 MOSI PB0 D13 SCK PB4 D12 MISO PB7

boot log

RetroBrew SBC [SBC_10] Z80 @ 8.004MHz 0 MEM W/S, 1 I/O W/S, INT MODE 2, SBC MMU 1024KB ROM, 512KB RAM ROM VERIFY: 00 00 00 00 PASS

SN76489: LEFT IO=0xC6, RIGHT IO=0xC7 YM: IO=0xC0 UART0: IO=0x68 16550A MODE=38400,8,N,1 FIFO DSRTC: MODE=STD IO=0x70 Sat 2000-01-01 00:09:53 CHARGE=ON I2C: IO=0xE0 DS1307: 01/01/21 00:00:00 VDU: IO=0xF0 MODE=80X25 NOT PRESENT MD: UNITS=2 ROMDISK=896KB RAMDISK=256KB PPIDE: IO=0x60 PPIDE0: ATA LBA BLOCKS=0x07740000 SIZE=61056MB PPIDE1: NO MEDIA SD: MODE=PIO IO=0xA1 DEVICES=1 SD0: COMMAND ERROR

Unit Device Type Capacity/Mode

---

Char 0 UART0: RS-232 38400,8,N,1 Disk 0 MD0: RAM Disk 256KB,LBA Disk 1 MD1: ROM Disk 896KB,LBA Disk 2 PPIDE0: CompactFlash 61056MB,LBA Disk 3 PPIDE1: Hard Disk -- Disk 4 SD0: SD Card -- Sound 0 SND0: SN76489 3+1 CHANNELS Sound 1 SND1: YM2612 6+0 CHANNELS

RetroBrew SBC [SBC_10] Boot Loader

I use the B port of the first z84c2010 at ioport $A1 and a cheep microsd card adapter HW-125. It use the same level shifting as the Gluino card shield. As a second try i used sd card from spi display with no pullups and a TXS0108 module for level shifting with the same results. After some logging the spi protocol with pulseview i didn't got any clue because my lack of knowledge. Maybe someone got a clue out of my data and a fix for the source code.

thx sebastian

https://sigrok.org/wiki/PulseView

spi_command_error.zip

[wwarthen]

Hi @grafzahl12345,

I appreciate the thorough description of the problem.

I don't see anything wrong in the information you have provided (other than the "COMMAND ERROR" or course). I assume you have modified the sd.asm code because there is currently no support for an SIO. I was not able to get anything meaningful from the PulseView data.

There are a couple things that might help me tell what is wrong:

1. Enable tracing in the SD Card driver by setting SDTRACE to 3 in your config file.
2. Provide a copy of the modified source code.

In this case "COMMAND ERROR" indicates that the result code sent from the SD Card indicates an error. The trace output will show what the error is.

Thanks,

Wayne

[grafzahl12345]

Hello Wayne,

sorry i have forgotten to mention i use the development tree von RomWBW and there is PIO included. I never used SIO as you mentioned. The code is in directory \RomWBW\Source\HBIOS\ sd.asm line 285

Here is the output of SDTRACE=3

SD: MODE=PIO IO=0xA1 DEVICES=1 SD0: CMD 40 00 00 00 00 95 --> RC=01 SD0: CMD 48 00 00 01 AA 87 --> RC=7F SD0: COMMAND ERROR [48000001AA877F00] SD0: CMD 77 00 00 00 00 FF --> RC=05 SD0: COMMAND ERROR [7700000000FF0500] SD0: CMD 41 00 00 00 00 FF --> RC=7F SD0: COMMAND ERROR [4100000000FF7F00]

and the updates pulseview spi log. SD_command_error.zip

thx sebastian

[wwarthen]

Hi @grafzahl12345,

Actually, I need to apologize. I forgot that @etchedpixels had added an SD driver mode called PIO. I'm sure it worked for him, but I have not personally put together the hardware to try it (although it is on the todo list). When I said SIO, it was a typo. I meant PIO.

Looking at your trace output, the first command (40), seems to go OK. This is the command to put the card in idle state and should return 0x01, which it does. Good. However, everything after that looks way off. The next command (48) looks like the card is not even selected and MISO is just sitting at a high value. The next command (77) returns a resulting indicating illegal command which probably means the prior command (48) was not successful.

I am going to review the PulseView snapshot and see if that reveals anything. I am also going to look at the 4PIO vs. the Gluino w/ Arduino shield (which is what Alan coded for). I have a feeling that the Zilog PIO (from the 4PIO) is not being properly initialized because that would require a different initialization than the Gluino+Arduino shield.

Thanks,

Wayne

[wwarthen]

So, after looking at @etchedpixels Gluino, it does use a Zilog PIO and so the initialization should be OK. You are using an SD Card adapter instead of an Arduino shield, but I don't see why that would be a problem as long as the signals are mapped correctly. I was unable to successfully open the Gluino schematic, so I am having trouble figuring out the specific pins it is using.

I still need to look at the PulseView dump.

-Wayne

[wwarthen]

Well, I am able to make more sense out of this PulseView dump than the prior one. The initial GO_IDLE command looks OK (which is verified by the trace). However, the next command (48) has an extraneous byte (value 0x00) prior to the command byte. This is wrong and causes the SD Card to interpret the command as 00 instead of 48. All command after the initial GO_IDLE have the extraneous null byte in front which is causing the commands to be misunderstood by the SD Card.

So, the problem to be solved is why an extraneous null byte is appearing before all command bytes. I'll take a look at the code.

Thanks,

Wayne

[wwarthen]

I think I see what is causing this. I am attaching a slightly updated version of the sd.asm file to this message. Can you try building with this file and let me know what happens. I don't want to check this in without some confirmation it is working.

Thanks,

Wayne

sd.zip

[EtchedPixels]

There's nothing particularly magical about the PIO SD driver, it's just a direct connect to the 5v adapters on the arduino. The gluino is just a formfactor adapter really.

[grafzahl12345]

Hallo Wayne,

thanks for your work . Installing the changed code works. It reads and boots now form SD Card over my PIO4 card.

SD: MODE=PIO IO=0xA1 DEVICES=1 SD0: CMD 40 00 00 00 00 95 --> RC=01 SD0: CMD 48 00 00 01 AA 87 --> RC=01 SD0: CMD 77 00 00 00 00 FF --> RC=01 SD0: CMD 69 40 00 00 00 FF --> RC=01 SD0: CMD 77 00 00 00 00 FF --> RC=01 SD0: CMD 69 40 00 00 00 FF --> RC=01 SD0: CMD 77 00 00 00 00 FF --> RC=01 SD0: CMD 69 40 00 00 00 FF --> RC=00 SD0: CMD 7A 00 00 00 00 FF --> RC=00 SD0: SD CARD TYPE ID=02 SD0: CMD 50 00 00 02 00 FF --> RC=00 SD0: CMD 49 00 00 00 00 FF --> RC=00 TOK=FE SD0: CSD = 00 26 00 32 5F 59 83 C8 BE FB CF FF 92 40 40 D7 SD0: SDSC SD0: CMD 4A 00 00 00 00 FF --> RC=00 TOK=FE SD0: CID = 03 53 44 53 44 30 31 47 80 90 1B C3 99 00 6C DB NAME=SD01G BLOCKS=0x001E4600 SIZE=968MB

Unit Device Type Capacity/Mode

---

Char 0 UART0: RS-232 38400,8,N,1 Disk 0 MD0: RAM Disk 256KB,LBA Disk 1 MD1: ROM Disk 896KB,LBA Disk 2 PPIDE0: CompactFlash 61056MB,LBA Disk 3 PPIDE1: Hard Disk -- Disk 4 SD0: RAM Floppy 968MB,LBA Sound 0 SND0: SN76489 3+1 CHANNELS Sound 1 SND1: YM2612 6+0 CHANNELS

[wwarthen]

Very glad to hear this. I will close this issue when I check-in the fixed file.

Thanks,

Wayne

[EtchedPixels]

So what was the actual problem for reference ?

[wwarthen]

So what was the actual problem for reference ?

The driver maintains a shadow register (OPRVAL) for the operations register (OPRREG). It was not initialized with the default value during driver initialization which resulted in some very subtle anomalies. Primarily, MOSI was not being kept high during MISO operations. I suspect the effect of this would vary depending on the SD Card.

If you get a chance, I would appreciate it if you could confirm my changes do not break your Gluino + Shield configuration. My changes are not checked in yet. I will post to this thread again once they are.

Thanks,

Wayne

[wwarthen]

The fix is now checked in with commit faaba69.

Closing this issue.