MiSTer FPGA Forum

spark2k06 wrote: ↑Mon Feb 27, 2023 4:54 pm

kitune-san wrote: ↑Mon Feb 27, 2023 3:13 pm

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

kitune-san wrote: ↑Tue Feb 28, 2023 12:19 pm

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

spark2k06 wrote: ↑Tue Feb 28, 2023 2:12 pm

kitune-san wrote: ↑Tue Feb 28, 2023 12:19 pm

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.

kitune-san wrote: ↑Tue Feb 28, 2023 2:26 pm

spark2k06 wrote: ↑Tue Feb 28, 2023 2:12 pm

kitune-san wrote: ↑Tue Feb 28, 2023 12:19 pm

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?

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.

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

kitune-san wrote: ↑Tue Feb 28, 2023 2:52 pm

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...

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

Wrong, system_2MB
I am a little confused.

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

kitune-san wrote: ↑Tue Feb 28, 2023 3:25 pm

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

Oops! commented out...

kitune-san wrote: ↑Tue Feb 28, 2023 3:29 pm

2023-03-01 002834.png

Oops! commented out...

UCF file of UnoXT model is this:

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

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.

kitune-san wrote: ↑Tue Feb 28, 2023 3:47 pm

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.

kitune-san wrote: ↑Tue Feb 28, 2023 3:47 pm

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:

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

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

kitune-san wrote: ↑Mon Feb 27, 2023 3:05 pm

I see the SD_SCLK signal running continuously.

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.

The following is a normal case.

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

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.

kitune-san wrote: ↑Wed Mar 01, 2023 12:14 pm

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:

The trigger (single mode) is never activated:

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

kitune-san wrote: ↑Wed Mar 01, 2023 12:49 pm

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:

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

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;

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

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).

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

kitune-san wrote: ↑Thu Mar 02, 2023 12:23 am

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.

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

kitune-san wrote: ↑Wed Mar 01, 2023 12:49 pm

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:

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:

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.

kitune-san wrote: ↑Thu Mar 02, 2023 9:51 am

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):

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

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.

kitune-san wrote: ↑Fri Mar 03, 2023 12:15 am

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.