PCXT Core Access to Secondary SD Card

[kitune-san]

I believe that native mode (same implementation as MiSTer) can be used with ZXUno without the need to implement SPI.

I will look for ZXUno to see if I can buy it (and deliver it to Japan).

Here would be the commit of changes related to the KFMMC implementation, so you can look only at the changes, and nothing else, to focus on them. It synthesizes, but the unit is not recognized by XTIDE, it remains to debug in depth... but maybe you can provide me some clue:

https://github.com/spark2k06/PCXT_ZXUno ... 758fa4f151

The technical features of this improved but compatible ZXUno clone:

https://gitlab.com/emax73g/unoxt-hardwa ... ain/scheme

Originally, the signals in the UCF file are defined as follows:

Code: Select all

NET 'sd_cs0_n_o' LOC='E16' |IOSTANDARD = LVTTL;
NET 'sd_sclk_o' LOC='F16' |IOSTANDARD = LVTTL;
NET 'sd_mosi_o' LOC='F15' |IOSTANDARD = LVTTL;
NET 'sd_miso_i' LOC='G14' |IOSTANDARD = LVTTL |PULLUP;

I have also tried assigning PULLUP to the sd_mosi_o signal, but with the same result.

My suggestion.
Could you please try this change when you have time?

https://github.com/kitune-san/PCXT_ZXUn ... suggestion

[spark2k06]

My suggestion.
Could you please try this change when you have time?

https://github.com/kitune-san/PCXT_ZXUn ... suggestion

I've tried it, but it still doesn't detect anything... to rule out, could you tell me what I can change in KFMMC_IDE to force its identification by XTIDE, even if then the SD usage doesn't work... I want to make sure that I haven't made any mistake in the I/O port mapping and similar issues.

https://github.com/spark2k06/PCXT_ZXUno ... 0dd5ebcb65

[kitune-san]

My suggestion.
Could you please try this change when you have time?

https://github.com/kitune-san/PCXT_ZXUn ... suggestion

I've tried it, but it still doesn't detect anything... to rule out, could you tell me what I can change in KFMMC_IDE to force its identification by XTIDE, even if then the SD usage doesn't work... I want to make sure that I haven't made any mistake in the I/O port mapping and similar issues.

https://github.com/spark2k06/PCXT_ZXUno ... 0dd5ebcb65

If you change here, the IDENTIFY ID should be returned.

[spark2k06]

My suggestion.
Could you please try this change when you have time?

https://github.com/kitune-san/PCXT_ZXUn ... suggestion

I've tried it, but it still doesn't detect anything... to rule out, could you tell me what I can change in KFMMC_IDE to force its identification by XTIDE, even if then the SD usage doesn't work... I want to make sure that I haven't made any mistake in the I/O port mapping and similar issues.

https://github.com/spark2k06/PCXT_ZXUno ... 0dd5ebcb65

If you change here, the IDENTIFY ID should be returned.

Identification occurs with this test change... Is it something from the sd_sck clock? maybe?

KFMMC_ID.png (407.31 KiB) Viewed 6984 times

[spark2k06]

Don't worry, the next step will be to use oscilloscope (real) on the SD pins... and we'll see what happens and if we can interpret it, I'll share the results when I can get on it.

[kitune-san]

After reverting the changes, could you make the following changes to slow down the clock?

2023-02-28 234942.png (21.59 KiB) Viewed 6969 times

[spark2k06]

After reverting the changes, could you make the following changes to slow down the clock?
2023-02-28 234942.png

Nothing. Raised both values from 100 to 200, and still no detection...

[kitune-san]

Just to be sure, the top-level module is unoxt_top, correct?

[kitune-san]

Wrong, system_2MB
I am a little confused.

[spark2k06]

Right now, for these tests this is the case. The latest changes (before going up from 100 to 200), are here:

https://github.com/spark2k06/PCXT_ZXUno ... am_32Kb_sd

[spark2k06]

Wrong, system_2MB
I am a little confused.

That module is shared between all ZXUno models of 2Mb or + in the repository, but yes, for these tests the top is unoxt_top.v

[kitune-san]

2023-03-01 002834.png (33.33 KiB) Viewed 6895 times

Oops! commented out...

[spark2k06]

2023-03-01 002834.png

Oops! commented out...

UCF file of UnoXT model is this:

https://github.com/spark2k06/PCXT_ZXUno ... t_pins.ucf

[kitune-san]

It seems difficult to analyze further.

One last thing, since the following signal is in reg.
Could you try changing it to wire or back to 1'b1?

Thank you.

2023-03-01 004353.png (16.3 KiB) Viewed 6865 times

[spark2k06]

It seems difficult to analyze further.

One last thing, since the following signal is in reg.
Could you try changing it to wire or back to 1'b1?

Thank you.

2023-03-01 004353.png

Yes, I'll try that soon and some oscilloscope testing if it still doesn't work. I will let you know.

[spark2k06]

It seems difficult to analyze further.

One last thing, since the following signal is in reg.
Could you try changing it to wire or back to 1'b1?

Thank you.

2023-03-01 004353.png

I have changed the value of SD_sn_CS to 1, instead of Z:

https://github.com/spark2k06/PCXT_ZXUno ... 7a00385327

SD_SCLK operation, correct:

sd_sclk.png (21.96 KiB) Viewed 6673 times

However, I see no activity on the SD_MISO (yellow) signal, only on SD_MOSI (blue) every 1.5 sec or so:

sd_mosi_activity.png (24.37 KiB) Viewed 6673 times

