Cordless vacuum cleaner problem

Status
Not open for further replies.

It's OK thanks, no apologies are required - and I'm mega impressed by the quality of his drawings above.
 
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.
 
Last edited:
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.
 
rjenkinsgb said:
The firmware file is still on Yandex disc at the url in that last post, and downloadable!
Click to expand...
Indeed. That's what I was referring to earlier:
Buk said:
I have downloaded an .eep that I believe is taken from the eeprom on a good board.
Click to expand...

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} )
 
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..
 
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.
 
Last edited:
"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:

 
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.
 
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.
 
rjenkinsgb said:
The firmware file is still on Yandex disc at the url in that last post, and downloadable!
Click to expand...
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?
 
Buk said:
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?
Click to expand...

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?.
 
Decompile!
 
Buk said:
Decompile!
Click to expand...

????? 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.
 
 
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
 
Nigel Goodwin said:
And doesn't mention any micro-controllers!.
Click to expand...
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.
 
Status
Not open for further replies.

Similar threads

B
  • Question
Repairing Vacuum Fluorescent Display Driver on IRD 245
Replies
4
Views
3K
blowerman
B
E
  • Solved
Electric oil heater switch problem.
Replies
11
Views
2K
evi3
E
  • Question
LCD screen problem - BEKO MGF 20210 X microwave oven
Replies
6
Views
2K
Nigel Goodwin
  • Question
Samsung UN58TU7000 half screen color problem
Replies
2
Views
3K
Serge 125
  • Question
problem low light brightness display fonrtpanel glass.segment receiver istar
Replies
5
Views
4K
danadak
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…