Jubatian
commented
7 years ago I merged the bugfix in, I assume it should work as it likely received sufficient testing with the new bootloader and Flight of a Dragon which already use the revised port inits. I will keep this open for some days if anyone still encounters any related problem.
This is definitely something which would occur extremely rarely in specific situations, but then the results would be quite bad. There were some reports of damaged SD cards in Uzebox, this could be a reason of that happening.
Note that fixing it on individual units will require uploading a new bootloader since the bootloader also carries this flaw and so could trigger it even with a fixed game (as it always starts, only passes control over to the game).
In the normal kernel, the problem area is the I/O table in uzeboxCore.c (in the bootloader an identical table is in bootloaderCore.s).
PORTD contains the Chip Select for the SD card (on PD6). This pin is initialized as Input (by an io_set to DDRD), and without pull-up (by an io_set to PORTD). This leaves the pin floating unless the circuit contains a pull-up resistor, which could result in the card unintentionally becoming selected.
PORTB contains the SPI pins (SCK, MISO and MOSI), their direction is initialized as Output (io_set(DDRB,0xff)), including MISO. The port's value (by the SYNC_PORT definition) is set zero for this pin, so it puts a strong low drive on this line which should be driven by the selected SPI peripheral.
The SPI RAM's Chip Select is on PORTA, which is initialized with a weak pull-up, so hardware containing it at least shouldn't cause conflicts.
However the setup is still slightly dangerous especially on home-built Uzeboxes where external pull-ups might be omitted.