search

retro16 / acsi2stm

Atari ST ACSI to SD card converter with a STM32
GNU General Public License v3.0
150 stars 34 forks source link

C partition is getting corrupted only on STE and strange LED activity #35

Closed mamejay closed 1 year ago

mamejay commented 1 year ago

This is a weird one. I have created Version 3 boards and they work perfectly on my 1040STFM I gave one to my friend that has a 1040STE and it works fine initially but after loading a game that is not in the primary partition it seems to corrupt or wipe that partition. I am using a ready made disk image from Petari. Another thing I noticed is that the drive activity LED which is connected to PC13 is showing as slightly lite even when there is no drive activity. When the drive is accessed it flash at 100% brightness then goes back to say around 50%. On my 1040STFM it is totally off unless there is drive activity. Any ideas of what could be the issue?

retro16 commented 1 year ago

Hi, thanks for reaching out. A weird one indeed ! Nice catch with this half-bright LED, it provides useful information. The LED is lit when commands are processed. Half-bright would indicate that the STM32 detects incoming commands all the time.

Can you provide a verbose output from this problematic STE ? (recompile with ACSI_DEBUG and ACSI_VERBOSE set to 1)

mamejay commented 1 year ago

Thanks for that! I have changed the acsi2stm.h updated the #define ACSI_DEBUG 1 and #define ACSI_VERBOSE 1 It programs up successfully but I get garbage on the serial monitor when I start it out of the Atari. Getting late here and I will test at the machine but should it show any information if the device is started NOT connected to an Atari? I will test further when I get home from work

mamejay commented 1 year ago

ASCS2STM Output.txt OK. Tried a different UART USB and managed to get output now. This is me loading my Petari game image and loading a game. I also tried to switch off and back on again to make it corrupt the C drive but it did not. I did manage to get it to corrupt the image on the 3rd try but I could not save all the output from the serial monitor. Is there a way to capture all of the output? I used Putty but output is no clean at all

mamejay commented 1 year ago

Further to my previous posts. I managed to get a 1040STE PAL model and I get the same half lite led when not being accessed. Attached is a copy of the schematic I drew up. What could be the difference with the STe? I do not get corruption on this model and now I cannot make the existing one corrupt a SDcard. Just curious about the LED. Do I need a pulldown resistor or something? image

retro16 commented 1 year ago

Thanks a lot for the extra feedback.

I think the half-bright LED is because you power it with 5V. PC13 is 0V when the LED is on (this is okay), but it's only 3.3V when the LED is off: when the LED is supposed to be off, you still have 1.7V across the LED, which is barely enough to power it. Powering the LED with +3.3V and lowering R1 to match the decreased voltage should fix the issue.

About corruption, I found a very strange hardware glitch on the STM32 during the development of 4.0. It's hit or miss, and it seems linked to code compilation. Maybe it's triggered by some bad interaction with code cache or execution timings inside the STM32, anyway I can't explain it.

How it behaves:

It may explain some of the strangest bugs reported in the GitHub issues here.

Anyway, I changed the low level DMA transfer code in 4.0 to try to work around the glitch, but since it doesn't always happen, I can't say that the workaround is 100% efficient. The price to pay is slower transfers by 5-15%, but who cares ?

Can you try the latest 4.0 alpha release ? The "strict" variant of the 4.0 alpha firmware should be very stable already, maybe you could consider it if it matches your needs. It still has a few known issues, but probably less than 3.02 as far as I know. "strict" is just compiling with #define ACSI_STRICT enabled. You can also switch strict mode dynamically with the BOOT1 jumper just below the firmware flash jumper on the blue pill.

To answer your 5 months old question about capturing serial: I use the good old Arduino serial monitor, which has long enough scrollback for my usage. By default, the speed is 2000000.

mamejay commented 1 year ago

Thanks so much for that. I didnt realise there was a new release. I will flash my board and test it out. As for the LED I will just leave it for now but might hack my test board and feed 3.3v instead of the 5V

TzOk83 commented 1 year ago

This may be a hint or not, but STe has buffers for the ACSI lines, while ST - doesn't. As a result, there is a slight difference in timings between ST and STe. It is worth remembering that ACSI lines should have pull-up/termination resistors.

I slightly regret the decision of dropping the integrated ACSI driver in favor of the unfinished GEMDOS mode. I'd rather go with 2 separate builds. ACSI would be a fully polished, production quality release.

retro16 commented 1 year ago

@TzOk83, now that 4.00 is out, the old integrated driver is completely outdated. GemDrive mode is now finished and works better than everything else I ever used on my machines (including floppy disks because TOS sometimes fails to detect floppy swapping). No regrets dropping the old stuff.

About timings, the "new" DMA code since 2.3-2.4 should not be timing sensitive anymore, it properly samples the ACK and CS lines at timings when data is known to be present. Issues with ACSI2STM were in the STM32 that have hardware bugs in timers: it produced glitches on the DRQ line, shifting data by 1 extra byte. This is hopefully worked around.

I don't have access to an unbuffered ST, nor do I have access to any original ACSI peripheral, so I have no way to check pull-up / termination, but from the documentation I gathered, nothing indicated that pullups were required anywhere.