Firmware & Upgrade

Rockbox Utility will ask you to provide an original firmware from Sansa's forum. You may go to the manual download method to obtain this file.

Windows people can download and install Sansa Firmware Updater (available here). It checks for a new firmware version, downloads and will then install it on your player if mounted.

You may also manually download the firmware (available here) if you don't do Microsoft. Unzip the file and copy the firmware file to the root of the player, unmount it and then unplug the player to launch the upgrade process

Recovery mode

The i.MX233 chip has a usb recovery mode partly documented in the datasheet. The Fuze+ can be put in this mode by the following procedure:
* Turn off the device
* Push the volume up button
* While holding the volume up button down, plug in the USB cable
* The screen will stay black and the device will then register itself as a HID device: 066f:3780 (Sigmatel, Inc.) ROM Recovery

When in recovery mode, the device uses the BLTC protocol for which we do not have documentation. However the sbloader (utils/imxtools/sbtools/) tool is in the SVN is capable of uploading a firmware file in the SbFileFormat based on some reverse-engineering we did.

PCB Scans

Components

Flash memory: SanDiskSDIN4C2?-16G. This is a SanDisk iNAND eMMC I/F 4.3 with extended features. It is a standard eMMC flash although a datasheet for this precise chip (or for the 4.41 version of it) can be found on Google.

The OF has support for two kinds of LCD controllers. The LCDs should report ID code 9325 or 7783. The 9325 could match the ili9325 from ilitek and the 7783 could match st7783 from sitronix. The former has a datasheet available on the web and the second has a datasheet for st7781 which should be pretty close.

It uses the A4 revision of the STMP3780 family, not the A5 revision, which basically has an updated ROM that fixes some microSD issues and slow boot times. See: here. It is possible that there are Fuze+'s out there using the new revision, however it shouldn't make a difference to the ability to port Rockbox.

It looks like this Development Board uses a rebranded STMP378x chip. See here

The Atmel AT24C64C (see here) I2C EEPROM contains a bootloader, because it matches the requirements (address 0xA0) for the I2C boot mode mentioned in the i.MX233 document. I dumped its content and its mostly a stub except that it changes the boot mode to SSP2 (which is the internal eMMC).

Set on power off. Needed to do a "clean" power down. Exact use unknown.

B0P10

IN

Used by the OF to monitor SD change between boots. OF refers to it as "SD_CHANGE". Hardware sets this to one on SD removal. Cleared by a clean power down.

B0P20

ssp2_cmd

B0P24

ssp2_sck

B0P26

OUT

Touchpad Power

B0P27

IN

Touchpad ATTN line

B0P29

OUT

Tuner Power

B0P{30,31}

Touchpad I2C lines

B1P{00-17}

lcd_d{0-17}

B1P18

lcd_reset

B1P19

lcd_rs

B1P20

lcd_wr

B1P21

lcd_cs

B1P22

IN/OUT

Tuner I2C SCL

B1P23

lcd_enable

B1P24

IN/OUT

Tuner I2C SDA

B1P25

lcd_vsync

unused?

B1P{26,27}

duart_{rx,tx}

Debug uart pins

B1P28

OUT

Backlight control line

B1P29

OUT

eMMC Power / Chip Enable

B1P30

IN

Volume down button

B2P00

ssp1_cmd

B2P01

ssp1_det

SD detect

B2P0{2-5}

ssp1_d{0-3}

B2P06

ssp1_sck

B2P27

IN

tuner GPIO2 (SCT/RDS)

Mysteries

Here is a list of unsolved mysteries about the Fuze+

Freezing bootloader with very bright screen

After booting in USB bootloader mode and unplugged, boot process sometimes gets stuck with a very bright screen (usually at the rockbox logo). The workaround is simple: just hard reset and reboot without USB plugged. It seems related to the power subsystem not being properly configured when passing over to the main binary.

Touchpad crazyness

Sometimes the touchpad will go crazy and report wrong or false touches. The only way to recover is to shutdown and reboot. There is a way to reset the touchpad but without a way to detect that the touchpad is mad, this is useless.

Backlight flickering

Sometimes the backlight will flicker on every touchpad touch or just randomly. Experiments suggest that it happen when VDDIO is wrong set to 3V instead of 3.3V. The situation is further confusing because then VDDIO is configured for 3.3V but the LRADC reports 3V meaning that the hardware somehow doesn't keep manage to keep the good voltage.

Unknown ADC Channel

The Fuze+ OF monitors the LRADC channel 2 but the code is so intricate that I'm unable to determine its use. The code suggests that it is resistor divided from VDDIO. However, experiments haven't shown any value different from VDDIO yet, making it unlikely that it charging currennt, temprature or anything physical.
The channel readout can be found in the debug menu, under the third screen of HW info.

Malfunctioning internal storage

Some Fuze+ suffered from what looks like a hardware failure of the internal storage. Two situations have been encountered:

dead storage: the device won't boot except in recovery mode

read-only storage: the device will boot but all writes to the storage will be ignored (although reported as successfull)

It is not clear if it is related to Rockbox or not since some users suffered from it using the OF only.

If you suffer from such a problem there is a way to keep using your device by booting it from a SD card. See here

Troubleshooting

Broken recovery mode on linux

The recovery mode of the fuze+ (of the imx233 to be precise) is HID based but has a quirk: if doesn't like being send a GET_REPORT. On linux kernel versions up to somwhere between 3.2 and 3.7, a change was made to the usbhid driver which sends a GET_REPORT by default. A quirk was added for this particular device somewhere between 3.7 and 3.8. Consequently, if you a running a recent kernel but not the trunk, it will break your device. There are several ways to fix this problem. In all cases, unplug the device, apply the fix and replug your device.

Temporary fix: the proper way

If you only need to access the recovery mode once and don't want to both with config files, you will need to unload the usbhid driver and reload it with an option, like this (as root):

rmmod usbhid
modprobe usbhid quirks=0x066f:0x3780:0x0004

NOTE: unloading usbhid will kill any usb hid device connected (mostly mices and some keyboards), be sure you can enter text without usb !
NOTE: in some cases, you can get an error when trying to unload usbhid because some another module relies on it. You'll have to remove too. Example: