Gigaset C430 Hacking » History » Revision 9
Gigaset C430 Hacking¶
- Table of contents
- Gigaset C430 Hacking
The C430HX/A phones use a Dialog/Renesas SC14441 SoC, which is a fully integrated DECT handset IC, with all peripherals built in.
The firmware is stored on an external Quad-SPI flash chip (MX25U1635E), 2 MByte.
The CPU inside the SC14441 is a CompactRISC CR16c plus-architecture.
The firmware can be modded by unsoldering the SPI flash chip and flashing it in an external programmer (like a MiniPro TL866):
Be careful when trying to flash the SPI flash in-circuit! The phone runs at 1.8V I/O voltage! Do not apply 3.3V to any parts of the system externally!
The SPI flash IC is being accessed at 82.944MHz, using Quad-SPI.
Trying to run jumper wires from the SOIC footprint out to an external socket can be accomplished, but needs to be done very carefully, ideally with shielded wires, kept as short as possible. Even with a pretty reasonable setup, the phone will be unstable in this configuration.
It might be possible to lower the SPI clock frequency to a more reasonable value somehow.
Not much info is available about the SC14441 (except for a single page overview), but a datasheet for the similar SC14480 SoC is floating around online.
The SC14480 has many of the same registers and peripherals and the register maps are highly useful for looking at the SC14441/C430 firmware.
Gigaset also offers a GPL download .tar.gz for another product from their DECT lineup for one of their DECT base stations, which is running GPL software.
This tarball contains a full GNU toolchain and a bunch of other interesting things: https://cms.gigaset.com/opensource/GigasetElements/gigaset_elements_bl26_opensource.tar.gz
Ghidra can decompile the firmware image for the phones with the cr16c architecture.
You'll need to map the flash memory at 0xF0000 and some volatile peripheral registers at 0xFF4000 - 0xFFC00.
Sitronix ST7735 - 262K Color Single-Chip TFT Controller/Driver
Ringtones on the C430 phones are standard MIDI files, being played by a software MIDI synthesizer implementation.
This implementation seems to be called "Sitel Midi Player", but no further info about that player/synth is publicly available.
A video showing the custom ringtones is available on YouTube:
The MIDI files are embedded into the firmware directly and can be found by looking for the MIDI header magic "MThd" (ascii).
From there the amount of tracks and then their length in bytes can be determined by looking at the MIDI track headers.
This script will look at a binary dump and extract any MIDI files (this script is not limited to Gigaset phones, useful in general):
Running that script will result in a folder full of MIDI files like this:
[gigaset-c430-modding]$ file * extract-1662195.mid: Standard MIDI data (format 0) using 1 track at 1/480 extract-1662318.mid: Standard MIDI data (format 1) using 1 track at 1/480 extract-1662352.mid: Standard MIDI data (format 0) using 1 track at 1/480 extract-1662462.mid: Standard MIDI data (format 1) using 1 track at 1/480 extract-1662510.mid: Standard MIDI data (format 1) using 1 track at 1/240 [...]
The number in the filename is the offset of the MIDI file in the dump, in decimal notation.
As MIDI files are read from the start and contain their own length information, these files can be replaced by files that are the exact same length or shorter.
When trying to replace a ringtone, find a suitable stock ringtone and just replace the bytes starting at the same offset with your desired .mid file.
Take great care not to overwrite any other memory content (by overstepping the boundaries of the stock MIDI files, etc.), as this will lead to memory corruption and crashes.
An example shell script for modding 6 custom ringtones into the firmware can be found here:
This script also uses dd to patch the strings of the ringtone names. When doing this, ensure you don't overwrite the \0 null terminator, otherwise you'll end up with memory corruption again.
Creating/editing MIDI files to fit onto the phone can be done with a free/open tool like "Rosegarden". The exported MIDI files seem to be very compatible with the Sitel player.
NiMH battery charge configuration¶
By default, the C430 phones will not treat the NiMH batteries very carefully. When sitting in the charging cradle for a long time, the batteries will be hot and won't last a very long time until they need to be replaced.
Both charging current and end-of-charge voltage are controlled by the SoC itself. The stock firmware will set no limit for the charge current and a end-of-charge voltage of 3.4V (1.7V per cell).
This is out-of-spec for many NiMH cells and for casual desktop operation, a much lower voltage and current limit might be desirable to keep the cells alive longer.
WARNING! This change is not well tested! It might cause your cells to explode, catch on fire, etc.!
Do NOT apply this mod on your daily driver phone without keeping a close eye on the batteries!
If you do, please report back. The author has only ever bench-tested these mods!
In the stock firmware, the BAT_CTRL2_REG (0xFF4814) will get written in 2 places:
0011d508 b0 5a 62 08 MOVW $0x862,R0 SOC_TEST2 0 = Normal operation. SOC_TEST1 0 = Normal operation. SOC_CAL 0 = Normal operation of the state-of-charge counter SOC_ON 1 = State Of Charge counter is enabled. CHARGE_CUR 000 = no current limit, Hysteresis mode enabled NTC_DISABLE 1 = Charger NTC protection disable. CHARGE_ON 1 = Charger enabled CHARGE_LEVEL = 00010 // 3.4V 001157e0 b2 22 ff f8 ANDW $0xf8ff,R2 CHARGE_CUR to 000 = no current limit
(offsets are including the 0xF0000 flash offset)
Changing this as follows:
0011d508 b0 5a 60 09 MOVW $0x960,R0 CHARGE_CUR 001 = 65 mA CHARGE_LEVEL = 00000 // 3.0V 001157e0 b2 22 ff ff ANDW $0xffff,R2 don't touch CHARGE_CUR register
should limit the charging current to 65mA and the end-of-charge voltage to 3.0V (1.5V per cell).
In testing, it changed the current from ~430mA to ~100mA, which is much more reasonable (will also 4x the charging time, but that's acceptable for home-use):
The firmware contains a bunch of images of fish, which are being used as a (optional) screensaver.
It would be very nice to be able to replace these images with custom ones.
Unfortunately, the encoding and location of those images in the firmware is currently unknown.