USB bug?

[blackch0]

On the STmini board (a MiST) clone, the USB connectivity fails after running this core for some minutes. The core keeps running but USB devices (mouse/keyboard) get disconnected. Need to reset the board to get them to work again.

All other cores work fine, even the old ST core.

[gyurco]

Firmware version?

[blackch0]

tested a few: 200622, 201011 and latest 210130. Same behaviour.

Apparently if you eject the SD card (after loading TOS, etc) the core will run fine but with the SD card inside the socket USB crashes within 20 minutes aprox (sometimes takes 5 min other times more).

[gyurco]

That looks like a hardware issue for me. A log from the serial port of the ARM CPU would help. If it's not possible to use the ARM UART, then you should ask the manufacturer of the device. Maybe it's just a powering issue, try another power supply, different keyboard/mouse, etc...

[blackch0]

Thanks for the answer.

Any ideas as why all other cores work without this issue?

[gyurco]

No idea, it's true that MiSTery uses different code path in the firmware than the ordinary cores, but it never crashed for me. Also would be good to find out if really the firmware crashes, or the error is in the FPGA side. Even OSD doesn't come up when the Atari looks crashed?

[blackch0]

It seems is the ARM is crashing. The OSD doesnt show up even if you push the button on the board but the core keeps running (for example if you have a game running it will keep on running). I contacted Daniel at 8bits4ever (the manufacturer). He said they've been trying to figure out the bug with no success so far.

I will try a few things myself to see if I can narrow the issue.

Thanks!

[gyurco]

I'm suspecting a hardware issue then. ARM should not crash. An ARM UART connection could be helpful to see what happens.

[blackch0]

The board does not have debug port, only RX/TX serial connection (the ones used for MIDI). Would be possible to debug it through that port?

In the meantime I've added a couple of decoupling capacitors to see if that helps. It seems to me now with the capacitors takes longer for the board to crash.

[gyurco]

No, the ARM has its own UART. (I don't really understand why they spare it, even the cheapest crap routers have provisions for the SoC's UART). The crash happens when are you using ACSI disks? Or floppys? Is it crash if you don't use these two (disable them in OSD)? Did you try other SD Card? They can be power-hungry.

[blackch0]

I tried to debugging it through the USB port using hyperterm, but I couldnt see any error messages, just regular key log messages.

Im using ACSI disks (in direct SD mode and also with an img file). I will try different SD cards as you suggested.

In any case, thanks again for your help, and your work of course.

[gyurco]

I've never tested direct mode in MiSTery, it would be good to see if it crashes if you disable that.

[blackch0]

Hi, just letting you know that I've managed to get the core running stable. As you said from the beginning, it was a power related problem. The solution was a combination of replacing the 3.3v regulator and adding some decoupling caps and getting a good quality USB cable for feeding the board.

What still puzzles me is the fact that the board was working fine with the rest of the cores... I guess Mistery core might be more power hungry than others.

In any case, thanks a lot for your help!

[gyurco]

Good to hear it's working!

[blackch0]

Hi! After a lot of testing I was able to further narrow down the issue to the memory chip (probably having slightly different timings than the one from the MiST). Im now running a Mistery core variant compiled for the "Mistica FPGA" and it is running completely stable without any board modifications. Cheers!

[gyurco]

Strange it kills the ARM. Maybe those extra capacitors are still not a bad idea.