SpritesMind.Net

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.

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

Just to offer another alternative for production: i've used oshpark and sierra express for pcb, and digikey for the components. Bit expensive, but at least the parts will not be counterfeit.

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

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

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

MintyTheCat wrote:Did you contact Prophet36?

No i didn't want to bother him yet. I've figured he would've dropped in if he had time.

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, i got it to boot the firmware, but now chasing another issue:
The SD Card doesn't clock any data out ---
i see the command sent to SD, but no response, not even ACK.
I've noticed that spi_master is coded to be MODE3, but MODE0 is recommended for SD, could that be the issue?
Here is the LA trace ...

MintyTheCat wrote: Could you tell us where you found that file please?

it's mentioned in bulletpoint #9 here:
viewtopic.php?p=24032#24032

Thank you,
do you have any idea what project does cksum.xsvf coming from?

i've tried 20140524 and dev branches. At this point i'm inspecting my soldering. Could be that something is not soldered or shorted.

Yes, I did the same thing and it fails to boot into the firmware. I will check with LA to see actual address and data bus. I can see that FPGA is configured but I don't see any accesses to 0x60000 and up over SPI.

Based on vhdl (actually assembly in mem_arbiter.vhdl ) i would assume that fpga.bin is flashed at 0x0, and firmware.bin at 0x60000. Is it correct?
I've flashed and verified the spi using those offsets, but firmware is not booting up. I can confirm that fpga is loaded correctly. All voltages and ...

Thank you! I don't believe i didn't notice it...