Cordless vacuum cleaner problem

[Nigel Goodwin]

Just a simple message/thought from a "fanboy". Don't you think you owe Nigel a public apology? He was right and you were wrong after all. And calling me a "fanboy" when you don't know our history is strange, we have had our battles both here and at AAC, but I do try to respect those that deserve respect. something you don't deserve.

It's OK thanks, no apologies are required - and I'm mega impressed by the quality of his drawings above.

 

[rjenkinsgb]

and I'm mega impressed by the quality of his drawings

+1 on that - Buk's CAD work has always amazed me, he seems to be able to produce a 3D CAD model quicker than I can do a back-of-a-beermat grade pencil rough!

 

[shortbus=]

It's OK thanks, no apologies are required

Well if it's OK with you I won't push. But when a member does like he has in open forum, complaining that he is being picked on because he is the one causing problems......

 

[Buk]

I've read:

Amongst many others, whereby Bosch program their microcontrollers to hard fail after even transient anomalies are detected. In correspondance with one of these guys, his friend at the Bosch service centre claimed that at least a 1/3rd of all Athlet warranty claims are resolved by re-initialising the eeprom in the µCPU.

 

[rjenkinsgb]

The firmware file is still on Yandex disc at the url in that last post, and downloadable!

Yandex

Finds everything

disk.yandex.com

I've give it a try, using those instructions.

 

[Buk]

The firmware file is still on Yandex disc at the url in that last post, and downloadable!

Indeed. That's what I was referring to earlier:

I have downloaded an .eep that I believe is taken from the eeprom on a good board.

But to use it means obtaining a USBasp or similar, soldering 6 wires to the board that has test pins smaller than can I see with my naked eyes, without screwing anything else on the board up; downloading, installing and learning to use software to drive it.

The hardware is cheap enough, but everything thereafter is a royal pain.

I was all up for checking out the eeprom when I thought that this unused black plug was the interface connector:

BUt I've still yet to find two of the six tps that I would need to connect to. I'm beginning to suspect they are under some of the goop that is liberally spread across the board:

Something like this is looking more and more value for money! (It probably sucks, but not big time. {groan} )

 

[rjenkinsgb]

If you want a replacement in a similar style, go with a Dyson - expensive, but if it goes wrong out of warranty within around ten years, they will send someone to do an on-the-spot repair and refurbishment for a fixed price.

Or for a handheld only one, the 12V version of a Black & Decker dustbuster is good; I've had one of those for many years, I use if for everything from cleaning out computers to picking up drill swarf and is still works like new..

 

[Buk]

Turns out that the 4 pin plug on the board is some form of IO connector. I've traced 3 of the 4 pins on the plug, to pins on the Mega328p:

1. 328 pins 3/5/21: GND
2. Appears to unconnected to any of the 328 pins, or the BMS chip pins or any of the 60 test pins that are accessible.
3. 328 pin 30: Labelled (in the pinout) as RDX
4. 328 pin 31: Labelled as TDX

According to the ATMega328P datasheet, in addition to the 4-pin (+VCC & GND) "Master/slave SPI serial interface" that DeD used above,
which uses these 328 pins

• TP2 ............................................................... 328 pin 4/6 ............................... VCC
• TP37 ............................................................ 328 pin 3 ................................... GND
• TP38 ............................................................ 328 pin 16 ................................ MISO
• TP39 ............................................................ 328 pin 15 ................................ MOSI
• TP40 ............................................................ 328 pin 29 ................................ RESET
• TP41 ............................................................ 328 pin 17 ................................ SCK

there is a "Byte-oriented 2-wire serial interface (Phillips I2C compatible)". The two wires of this Two Wire Interface (TWI) are described as

• SCL ............................... 2-wire serial interface clock on pin 28
• SDA ............................. 2-wire serial interface clock on pin 27

Its not clear to me if this interface could be used as an alternative for accessing/re-writing the eeprom?

Searching for RDX (not to be confused with RDx) and TDX finds no reference at all other than in the non-searchable pinout diagram. However, after wading through the DS, it seems clear that these 2 pins are used as part of a 3rd serial interface, a programable USART; but how Bosch have configured this (syncronous/asyncronous/baud/bits/parity etc.) and what they use it for is -- as the manuals used to say -- undocumented.

Although I have now located all 6 TPs that DeD used, I'd have been much more comfortable attempting a connection to the board if I could have use this plug.

Are there any kind of plug/pin that could be (semi) permanently connected to the test points to simplify connecting to the SPI interface? As I am quite sure that if I decide to attempt this -- why not, the damn thing is dead if I do not -- then I will certainly need to connect multiple times.

 

[rjenkinsgb]

"Pogo pins", if you can create a pattern on a bit of blank PCB or similar.

Pogo Pins for sale | eBay

Find great deals on eBay for Pogo Pins. Shop with confidence.

www.ebay.co.uk

You can get various diameters & with either cup ends to fit PCB pins / leads, or pointed ends to connect to PCB pads.

These are some in a test rig for a control module we make:

 

[Buk]

These are some in a test rig for a control module we make:

What holds it in place?

 

[rjenkinsgb]

