cross-posted from: lemmy.dbzer0.com/post/38015770
A washing machine is trapped in a fault state even though all the components function (AFAICT). The controller board has two ports:
- ISP (to attach an ISP programmer to flash new software)
- USART (4-pin serial port: 0v, TX, RX, 5v)
I’m guessing the ISP port is useless without whatever proprietary software is needed. But what can the USART do for me? Can that be used to obtain the error code and clear it, or reset the board to the factory state? Has anyone done that, without documentation?
j4k3@lemmy.world 5 days ago
UART is often used for debug and programming, but there is no telling what it is running from this info. What is the processor? That info might recruit more help
diyrebel@lemmy.dbzer0.com 5 days ago
The MCU is an ATmega32L, which seems to be well documented. I was able to fetch a 300+ page document and a 12 page overview of the specs.
j4k3@lemmy.world 5 days ago
That is a microcontroller. I don’t have a lot of experience with hacking around with commercial products like this. It is not capable of running something like embedded Linux or a standard real time operating system. It could in theory be running Arduino, but probably not with the ISP connector. It was likely developed with the Microchip toolchain for ISP support. In this instance, the serial port is likely used for feedback only and not some interactive like interface. There may be some functionality programmed or the port may have been disabled after it was used in the jig that did the initial programming and tests.
Most of the info you will find about using UART to hack around is related to embedded Linux where UART is a full terminal interface. Devices capable of running embedded Linux are the next level above something like an ESP32 microcontroller.
The datasheet for the ATMega32L is not really relevant to you unless you want to rebuild the entire software stack from scratch. Reverse engineering and rebuilding is a major project even for a pro dev.
The manufacturer as you perceive a brand is likely just a logistics and label maker with little to no relevance to your actual device. The components PR entire machine were likely out sourced and contract manufactured. In the world of contract manufactured goods, the software is usually just a checklist of features. As soon as the checklist is complete and verified, the dev gets paid and is never seen again. If the company wants something more or something changed it will cost a fortune for the old dev to return or a new one to read-in to the code and make changes or just start over. This kind of thing might happen when versioning is required because some part is not available or something like that during production runs.
Each run is like a one time thing. Some capital is put together and parts are sourced, then the contractor makes like 5k of the thing over the course of 2 weeks. These go in shipping containers around the world with whatever brand stickers applied. When each run is done, the software and any unique tooling are consumables to the whole affair and not something anyone cares about or keeps like a real asset of value. It is probably archived in several private databases on various employee’s computers, but these are not connected in any way to aid or support your needs. It is in the best interest of the company to never give out this info.
Also getting the whole microcontroller toolchain working is a major pain in the ass. That large datasheet is because a microcontroller is a whole computer all integrated into a single chip. It is just a very simple type of computer. You need to understand all of the peripheral parts of computing to really make sense of it in practice. It is not just a microprocessor.
Embedded Linux means that there is a kernel and user space abstraction layer that makes the unique hardware irrelevant and abstracted away. Without this abstraction layer, you need to know and understand that actual hardware assembly, or use a language like C and a compiler for the actual hardware. This is the level you are facing.