proper offsets for gordon flash tool, and bringup.

[MintyTheCat]

As far as i understand from vhdl and m68k code, everything is in place on 20140524 branch. i can check out dev shortly and will let you know

Ok.

Then some further testing is in order.

I have a L-A the Logic from Salea and have ordered the Open Workbench L-A (should arrive soon).

What I could do is to carry out the exact same tests as you to try to determine what is different between our hardware and software.

Yes, Prophet36 is a pretty busy guy but he does read this Forum when he has time.

However, in a very real way the experience that you are having now could well be something that someone else could have who is trying to build their own UMDK so it serves the community to work out problems as they arise if that makes sense.

I shall have a look at the Schematic and then work out which pins to connect and then repeat your SD-Card test myself.

[fixel]

I'm also using LA from saleae. Use small connector on top of lx9 board. It has all SD signals marked on silkscreen. You need cs,clk, datain, dataout. Connect all ground and all 4 SD signals to the LA. Set trigger to start capturing on falling edge of CS and capture normal powerup of the console with working SD. Please attach captured session to this thread.
Word of advise - before connecting any signals make solid ground connection between sega and your pc!!!!
You can also select SPI protocol decoder and configure it to CPOL=1, CPHA=1
What i basically noticed that SD card doesnt drive DO line. It is floating. The spi flash works fine, as the console boots into the firmware. While debugging the menu.elf with gdb, it is stuck in infinite loop, waiting for the card to reply 0xfe on CMD0. Just very beginning of the sdinit in sdcard.s

[fixel]

P.S. I've tried about 9 different, known good SD cards, with various specs. It is not the sdhc vs anything else issue. Every embedded project that uses SD cards in SPI mode, that I've encountered uses SPI mode0 (cpol=0, cpha=0). Umdk uses mode3. I'm going to try to compile something small on one of my dev boards with sd card to see if this could affect the cards.

[fixel]

Yes, Prophet36 is a pretty busy guy but he does read this Forum when he has time.

However, in a very real way the experience that you are having now could well be something that someone else could have who is trying to build their own UMDK so it serves the community to work out problems as they arise if that makes sense.

This is exactly the reason I don't want to PM him. If he has time, he will reply here, in public forum. Same as anyone else who had similar issue.

[fixel]

Issue identified!
Apparently interbyte delay during init sequence was not long enough. I'm using NTSC version megadrive, and the processor runs slightly faster. The SPIDATB register was overwritten before byte was clocked out.
I'm adding region detection and adjusting delays into menu. But ultimately -- proper status register in FPGA will solve any and all issues with timing, as the cpu will simply wait for a status (transfer complete, or similar) rather than arbitrary delay. I'll address that at later stage.

To summarize:
1. for proper testing you need to build some "jumper jig", that will bridge data lines to address lines, preferably with latch, so you can detect bit patterns.
In my case - two of the address lines were shorted with practically invisible solder whisker. I couldn't spot it under 20x microscope, and ultimately applied running "1" and running "0" to cartridge connector, and wrote small test FPGA configuration to identify the issue.
2. m68k/menu/sdcard.s have to be rewritten with more standard initialization routine (right now not all cards are supported). Right now there are no timeout detections or any error handling. We either need to increase delay (no harm in PAL region, since it's only relevant for first 5-6 commands), or implement proper FPGA status register.

[MintyTheCat]

Issue identified!
Apparently interbyte delay during init sequence was not long enough. I'm using NTSC version megadrive, and the processor runs slightly faster. The SPIDATB register was overwritten before byte was clocked out.
I'm adding region detection and adjusting delays into menu. But ultimately -- proper status register in FPGA will solve any and all issues with timing, as the cpu will simply wait for a status (transfer complete, or similar) rather than arbitrary delay. I'll address that at later stage.

To summarize:
1. for proper testing you need to build some "jumper jig", that will bridge data lines to address lines, preferably with latch, so you can detect bit patterns.
In my case - two of the address lines were shorted with practically invisible solder whisker. I couldn't spot it under 20x microscope, and ultimately applied running "1" and running "0" to cartridge connector, and wrote small test FPGA configuration to identify the issue.
2. m68k/menu/sdcard.s have to be rewritten with more standard initialization routine (right now not all cards are supported). Right now there are no timeout detections or any error handling. We either need to increase delay (no harm in PAL region, since it's only relevant for first 5-6 commands), or implement proper FPGA status register.

Ah yes - region, I had not even considered that. Prophet36 developed UMDK using a PAL UK Megadrive 2 (not sure which board he has). I do recall that when he was doing some testing we found that code would not run correctly using my MD 1. Up to now both me and Prophet36 have done all our UMDK tests using PAL MDs.

Indeed, the region issue needs to be addressed.

To be honest, over the years I have found many issues wrt SD-Cards working and not working with various DevBoards.

I think it would be a good idea if code could be contributed to a UMDK Jig Repository as I know very well that it will be required for anyone who wishes to test their UMDK during production.

Having to solder SMT scares the hell out of me

Long-term I would opt to have an FPGA Status Register.

Glad that you got it up and running.

[prophet36]

Apologies, I didn't notice this thread. In future please feel free to PM me to notify me of a thread that could use my attention.

Excellent work tracking down the bug, fixel. Is it sufficient to merely increase the delay count used during initialization?

The reason I didn't implement a status register is because the process of clocking the SPI bus is deterministic, and is guaranteed to work[1] provided there are enough NOPs - in general I have favoured adding complexity to the 68000 rather than the FPGA.

[1]Guaranteed to work, but perhaps not guaranteed to return sane bytes from the SD card, but that's another story.

[fixel]

Yes, increasing the delay solved the issue. There is still a fantom issue present with SDRam though. Sometimes entire bank of it gets corrupted, even when 68K is halted by debugger. I'm trying to trace the issue.

[prophet36]

Yes, increasing the delay solved the issue.

Great. What did you set it to? I would like to update the git repo to reflect any changes needed for NTSC machines.

There is still a fantom issue present with SDRam though. Sometimes entire bank of it gets corrupted...

The first step is to test the SDRAM in isolation. There's a design called "readback" which can be used for this purpose, like this. Remove the LX9R3 board and flip its power jumper to "USB" and test it in isolation, writing 16MiB of data and reading it back repeatedby, verifying after each readback.

If an entire bank is getting corrupted, the most likely cause is a dry solder-joint on one of the BA[0:1] lines from the FPGA to the SDRAM.

Another possible (though unlikely) cause of SDRAM corruption is the way the bus arbiter schedules DRAM refresh cycles: rather than schedule refreshes on a timer (thus ensuring the minimum number of refresh cycles as per the SDRAM spec), it schedules a refresh after every single 68000 read or write from SDRAM. Thus, the memory controller is guaranteed to be immediately ready when the 68000 needs to access it. The SDRAM is therefore massively over-refreshed, since the 68000 accesses SDRAM frequently. But you can deliberately sabotage this scheme by copying some code into the MegaDrive's onboard 64KiB of RAM, and executing it there, thus starving the SDRAM of refresh cycles. But in that case you'd see a gradual degradation of the SDRAM's data over a period of several tens of seconds, rather than an outright corruption of an entire bank.