Finger pressure on that one - it's a 24V unit so nothing dangerous, and the test only takes a few seconds.

On some other rigs, we have studs for the board mounting holes to fit over and plastic latches that hold the board down for the duration of the test sequence.

 

[Buk]

It just this minute struck me that there are only two wire connecting to the motor. Looking closely, I can see that the coils are in the rotor. Thus a brushed DC motor.

Therefore I can simply remove the entire Bosch circuit board and replace it with a 7S BMS and and a solid state relay or similar to bypass all the Bosch planned obsolescence crap.

Cheaper, simpler and more certain than trying to restore the eeprom(s) to factory defaults.

 

[Buk]

The firmware file is still on Yandex disc at the url in that last post, and downloadable!

rj,

There are two files in that zip. One for the eeprom and one for the flash memory.
What are the chances of decompiling them well enough to understand how the Bosch code functions?

 

[Nigel Goodwin]

rj,

There are two files in that zip. One for the eeprom and one for the flash memory.
What are the chances of decompiling them well enough to understand how the Bosch code functions?

You can't 'de-compile' you can only 'dis-assemble' - as long as the original code was written in assembler then that's perfectly fine, and the dis-assembled code should re-assemble to give exactly the same machine code, and should also be easy to understand and modify. However, if it was written in a high level language (such as C) then the resultant machine code is absolutely horrible, and it's difficult to modify it or understand what it's doing.

I've done it a LOT over the years, and it's mostly far quicker and easier to write your own code from scratch. If you want to try it though?, I would suggest trying to break it in to separate sections, and add LOT'S of comments as you do. Then, before you try and modify it, make sure your (now well commented) code assembles back to exactly the same file as the original (to ensure you haven't broken it on some way).

External EEPROM is usually used for data storage, and not program code, so is probably not an issue?.

 

[Buk]

For AVR-C programming, there are many compilers available in the market. Many are commercial but they have evaluation version available for download. Below is a list of the most common and links to download and more information. The compiler selection is user's choice.

1) MPLAB XC8 compiler: This is a free compiler available for Windows, Linux, Mac OS. For more information and download link: MPLAB XC8 compiler

2) AVR-GCC, GNU Project: This is a free C compiler for Windows and Linux. For more information and download links please see the AVR-GCC and the Toolchains for AVR site.

3) IAR: EWAVR Commercial C compiler with high code density.
For more information and download of evaluation version: IAR

4) Rowley Associates: Crossworks for AVR. High code density. Compiler and a debugger with support for both JTAGICE and JTAGICE mkII. For more information: Rowley

5) ImageCraft Embedded Systems: Imagecraft ICCAVR: Commercial C compiler. For more information and download of evaluation version: Imagecraft

6) HP InfoTech: CodeVisionAVR: Commercial C compiler. For more information and download of evaluation version: CodeVision AVR

Decompile!

 

[Nigel Goodwin]

Decompile!

????? there's no mention of decompiler in your post?, as I could see! - however, as I said, you can't decompile machine code to C etc. as nothing of it exists in the machine code, so there's no way to recover it.

 

[Buk]

Decompiler reads program binaries, decompiles them, infers data types, and emits structured C source code. Designed with a pluggable architecture, it currently has:
- support for x86, 68k, PowerPC processors (partial support for Arm, Mips, Sparc, Z80, m6502, PDP-11)
- support for EXE, Elf, AmigaOS Hunk executable formats
- support for MS-DOS, Win32, U*ix, AmigaOS (partial for C64, ZX-81)

Decompiler comes with a GUI and a command-line interface.

 

[Nigel Goodwin]

And doesn't mention any micro-controllers!. It also mentions computers that don't even have C compilers?.

If (and it's a big 'if') the debugging information is available, then it's a lot more possible (as it contains much more details to try and recreate the source code).

However, considering it's just a simple vacuum cleaner you could have long since written your own code

 

[rjenkinsgb]

And doesn't mention any micro-controllers!.

If you go to the source repository, it does include support - at some level - for quite a few MCUs; it's just the commonly shared binaries that seem to be x86 only - or is that even just the system they are built for?

Supported binaries

Reko is a binary decompiler. Contribute to uxmal/reko development by creating an account on GitHub.

github.com

It does look interesting, though I do rather doubt its C source recreation will do much on programs created with non stack-based compilers; the size and usage of the stack data could be how it tries to recreate data structures, but small memory devices don't use that method of passing data or structures.

 

[Nigel Goodwin]

If you go to the source repository, it does include support - at some level - for quite a few MCUs; it's just the commonly shared binaries that seem to be x86 only - or is that even just the system they are built for?

Supported binaries

Reko is a binary decompiler. Contribute to uxmal/reko development by creating an account on GitHub.

github.com

It does look interesting, though I do rather doubt its C source recreation will do much on programs created with non stack-based compilers; the size and usage of the stack data could be how it tries to recreate data structures, but small memory devices don't use that method of passing data or structures.

I was under the impression that PIC C compilers were stack based? (and presumably AVR ones?), using a software stack in RAM. Something I seem to remember been discussed on the PicList LONG ago - but I could be entirely mistaken?.

Anyhow, if buk has the machine code he just needs to give it a try and see what happens.