I have set a trigger on both and it only activates with SD_MOSI, in the periodic way I have comment.

It is as if CMD signals are generated periodically, but the SD does not know about it and does not generate DATA signals.

By the way, unlike this graph

I see the SD_SCLK signal running continuously.

[kitune-san]

Could you please check the waveforms (SD_SCLK, SD_MOSI) immediately after resetting the core?

If the waveform is as follow, the SD card is not recognized.

20230301-0002.png (67.23 KiB) Viewed 6596 times

The following is a normal case.

20230301-0001.png (133.31 KiB) Viewed 6596 times

If anything other than the above is the case, some command has failed.

[kitune-san]

Please check that CMD changes at the same time as the falling edge of CLK.
In the figure below, the waveform looks sluggish, but this is because a passive probe is connected. Ignore it for now.

2023-03-01 214837.png (143.66 KiB) Viewed 6577 times

[spark2k06]

Could you please check the waveforms (SD_SCLK, SD_MOSI) immediately after resetting the core?

SD_MOSI (CMD) has intermittent accesses from the very beginning of the core, however SD_MISO (DATA) has none, here you can see a downstream trigger on SD_MISO (yellow wave)... set just before starting the core:

Hantek_01.jpg (109.88 KiB) Viewed 6518 times

The trigger (single mode) is never activated:

Hantek_02.jpg (102.75 KiB) Viewed 6518 times

Also, there you can see what kind of probes and oscilloscope I have, I don't have anything else to measure.

Please check that CMD changes at the same time as the falling edge of CLK.
In the figure below, the waveform looks sluggish, but this is because a passive probe is connected. Ignore it for now.

2023-03-01 214837.png

This is something I need to analyze carefully... I'll let you know.

The probes are connected to test pins on the board, and are replicated in the project, including their PULLUPs:

Code: Select all

	
assign test[0] = sd_sclk;
assign test[1] = sd_miso;
assign test[2] = sd_cs0_n;
assign test[3] = sd_mosi;

Code: Select all

NET "test<0>"           LOC="G12"   |IOSTANDARD = LVTTL;
NET "test<1>"           LOC="H11"   |IOSTANDARD = LVTTL |PULLUP;
NET "test<2>"           LOC="H13"   |IOSTANDARD = LVTTL |PULLUP;
NET "test<3>"           LOC="H14"   |IOSTANDARD = LVTTL |PULLUP;
NET "test<4>"           LOC="J11"   |IOSTANDARD = LVTTL;
NET "test<5>"           LOC="J12"   |IOSTANDARD = LVTTL;
NET "test<6>"           LOC="J13"   |IOSTANDARD = LVTTL;
NET "test<7>"           LOC="K14"   |IOSTANDARD = LVTTL;
NET "test<8>"           LOC="K12"   |IOSTANDARD = LVTTL;

[kitune-san]

The work to recognize the SD card is done only on the cmd line; the dat line will remain high until then.

[kitune-san]

Does the GND1 pin on the unoxt card slot 6 pin drop to GND?
I don't know why, but apparently it is connected to the fpga port(N11).

[kitune-san]

If this pin is floating, power may not be supplied to the card.

[spark2k06]

If this pin is floating, power may not be supplied to the card.

This card works well in other cores, in SPI mode, that's a fact. I'll check the clock and CMD later.

However, if it is connected to the FPGA, it will be as simple as setting it to 0, I will also try it... I have not looked at the code of other cores.

[spark2k06]

According to the schematics, GND1 (pin 6 of SDCARD) and pin N11 of the FPGA, both are connected to GND.

[spark2k06]

Please check that CMD changes at the same time as the falling edge of CLK.
In the figure below, the waveform looks sluggish, but this is because a passive probe is connected. Ignore it for now.

2023-03-01 214837.png

Without going into detail because I can't right now, this is the result of the SD_SCLK and SD_MOSI (CMD) signals together:

SD_SCLK & SD_MOSI.png (27.73 KiB) Viewed 6324 times

[spark2k06]

In the UnoXT design, SD pins 8 and 9 are in the air, unlike the ZXUno. There doesn't seem to be any problems working over SPI, but we'll see if in native mode there are.... I will also try to physically force some PULLUPs with resistors here:

D1 & D2 SD pins.jpg (74.16 KiB) Viewed 6298 times

[kitune-san]

If you have time,
Could you connect the control_state signal of KFMMC_Controller.sv to the test port?
By looking at this signal, you may be able to tell which process is failing.

[spark2k06]

If you have time,
Could you connect the control_state signal of KFMMC_Controller.sv to the test port?
By looking at this signal, you may be able to tell which process is failing.

That will be the next thing I do... because before trying to make a physical PULLUP with 10K resistors in the UnoXT, I opted to make this simple change in the MiSTer PCXT code (assign D1 and D2 the value 1'b0 instead of 1'b1):

SDIO_DAT.png (9.84 KiB) Viewed 6212 times

However, to my surprise... in MiSTer it still works fine despite this change.

[kitune-san]

There may be a timing-related problem inside the FPGA, or there may be a problem with the verilog conversion.

First, I will replace the mister's mmc module with the one used in zxuno.
I will try this when I have time.

[spark2k06]

There may be a timing-related problem inside the FPGA, or there may be a problem with the verilog conversion.

First, I will replace the mister's mmc module with the one used in zxuno.
I will try this when I have time.

Thanks, I for one, for entertainment, will try to understand what might be going on, also at times in my spare time.

Debugging options on the Xilinx ISE platform are much more limited.