Device detection fails. Boot fails as well.

[grzybsonssg]

I am trying to build acsi2stm and I am having hard time.

Symptoms:

• I etched SD card image with ICD Pro from Jookie - it does not boot.
  Source: http://atari.8bitchip.info/DiskImgPP1.html
• I etched SD 1GB card image from Pera Putnik - it does not boot.
  Source: http://joo.kie.sk/?page_id=332
• I booted from floppy with ICD Pro, then run IDCHECK.PRG - device is detected about once in around 20 tries

Some details:

• On serial output, when booting I can see something like below and nothing happens.

-----------------------
ACSI2STM SD bridge v1.1
-----------------------

Initializing ACSI bus ...
ACSI bus ready
Initializing SD card 0
Size: 7388MB - 15130624 blocks
SD card is bootable
1 SD cards found

--- Ready to go ---

Command  8 0 0 0 1 0
Send:512 bytes
Success

• This is output when running IDCHECK.PRG. However the device stays undetected.

-----------------------
ACSI2STM SD bridge v1.1
-----------------------

Initializing ACSI bus ...
ACSI bus ready
Initializing SD card 0
Cannot init SD card
0 SD cards found

--- Ready to go ---
Initializing SD card 0
Size: 7388MB - 15130624 blocks
Command  3 0 0 0 12 0
Initializing SD card 0
Size: 7388MB - 15130624 blocks
Send: 70 0 0 0 0 0 0 E 0 0 0 0 0 0 0 0 0 0
Success
Command  12 0 0 0 24 0
Initializing SD card 0
Size: 7388MB - 15130624 blocks
SD 0 ID ='ACSI2STM SD 0 7388 MB   v1.1'
Send: 0 0 1 0 1F 0 0 0 41 43 53 49 32 53 54 4D 20 53 44 20 30 20 37 33 38 38 20 4D 42 20 20 20 76 31 2E 31
Success
Command  12 0 0 0 0 80
Initializing SD card 0
Size: 7388MB - 15130624 blocks
SD 0 ID ='ACSI2STM SD 0 7388 MB   v1.1'
Send:
Success

• I used some cheap blue pill and micro sd module (with buffered) lines. I suspect that STM32 might be a fake, because of markings. Please look at the F letter on photo, it should be on next line:
  https://a.allegroimg.com/s720/118a5c/e51e5c7a499b809e3ae4c8f7aa82/Modul-STM32F103C8T6-Board-STM32-ARM
