Can't make Aliexpress (chinese) Bluescsi v2 work (Desktop 50P)

[MalvareRJ]

I'm sorry to open an issue for this, but I'm lost.
It may seem easier, and of course more logical to return it, but it's impossible to arrange a return with Aliexpress vendors.
I would like to try solving this myself.
I bought this to use on an FM-Towns, to take advantage of the CD Audio feature.
But the system is not reading the mounted devices.
At boot time, the computer can recognize there is a device in every assigned ID correctly, but it won't communicate with these devices.
Also, when scanning the bus, both computers take a while at these devices (ID0 and ID3 in my case) before continuing to the next. At empty IDs it goes quick to the next.
I have tried multiple SD cards, connected the board at the internal and external SCSI ports, tried a few arguments on the ini file, nothing changes.
Have also tested the board on my X68000, and the same happens. The computer "sees" that there is something at the correct IDs, but can't load anything.
I have enabled debug on the ini file, but I can't understand all of the log.
I'm asking here hoping someone can help to understand the log file.
Is it possible to say from the log, if the problem can be at the Raspberry Pi Pico? I believe it is also a chinese clone.
The board is the latest revision (2023.10a), and all seems fine with other components. I'm suspecting the Pico may be the problem.
I have also tried to remove the PWR_ON jumper and use an external USB PSU for the PI, as the 5V line at the Pico pin 40 was below 4,65V when using only the Berg connector, but that made no difference as well.
I have noticed in the log that it tells buttons are pressed and it seems to eject the CD and load it again (as there's a single image on the SD card). Is it expected?

By the way, both computers have other drives emulators (BlueSCSI v1.1 I made myself with a Bluepill for the FM Towns, and an also home made RaSCSI for the X68k), and both work flawleslly. The BlueSCSI v1 on the FMT even work fine with the same SD Card (same files) that I have also tried on the v2.

Really appreciate anyone that can shed some light on this!

log.txt

[erichelgeson]

I understand wanting to save a buck but honestly anything on Ali express is a crap shoot - no idea what components are actually on the board. Honestly they're more expensive too than what our sellers offer (comparing US/US - tariffs/taxes/etc excluded). I'd much rather debug a batch of V2 PCB's you built yourself for your collection/friends.

There are some clues in the logs that indicate what could be wrong: Every selection reaches the command phase and then stops:

Current buffer: 0x00000006/0x00000006, next 0x00000000 bytes

Six command bytes expected but none received. The board is holding REQ asserted and waiting for the computer to answer with ACK, and and never does. That is why both machines see something at ID0 and ID3 and then sit there for five seconds before moving on.

The firmware picks the REQ pin at boot based on which hardware revision it detects, and it decided your board is pre-2023.09a. So it is driving REQ on GP17 instead of GP19.

Detection works by reading GP16 and GP17, which are pulled up to 3.3V on 2023.09a and later boards. On your board they are not reading high. The phantom eject presses you noticed are the same thing from the other end - in the older-hardware mode the firmware reads the SCSI ATN and ACK lines as front buttons, which is why it ejects and reloads the CD on its own at boot.

To confirm flash the plain BlueSCSI_Pico firmware instead of the SPDIF one, boot it, and look in log.txt for the line

I2C Supported

If that line is missing, GP16/GP17 are not pulled up.

[MalvareRJ]

Dear Eric,

Thank you so much for your reply and support!

It is really not a matter of saving a buck, but being able to acquire the hardware at all.
I live in Brazil, and we are experiencing a deep political and intitucional crisis here.
Importing from US or Europe is impossible with my budget, as the currency rates, shipping costs and taxes are sky high.
My first instinct and desire was to build the boards myself, as I have other computers that would benefit from it, but making the math, I had to give up that route.

Speaking of the problem, you nailed it!
Inspecting the board more carefully, I found a crack in the pull up resistor for GPIO16 (R24). Replaced it and the computer can now talk to the board fine! It booted from my HD image and also from CD!

Big Thank You!

Just one more question, I have a S/PDIF enabled receiver that I intend to use for CD Audio.
The documentation says to wire up the S/PDIF DAC to the GPIO 16 (SDA), but the firmware log says to use SCL (GPIO 17).
Which one is supposed to be used actually?

Thanks once again for all your help, and for all your hard work in this amazing device!

Best Regards.

[erichelgeson]

Understood - international shipping is just terrible right now. I believe the firmware log is correct - if the docs are wrong (after you validate) could you please update? I don't have my setup handy.

[MalvareRJ]

Dear Eric,

Confirmed that the firmware info is correct, so made as you asked and updated the CD Audio wiki.
Now I'll enjoy it :-)

Thanks!