As my oven/stove broke I started analyzing the system in order to find and fix the error. Basically the residual-current-operated protective device “blew” when I switched on the oven – the cooktop worked just fine.
Side note: Searching the spare parts showed that Ignis, Bauknecht, Whirlpool and Philips are using the same parts – or that the same oven is sold under different brand names.
Disclaimer: be careful when working with devices that are usually connected to mains power. Definitely disconnected the device from mains power before trying to fix it or even measuring something – and also do make sure that there’s no power!
Gaining a basic understanding
The oven is connected to mains power using the three phase conductors (L1, L2, L3), the neutral conductor (N) and protection earth (PE).
There’s a lot of components inside the device which basically can be seen as resistors. To calculate the power converted to heat simply use the following formula (derived from Ohm’s law): P=U²/R where U=230 V (mains power in Europe).
There’s a lot of cables inside the oven, some components and several knobs/ rotary switches.
Those rotary switches work the following way: dependent on the position of the know some pins on the left side are connected with their direct opposite pins on the right side. Pins on the left and on the right side can be connected among each other so that combinations of connections can be made.
About the oven
The oven consists of the following main parts (besides cabling, etc.):
Rotary function selector switch
Fan on the back
Fan on the top
Temperature selection rotary switch/knob
Heating element on top (for upper heat; consisting of two separate loops)
Heating element on the bottom (for lower heat; single loop)
Thermistor, fuse or bi-metal (haven’t checked it yet)
The oven has a rotary function selector switch with 7 positions. Each of the positions may connect one or several out of the 7 internal switches (it’s a coincidence that the number of switch positions equals the number of internal switches).
I have identified the following functions for each internal switch:
1/P1: “enable” heating, lamp and fans (does not switch them on alone, another internal switch needs to be switched on for this!)
2/P2: switch on the heating element on the bottom (for the lower heat)
3/P3: switch on the outer loop of the heating element on the top (part of the upper heat; ~1600 W)
4/P4: switch on the inner loop of the heating element on the top (part of the upper heat; ~900 W)
5/P5: may “enable” the heating indicator, however, I think that this is strange…
6/P6: switch on the fan on the back side of the oven
7/P7: switch on the oven’s lamp and the fan on the top side of the oven
Which internal switches are closed/opened at which position of the rotary switch? You need to look it up in the table to get a deep understanding of that.
Pos. 0: everything is switched off
Pos. 1: switch on oven’s lamp and fan on the top
Pos. 2: switch on oven’s lamp, fan on the top, bottom heating element, outer loop of upper heating element and enable the heating indicator
Pos. 3: switch on oven’s lamp, fan on the top, bottom heating element, outer loop of upper heating element and switch on fan on the back
Pos. 4: switch on oven’s lamp, fan on the top, both loops of the upper heating element
Pos. 5: just like pos. 4 but additionally also the fan on the back
Pos. 6: switch on oven’s lamp and both fans (on top and on the back side), no heating element at all (used for defrosting)
Using the information gained during analysis lead me to the cause of the error: a broken heating element in the bottom of the oven. Fortunately, those are not very expensive so that I could order a new one.
“Kochplattenschalterblock”/”7-Takt-Schalter-Block” 4144723003 (cost of ~40 €)
Dependent on the position of the rotary switch there are different configurations of how current flows through the elements of the hot plates to generate heat. There’s a cable with 4 pins wired to each zone of the hot plates. Dependent on the position of the switch P1 and P2 are connected with different pins.
The following calculations are an example for the hot plates connected with the yellow connector (and assuming a mains voltage of 230 V):
Position 0: P1 not connected, P2 not connected
Position 1: P1 connected to pin 1, P2 connected to pin 2;
the current will be limited by a resistance of 108+108 Ohms (~245 W)
Position 2: P1 → pin 3, P2 → pin 4;
the current will be limited by a resistance of 108+64 Ohms (~308 W)
Position 3: P1 → pin 2, P2 → pin 4;
the current will be limited by a resistance of 108 Ohms (~490 W)
Position 4: P1 → pin 2, P2 → pin 3;
the current will be limited by a resistance of 64 Ohms (~827 W)
Position 5: P1 → pin 2, P2 → pins 3 and 4;
there are two paths for the current now; the old one through the 64 Ohms and another one through 108 Ohms (~827+429=1256 W)
Position 6: P1 → pins 1 and 2, P2 → pins 3 and 4
there are three current paths now; each limited by a resistance of 108/108/64 Ohms (~490+490+827=1807 W)
As I have reverse engineered the whole device, I can offer the following schematic (which may not bee free of errors):
I have also included order numbers within the schematic.
It was quite interesting to see the different components of an oven/ stove and how they work internally. Basically it’s not too complicated to fix such a device, when a component is broken. And you don’t need many tools: a multimeter is enough – or even a device only measuring resistance can be enough.
This post may be (or may be not) updated with further details in the future.
Long, long time ago I had flashed the bootloader of my Funduino UNO.
When listing my USB devices it would appear as follows:
Bus 002 Device 017: ID 03eb:2042 Atmel Corp. LUFA Keyboard Demo Application
I had flashed a firmware to get an alternative to the makeymakey board with my own shield (basically with high-imedance resistors only). So I could not flash the ATmega328P microcontroller (in the socket) via the serial interface which is usually provided via the USB of the ATmega16U2. And unfortunately I didn’t have the old shield available anymore and the controller was constantly putting out data on the HID keyboard device which was quite annoying!
Relevant info: “-vvvv” gives a very verbose mode. Let’s assume my AVRISP mkII is broken. How to proceed? I’ve still got a working Arduino Leonardo lying around – let’s try to use it as an ISP: ArduinoISP – https://www.arduino.cc/en/Tutorial/ArduinoISP
Before loading the ArduinoISP sketch and resetting the board:
Bus 002 Device 023: ID 2341:8036 Arduino SA Leonardo (CDC ACM, HID)
Bus 002 Device 024: ID 2341:0036 Arduino SA
The two Arduino board are connected with the following pins:
power supply 5V and GND from the programmer to the target Arduino
SPI interface (MOSI on target pin 11, MISO on target pin 12, CLK on target pin 13)
reset pin of the target Arduino with a controlling GPIO of the programmer Arduino
Checkout the following diagram:
If pins with the same numbers were connected with each other – like those SPI pins – wouldn’t this conflict? If MISO was connected to MISO and MOSI was connected to MOSI? Both controllers might drive the same line?
It probably would! I have stumbled across the logic in the ArduinoISP sketch and had to define:
[Comment: “Uncomment following line to use the old Uno style wiring (using pin 11, 12 and 13 instead of the SPI header) on Leonardo, Due…”]
Avrdude didn’t complain about any wrong signatures anymore. I used:
In a next step I compiled and downloaded the simple Blink example, that worked as well. Let’s try to unplug the Arduino Leonardo (the Arduino functioning as a programmer) and replug the USB connector to the Funduino/Arduino UNO. The LED still blinks after startup, however the UNO is still not available as a serial device to be programmed, but still the HID keyboard. The bootloader/firmware of the ATmega16U2 still needs to be flashed. The ATmega16U2 acts as a USB-serial bridge between the PC and the ATmega328P microcontroller.
Resetting the Arduino UNO connects the device in a different mode:
I have worked with files describing electronic schematics and PCB board layout. But so far I have never really worked with Gerber files myself. As I found out it’s not rocket science, it’s not complicated at all.
The Gerber format is used to describe monochrome vector images by an ordered stream of graphics objects. The format uses printable ASCII (7 bit) characters only.
The schematic and PCB design software EAGLE provides a job mechanism with the aid of which the creation of the output data for a board can be automated (CAM). This tool can be used to create Gerber files. The predefined job is called gerb274x.cam.
For a 2-layer PCB the standard process will lead to five Gerber files (where cmp stands for component side and sol for solder side):
Copper, component side (.cmp)
Copper, solder side (.sol)
Silk screen, component side (.plc)
Solder stop mask, component side (.stc)
Solder stop mask, solder side (.sts)
You might want to add (if your manufacturer allows you to have it:
Silk screen, solder side (.pls)
Additional steps: you may want to add a drill file, specified by the Excellon file format. That’s another job in Eagle called excellon.cam. The Excellon format (variant of the RS-274-C standard) is widely used to drive CNC drilling and routing machines in PCB manufacturing.
This will create the following two files:
Drill file (.drd)
Drill Station Info File (.dri)
The drill file is used by a drill program and includes sizes and locations of holes in the PCB.
To check my results I used the gerbv tool under Linux:
The memory of a NAND flash is organized in a hierarchy of:
The Hynix HY27UF084G2B consists of 4096 blocks. Each block of a NAND Flash consists of 64 pages. Each page consists of 4 sectors of data (512 Byte each) and 4 small sectors (16 Byte) of spare data, i.e. a single page consists of 2112 Byte where 2048 Bytes are data and 64 Bytes are spare. 2112 Byte blocks are also called “large block” opposed to “small blocks” of 528 Bytes (holding 512 Bytes of data and 16 Bytes of spare data).
Flash memory is read and written in pages and erased in blocks of data. Memory must be erased before it is written to! This is also true for single byte writes.
Content of the spare areas: those out of band (OOB) area store data for error detection (e.g. a checksum), correction coding (ECC, most algorithms are based on Hamming codes) and bad block markers (if ECC cannot handle the amount of errors anymore). But can also contain data for the logical/virtual organization (blocks, pages) of physical blocks and pages. The ECC is usually a vendor/model dependent algorithm.
Creating a flash dump
Know your chip
Sometimes the interface to update firmware (e.g. via JTAG or serial port) is not exposed or not easy to find. It may then be an option to take the NAND flash device from the printed circuit board. The desoldering process is followed by dumping the flash memory, sometimes referred to as “off-chip forensics” (used in security analysis and data recovery).
In a next step the device is taken and put into a NAND flash reader/writer. There are commercial tools, but they can also be built from some basic hardware. A popular choice is to build a serial/parallel to USB adapter*. The FTDI FT2232H (and a breakout board) is a good starting point as you can toggle various GPIO pins in “bit bang” mode via its USB interface (mostly used as dual-port USB/serial converter). There’s also a project about using an Arduino NAND flash reader (no focus on speed).
It’s also good to know the NAND flash memory chip’s parameters and pinout in advance. Those specifications can be read from the datasheet, if you can read the labels written on the IC package. It is possible that your flash complies with the Open NAND Flash Interface specifications.
Taking the Hynix HY27UF084G2B again as an example:
memory organization already mentioned above;
page organization: separate data and spare areas, i.e. main field with 4x 512 Byte of data comes first, followed by 4x 16 Bytes spare
timings can be read from the datasheet
x8 bus width I/O interface, i.e. IO0..IO7
nCE: chip enable
nWE: write enable
nRE: read enable
RnB: ready/busy indication
CLE: command latch enable
ALE: address latch enable
nWP: write protect
(8 + 7 = 15 pins needed)
capacitance between Vcc and Vss as a buffer: 0.1 uF
address cycle map: which address bit is latched when on the I/O interface?
the HY27UF084G2B has 5 cycles, i.e. 5 x 8 bit = 40 potential bits
512M addresses needed: log2(512M)=29, i.e. only 30 bits required (A29..A0) and 10 bits to be kept at a low logic level
definition of the device’s command set; some commands are single byte operations, others are composed of multiple bytes e.g.
READ1 (0x00 in 1st cycle, 0x30 in 2nd cycle)
READ ID (0x90 in 1st cycle)
The READ ID command is a good one to test if the connection with the flash can be established successfully and without causing a potentially high damage to the flash device. However, you should know what you do.
The ID to be read for my chip is: 0xAD 0xDC 0x10 0x95 0x54. Those bytes can be interpreted in the following way:
Manufacturer Code: 0xAD (=Hynix)
Device Identifier: 0xDC
Device Identifier Description: 0x10 = 0b00010000
Write Cache: not supported
Interleave program between multiple chips: not supported
(*Side note: our flash IC is a parallel flash, but a similar approach could be taken for an SPI flash as well, using an SPI to USB bridge.)
Building the hardware for a DIY NAND flash reader
wires & jumper wires
breakout board with the FTDI FT2232H (to read/write data from/to the NAND flash; communication with a host PC)
The pins of the TSOP-48 socket (being directly connected with NAND flash memory device) are wired with the pins of the FTDI FT2232H.
(Side note: the TSOP socket may also be used to get the NAND flash memory working in it’s embedded system environment and eavesdropping on how it is accessed with a logic analyzer – flash memory at which addresses and when, e.g. at boot.)
Using software with the DIY NAND flash reader
I will run my DIY NAND flash reader under a Linux operating system. Therefore tools which already work under Windows are not applicable here. But at least the source code of spritesmods.com ftdinandreader (Download) and Bjoern Kerler’s advancement NAND Reader FTDI can help here. I may start from scratch but also may re-use some source code.
First I got the source code and build files for libftdi. The build process and the dependencies for libftdi in turn (e.g. libusb-*-dev) are documented well in README and README.build. Afterwards I could run one of the examples coming with libftdi as I had a small breakout board with an FTDI 232RQ laying around.
Bus 002 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Dr. Tom Murphy (@tom7) wrote a paper about “compilers, bits and assembly” – it is about producing DOS-executable EXE file which contain the limited set of only the printable ASCII bytes. In principle, he explains which steps to be taken and some necessary tricks/workarounds when writing a C89 compiler to fulfil these requirements. You can also learn something about the x86 instruction set. Find the paper (20 pages with some ASCII art in it) here. And he also made an explanation video:
Carrie Anne Philbin (@MissPhilbin) has started a weekly series of YouTube videos about the basic inner workings of computers. Part #6 of the series explains the inner organization of an SRAM chip, provided with some nice visualizations:
The UART protocol (described in the datasheet) uses a packet of 10 Bytes sent each second. It contains two 16-bit values for both PM2.5 and PM10.
The blog article “Feinstaubmessung mit dem Raspberry Pi” [German] gives a good introduction of how to work on the raw data. It also provides an explanation of how to calculate the particulate matter measurement data in µg/m³ from the raw values. You can also find a Bash script on that site which can help as a “getting started” guide.
After some modifications you get two values per second (indoor test):
The sensor itself has a limited service lifetime of “up to 8000 hours” – which would translate to 333.3 days or not even a whole calendar year. To prolong the service lifetime it’s recommended to power down the sensor and use it in a discontinuous way.
The firmware update files can directly be downloaded from Ravensburger’s website. The file names for the German version are Update3202.upd (~10.8 MiB) and update.upd (~6.1 MiB).
The strings command can be run on those files to check for any insights into how the embedded system works or how updates are carried out. It would also be interesting to find out what is actually written to the NAND flash memory and possibly also other non-volatile memories.
List of NAND flash names (including the Hynix HY27UF084G2B with several others from Samsung, Hynix, Toshiba, Micron, ST and Intel)
Hints about the NTFL (NAND Flash Translation Layer)
Library/function names: FSLib (FS probably stands for filesystem), NandMtd, MtdLib (Mtd probably stands for “Memory Technology Device”), FatLib, MediaLib, Utl_*
“Serial trace is active!”
File system names: FAT32, FAT16, FAT12
List of German words: Apfel, Auto, Baum, …, Wort, Wurm, Zelt – What could they be used for?
Strings containing references to media files (“ID3x”, “RIFF”, “WAVEfm”)
Strings containing the word “battery”
Strings referring to possible SCSI data transfers
Firmware version strings at the end, e.g. “ANYKA_IDRAV_N0038” and “RAV_V0136”
C file names (e.g. “medium.c”)
“End of userware”, “This is userware”
Warning and error messages, probably also debug strings
Both firmware update files seem to contain RIFF wave files. As a first indicator the number of matches is counted:
Instead of using this reverse engineering approach – there is one version of the burntool the data contained in the .upd file can be read on import and is then stored in the config.txt file. For the specific Flash IC mentioned above the line in the configuration file is:
chip ID: 0x9510dcad (seems to be a little endian representation of the ID which can be read from the IC with the READ ID command,
i.e. 0xAD =Manufacturer Code for Hynix, 0xDC = Device Identifier,
0x10 0x95 = Device Details, 0x54 = Multiplane info is missing however)
Maybe we can find out something about the format of the firmware update files. As we know that the string of the flash device is stored in the .upd file let’s have a look for its location and the area around it within the file using the strings command with option -t (-td for decimal, -tx for hex):
The firmware update files pretty much start with a list of the supported flash devices.
The entries have a fixed width/spacing of 287 bytes (measured between the start of strings) in update.upd. The entries end with the string (NULL-terminated, up to 255 bytes), the other information (32 byte) can be found before it:
32-bit Chip ID (0x9510DCAD)
16-bit: page size: value is 0x0800 = 2048 Bytes (little endian)
16-bit: pages per block is 0x0040 = 64
16-bit: total block count is 0x1000 = 4096
16-bit: group block number[?] is 0x1000 = 4096
16-bit: plane block number[?] is 0x0800 =2048
8-bit: spare size is 0x40 = 64 Byte per page
8-bit: column address cycle is 0x02 = 2
8-bit: last column address cycle mask bit: 0x0F = 15
The format used by Update32.upd is slightly different: the width/spacing of each entry is 64 bytes:
It’s just a more dense representation saving some NULL bytes in the descriptor string. The string may now only take up to 32 bytes instead of 255.
About the burntool itself: BurnTool.exe (~1-2 MB): it is a PE32 executable (GUI) Intel 80386, for MS Windows. There’s different versions of the burntool available in the internet. Also found source code around the web for the burntool itself!
Which sections of the .upd files are transferred to the Tiptoi device?
How to build a valid config.txt configuration file?
Which sections include actual firmware code and in which instruction set?
Which addresses are used and where are the peripherals mapped?
What is the difference in the firmware update files for the different languages?