Mounted Image ejected after a while if OSD is active

[venice1200]

Hi, at first, many thanks for this really great software project.

I am using FlashFloppy 3.42 with my Artery AT32F435 Gotek Drive on my Amiga 500 (Board rev 6a) together with an OLED Display and like to use the FF-OSD as well.

I have installed FF-OSB v1.9 on a BluePil-Board created by Solarmon for the easy integration of FF-OSD into RGBtoHDMI for Amiga Computer. i2c is terminated at the BluePil Board, A0-A1 is bridged there as well. See https://github.com/solarmon/FlashFloppy/tree/main/FF%20OSD%20Adapter%20-%20Rev%202

My FF Config: FF.CFG.txt

I am using Solarmons Version of the RGBtoHDMI Project (RGBtoHDMI Amiga Denise DIP CPLD Rev 1.1) for my A500 which integrates the FF-OSD connections (Sync/OSD Output) directly, only i2c need cables from the Gotek to the BluePil Board. https://github.com/solarmon/RGBtoHDMI/tree/main#cpld-based-designs

The Amiga Keyboard integration and the OSD (flickering but readable) is working fine.

The problem is, after I connected the BluePil Board to the Gotek using i2c, all loaded Disk files are ejected earlier or later. Sysinfo for example isn't loaded, the disk is ejected before the program is fully loaded. The Amiga shows messages like "disk is unreadable" or "replace volume"

At the OSD I see before any "eject" a little Minus symbol.

If I remove the i2c connection between the BluePil Board and the Gotek, files can be loaded again without problems. If I use only the FF-OSD with the Gotek I have the problems as well.

Any Idea?

[keirf]

Well, that must be quite annoying! How long is your I2C cable? Could it be picking up noise?

Would you be okay to run a modified logfile firmware which would log bytes read from the OSD hardware whenever Gotek thinks an OSD "button" (aka keyboard hotkey) has been pressed?

[venice1200]

Hi and thanks for your response!

Well, that must be quite annoying! How long is your I2C cable? Could it be picking up noise?

Would you be okay to run a modified logfile firmware which would log bytes read from the OSD hardware whenever Gotek thinks an OSD "button" (aka keyboard hotkey) has been pressed?

The cables are about 28cm long and single lines without shield so pickup noise is possible as I see artifacts at the OLED Screen when all is connected together. Cable one is conntected between the Gotek and the BluePill, cable connects the BluePill with the Display. In total I have an i2c bus of around 56cm. As the Gotek and the OLED are not far away I can change the way of the cables to make it shorter, and I can try shielded cables as well.

I found old Souncdcard<->CD-Drive Audio Cables with shield and a matching cable with a shielded pair of wires. Let me try these at first.

I will report...

[venice1200]

The Audio cable doesn't work at all, I will build my own cable. Please provide the logging FW as well if you have one ready to use.

//edit discussion about i2c length

https://www.reddit.com/r/AskElectronics/comments/hq1vyh/why_does_my_i2c_bus_perform_worse_with_shielded/

//edit2 My Hardware... I have marked the i2c endpoints. At the left marker you can see the BluePill on top of the connector PCB. This Board is directly connected to the RGBtoHDMI Board under the Raspberry Pi.

see

[keirf]

Well a foot-long cable should probably be okay in practice. It could be a crappy Dupont connection?

Here is a test firmware build: https://github.com/keirf/flashfloppy/actions/runs/9830171888

You will see an Artifact link at the bottom of the above page. Download, unzip, then unzip the normal non-debug zip within. Then update to the alt/logfile firmware (https://github.com/keirf/flashfloppy/wiki/Logging-To-USB-Drive).

We are interested in the resulting FFLOG.TXT immediately after your disk gets ejected.

[venice1200]

I can't download the "artifact"directly.

If I drag anything onto it, and download the result, the checksum is the same as for the original.

Sorry, never used artifacts.

[keirf]

Try this link: https://nightly.link/keirf/flashfloppy/actions/runs/9830171888/FlashFloppy.CI.bd359b7.zip

[keirf]

Another suggestion: Try adding -slow to the end of your display-type line in FF.CFG.

This will make I2C 4x slower, but should be a lot more reliable. And I'm not sure the slower I2C comms will even be noticeable. If not, this is probably your easiest fix.

PS. I had somehow not noticed in my earlier comment the OLED hanging off your I2C chain. 2 foot of cabling and multiple connectors across an electrically noisy old motherboard is surely pushing it for I2C "fast" mode even though fast mode is not very fast.

[venice1200]

I will try -slow with my original cabling.

If this doesn't help I will try lower pullup resistors (~2,5k).

...and maybe both together.

Many Thanks

//Edit I will try to make some tests at the weekend.

[venice1200]

Because of a private matter I can't do the tests actually. I will keep you updated.

[keirf]

No rush. Let me know as and when.

[venice1200]

Hi again, it looks to me that -slow does the job. I am still on the last release firmware.

I use a simple two wire connection (blue&yellow) from the BluePil PCB to the Gotek and bridged from there to the display. No more "Ejects" and don't see any delays.

Will test more but i am really optimistic now.

[keirf]

Do you see any downside to -slow at all? I'm guessing not. 🙂

[venice1200]

I don't see/feel any differences.

How much slower does the i2c bus runs now compared to without -slow ?

[keirf]

A quarter speed. Seems it must still be fast enough.

[venice1200]

From my point of view it is fast enough. Both displays (old/osd) scroll like normal.

I will test the smaller pullups to see if this gives the "normal speed" i2c a bit more stability.

Many Thanks for your help.

[venice1200]

Sorry not to come back here. From my point of view it works fine.

I will build a second one and will test with lower pullups but not in the next few weeks.

Many thanks for your help and all the best!