If your BlueSCSI is not working, then looking at the log file BlueSCSI creates on the SD Card is probably one of the first things to check. That said, the log also contains useful information that may allow you to improve the speed or reliability of your BlueSCSI.
The log file is automatically created on your SD card when it’s powered on. This can be very helpful in troubleshooting common issues or simply confirming information, such as the amount of voltage your Raspberry Pi Pico board is getting, or if your hard drive images are being detected properly.
Every time your BlueSCSI gets power a log.txt file is written to the root directory of your SD card. Please note, the log file is overwritten every time the Raspberry Pi Pico on the BlueSCSI is powered on, so be sure to copy your log file to your PC if you need to save it.
Note: You can also log via USB serial to another computer. See USB Serial Debug for details.
The normal log should contain a startup sequence that details the BlueSCSI Firmware version you have plus the hardware flash size. Following that will be the detected SD card details.
Example:
Platform: BlueSCSI
FW Version: 2024.04.02-release Apr 3 2024 02:22:50
Flash chip size: 2048 kB
=== SD Card Info ===
SD card detected, exFAT volume size: 14799 MB
SD Name: SD16G, MID: 0x27, OID: 0x50 0x48
If you cannot find the file:
* This implies that the Pico cannot find the SD card. Check your SD card is working. Even if it seems to work, it’s suggested you also try to format your SD card with the SD Memory Card Formatter tool with the “Overwrite format” option selected.
* If it still fails, you should also confirm all the solder joints/tracks between the SD card socket and the Pico board are fine and no shorts exist. You can find interactive BOMs under Hardware for each BlueSCSI variant, which will allow you to trace the tracks on the PCB to other components.
From this point on in the log, if Debug Logging is enabled, all entries are usually timestamped with the number of milliseconds after boot at the start of each line.
Other sections of note:
=== Global Config ===
Global config info parsed from the Bluescsi file if it exists. If you configured something specific and it doesn’t appear here, then you may have a typo.
=== Finding images in / ===
Details of the disk images found on the SD card.
=== ROM Drive ===
The built-in ROM Drive, if enabled.
=== Configured SCSI Devices ===
The list of configured SCSI devices the BlueSCSI will respond to. This will include the SCSI ID, the Block Size, Quirks (if enabled) and the image Size (in kB).
=== Network Initialization ===
If a Pico W is installed and Wifi Daynaport emulation is configured, connection information for the configured wireless network will be listed below.
Initialization complete!
At this point, the BlueSCSI is responding to SCSI requests.
INFO: Pico Voltage: 3.273V.
This is the internal voltage that the Raspberry Pi Pico is receiving from the BlueSCSI and should be around the 3.3V mark. If this is substantially lower (ie: below 3.2V) then you should look at how your BlueSCSI is being powered to see if it’s getting enough voltage. This can be a problem if you’re using a BlueSCSi with a Pico W installed and Wifi Daynaport emulation configured, as it draws more power than can sometimes be provided via using SCSI termination power.
In addition to the default logging, you can enable debug logging to get extra information in the log. This can help with specific issues, particularly when trying to figure out specific SCSI commands not implemented by BlueSCSI or the host.
Most (but not all) debug log entries start with DBG after the log timestamp.
Debug logging adds a lot of speed overhead and extra accessing of the SD card, slowing things down. Unless you really need to see this stuff, it’s usually best to leave debug logging off by default.
To enable debug logging, create a new text file named bluescsi.ini and place it in the root directory of your SD card. Edit this .ini file with the following text:
[SCSI]
Debug=1
Here are some of the errors and warnings you may find in the log file with details on their associated meanings.
The SCSI 0x1A command is used by the host to find the size and geometry of the drive using Logical Block Addressing or LBA.
Usually this will be followed by something like:
Current settings are 63 sectors x 255 heads = 16065 but image size of 4194304 sectors is not divisible. This can cause error messages in diagnostics tools.
This is due to the image size not being a multiple of the number of heads (max 255) and sectors (max 63), multiplied by the sector size (usually 512 bytes). By default, BlueSCSI uses the max values for sectors and heads when the host asks for this information. The easiest way to remove this warning is by making sure the size of your disk image files is a multiple of 16065 x the sector size in bytes.
Most of the time this is usually not an issue. Some devices like sequencers or really early SCSI/SASI/ACSI systems may have issues. See Compatibility your specific host system.
Notes:
- The original LBA specification usually limits the maximum drive size to 8.4GB (8422686720 bytes). BlueSCSI supports the LBA48 extension for larger drive sizes, but this relies on the attached host supporting LBA48.
- Advanced users could define the number of sectors and heads specifically to get a different multiple in the Bluescsi file. This is not normally required should be left unset where possible.
The disk image file isn’t in one continuous section on the SD card. This can affect performance when accessing this image. See Image File Fragmentation for more details.
This usually means the SD card is faulty. The full entry will give more details, include which sector failed, etc.
Example:
SDIO card reports write CRC error, status 0x58000000
SdioCard::writeSectors(0x017960A4,...,64) failed: 7
SD card write failed: 0x00
SDIO checksum error in reception: block 0 calculated 0xF76C38ABE5BD4FB5 expected 0x726F722C20737461
You can try to format your SD card with the SD Memory Card Formatter tool with the “Overwrite format” option selected.
Some systems don’t support parity on the SCSI bus. For these systems, you need to disable parity in the Bluescsi file. Some systems that need parity disabled are documented at Compatibility.
If your system does support parity, you may have a connection issue. Check your SCSI cables and connectors for damage or try a new cable. You can also check the soldering on the BlueSCSI relating to the data pins for the SCSI bus. Remember to also check the host SCSI connections/boards if you’re restoring an old machine as well (eg: corrosion or bad joints).
For reference, the data/parity specific pins are:
* 50 pin (Desktop):
* Pins 2, 4, 6, 8, 10, 12, 14, 16, 18.
* 25 pin (External):
* Pins 8, 10, 11, 12, 13, 20, 21, 22, 23.
* 40 Pin (PowerBook Internal):
* Pins 6, 8, 10, 12, 14, 16, 18, 20, 22.
You can find interactive BOMs under Hardware for each BlueSCSI variant, which will allow you to trace the tracks on the PCB to the other related components.
Note: If parity is disabled in your Bluescsi but Debug Logging is enabled, you can still get parity errors in the debug log.
This indicates that your SD card may be too old or slow to keep up with the SCSI bus of your system. Try a newer or faster speed SD card.
You may also try and format your SD card with the SD Memory Card Formatter tool with the “Overwrite format” option selected.
As per the finishRead timeout, this indicates that your SD card may be too old or slow to keep up with the SCSI bus of your system. Try a newer or faster speed SD card. It may also be possible that your SD card is faulty.
Generated 2024-12-11