• Wires are max 7 cm
• I did a little shortcut - instead of connecting 7 unused CS pins (PA3-PA1,PB0-1, PB3-4) to ground, I just removed them from sdCs array - does it pose a problem?
• I tried STM32 Arduino libs from Dan drown (https://github.com/ddrown/Arduino_STM32/)
  as well as from Roger Clark (https://github.com/rogerclarkmelbourne/Arduino_STM32)
• I tried two different USB chargers to power the device.
• I have only one micro SD card.
• I have 1040STe, 4MB RAM, TOS 1.62DE, DMA chip C38739-001A (the so-called better one).

I am starting to believe that I have a fake chip. Maybe there are slightly different timings on GPIO and device goes out of sync?

Maybe do you have any ideas what to do next?
Maybe try to get different blue pill?

[retro16]

Thanks for the very detailed issue, that helps a lot !

First things first, here is a list of things I consider good from what you said:

• Your electronics are good because many commands were exchanged in the IDCHECK.PRG trace, so there is some form of communication.
• Altering the sdCs array is a good solution to avoid grounding pins. The code adapts itself automatically to that situation.
• The DMA chip of the ST is never an issue for reading.
• My main machine was also a 1040STe with the same configuration (I don't have it right now to test).
• My STM32 also has the F letter misplaced, so if you have a fake chip, so do I.

Things I'm unsure about:

• The IDCHECK.PRG trace says "0 SD cards found". The SD card is detected later. It shouldn't be a problem because the card is initialized again for most commands anyway.
• I heavily recommend the Roger Clark Arduino library, but my code was done a while ago with a different library, and I don't remember which one it was. That may have an impact on the time critical parts (more on that later).

Things I'm pretty sure don't work:

• Data transfers (DMA) are probably the problem because commands work.
• The timing-sensitive functions of my code are probably not working on your configuration. That's an issue some other people already had.

That would explain exactly the traces I see and also the detection issue you have.

DMA transfers are too fast to be cleanly implement on the STM32, so I use fixed delays. It worked on all my machines (and it worked for other people too), but it seems to be hit or miss.

Could you try experimenting with the pulseDrqSend function ? The aim is to find the correct number of lines (between line 230 and 236 in the last version) to have the correct DRQ pulse timing. Some had more success by removing 3 or 4 lines, but you may have to add 3 or 4 lines.

The best way to test is to try booting the ST: if you have more than one command on the trace, it means that reading from the SD card is working to some extent.

If you need to test your image, I recommend you test on the Hatari emulator because my code follows its implementation so the behavior should be the same.

[retro16]

I did some checks on an up to date Roger Clark environment. It seems that the optimization level has an impact. Can you try with Tools/Optimize: Fastest (-O3) ?

[grzybsonssg]

Hi! I switched the optimization level to: Fastet (O3). Results are at least interesting.

At first - nothing changed. I did some testing and after around 15 minutes of meddling - it booted!
I run some games, even copied some files from floppies. Unfortunately - it worked only for like a 30 minutes. When I turned everything off to copy some stuff from PC, and then on - it failed to boot again (with messages still logged on serial).

During a day I managed to get it working only once :(

I think I'll try shortening wires a little (now 7cm). I have also borrowed another blue pill from a friend.

[grzybsonssg]

I have another observation from today!

Just by accident I powered the ACSI2STM from laptops USB (instead of charger).
Guess what - it booted! And it booted every time I have tried!
But not with phone chargers..... (one charges is Huawei 5V 1A, another one LG 4.8V 1A)

During tests:

• some games from P.Putniks free image run flawlessly
• We were at demo HDD version crashed randomly during loading (screen turning to blue)
• Flipo demo HDD refused to load.
• Bad apple by fenarinasra crashed stopped at loading screen at random moments.

In following days I'll try to experiment with pulseDrqSend as you suggest.

[retro16]

That's nice progress, thanks for the feedback !
You probably have some electrical noise issues. Phone chargers often generate more noise than a PC and this kind of noise is difficult to filter. Reducing wire length and adding a decoupling capacitor (a big ceramic cap, something like 10uF) between 5V and GND might help.
pulseDrqSend adjustments may also improve things if the data signal is removed too early by the STM32. In that case, try to add a few lines. It's all guesswork.
Ideally, you would need to probe the DRQ and ACK signals with a logic probe or a digital oscilloscope during a big faulty transfer: the correct signal is DRQ rising right after ACK is pulled low by the ST, the sooner the better. If DRQ goes up before ACK goes down, pulseDrqSend is too fast and it may remove the data byte before the ST read it.

[grzybsonssg]

Hi,

I looked carefully at the bottom of the blue pill, and there are already to capacitors between 5V and GND - on mine boars labelled C5 and C7. Unfortunately, there is no label on them, parameters are unknown. According to some sources on web those might already be 100n and 10u :/
I wonder how much current the acsi2stm draws...

However I have a major breakthrough :)

• I switched optimization level back to "Smallest"
• Added three lines inside pulseDrqSend
• Disabled all the serial logging (important!)
  Right now "Bad apple" runs smoothly from the beginning to end :) There is no sound though. I might have STE DAC broken or something in-between, because I already experienced it with ProTracker or game "Stardust".

Demo "We were at" is causing problems. It loads and runs until certain point. It crashes before image screen with girl and her hair waving. FDD version loads some additional data at that moment. What's interesting is that Hatari emulator fails as well, but due to some reports - Ultrasatan does not. I'll try to contact Leonard/Oxygene for that.

[grzybsonssg]

Hi! I heard that someone at atari-forum is trying to exact-cycle Drq pulses using machine code's NOP instructions. What do you think?

[retro16]

Hi, If you still have issues, I recommend that you upgrade to the 2.0 beta I just uploaded. Beware that there are minor pinout differences.