In my last post, I talked about how the MEG 1.1 EEPROM stores critical information like VIN numbers, engine models, immobilizer programming, and SCN coding that determines which maps the ECU uses.
What I didn’t mention is how difficult it’s been to actually see and understand all this data properly. Sure, you can read the EEPROM with the right tools, but interpreting those 256 bytes of hex data? That’s where things get tricky.
The Problem with Existing Tools
Most of the EEPROM analysis tools floating around the Smart community are incomplete fragments – usually old PHP scripts from forums that only decode bits and pieces. You might see the VIN, maybe some basic immobilizer data, but huge chunks of the EEPROM remain mysterious.
This became a real problem for me. When diagnosing ECU issues, swapping units between cars, or understanding why a particular remap wasn’t working properly, I needed to see everything stored in that little 24C02 chip.
I have also tried to avoid spending large sums of money on proprietary or cracked software which still may only give me part of the answers.
What’s Actually Stored in There?
After months of reverse engineering work (with plenty of help from the usual suspects – you know who you are!), I’ve mapped out most of the MEG 1.1 EEPROM structure. Here’s what Smart is actually storing in those 256 bytes:
Vehicle Identity & Configuration
- 0x35-0x37: Model code (452 = Roadster, 450 = Fortwo)
- 0x38-0x3A: Engine variant (434 = 61kw, 437 = 74kw Brabus, etc.)
- 0x3B: Steering configuration (LHD/RHD)
- 0x32-0x42: Complete VIN storage
- 0x0A-0x19: SCN ID code
The SCN Coding Mystery Solved (Partially!)
Remember how I mentioned SCN coding determines which maps the ECU uses? The actual coding lives at 0x05-0x06 and it’s far more detailed than anyone realized.
These two bytes contain 16 individual bits that control everything. I’ve managed to identify what some of them do:
- SCN5 Bit 6: Climate control presence
- SCN5 Bit 7: SB2 upgrade flag (the magic bit for Brabus maps!)
- SCN5 Bit 8: Roadster vs Fortwo identification
- SCN6 Bit 4: 45kW variant
- SCN6 Bit 5: 61kW variant
- SCN6 Bit 7: 74kW Brabus variant
But here’s the thing – many of the SCN control bits are still unknown. There are bits that clearly do something (they change between different ECU configurations), but I haven’t been able to figure out what they control yet.
This explains exactly how the ECU knows which internal maps to reference from the same FLASH file, but there’s clearly more functionality hidden in those unknown bits.
Immobilizer & Security Data
- 0x52: Key counter (immobilizer status)
- 0x2A-0x30: 7-byte immobilizer coding sequence
- 0xB4-0xB7: Immobilizer data blocks
- 0xA4-0xA5: Key programming data
Engine Management & Adaptations
- 0x5B: MIL status (check engine light)
- 0x5E-0x5F: Knock sensor reference values
- 0xA0-0xA1: Lambda sensor zero point
- 0x6C-0x6D: Odometer reading
Clutch & Gearbox Learning
- 0x9A-0x9B: Clutch protection class 1
- 0x9C-0x9D: Clutch protection class 2
- 0x9E-0x9F: Clutch protection class 3
- 0xA2-0xA3: Time spent in clutch protection mode
- 0xA6-0xA7: Clutch slip point learning
- 0xB0-0xB1: Disengaged position values
ECU History & Diagnostics
- 0xF2: Flash write counter (how many times it’s been remapped)
- 0xED: Flash type indicator (original sC vs tuning files)
- 0xE2-0xEC: Error byte range
- 0xF0-0xF1: Flash CRC verification
Building the Complete Decoder
Rather than keeping this knowledge locked away, I’ve built a proper Python tool with a clean GUI that decodes every single byte. This tool is provided here for free and I appreciate it if anyone who shows any use from this or has any input about what it does to please get in touch.
The SB2 Connection
Remember how I explained that SB2 maps have built-in protection? Now we can see exactly how it works. The ECU checks SCN5 Bit 7 to see if SB2 has been applied. If the FLASH contains SB2 maps but this bit isn’t set, limp mode kicks in within minutes.
This is why proper SCN coding (not just map flashing) is essential for SB2 conversions. The EEPROM and FLASH must match, or the protection system activates.
Update, I have successfully managed to make a modified SB2 map file which incorporates all the SB2 changes to the 371568 original map. This is the newest map file that Smart released and the only one which has faster gear changes. Please message me if you want a copy, all I ask is a donation for my time.
Still Much to Learn
Despite mapping out the complete EEPROM structure, there’s still a lot we don’t understand about these MEG 1.1 ECUs. The reverse engineering work has been like peeling back layers of an onion – every answer reveals new questions.
Some areas that need more investigation:
- Unknown SCN control bits – several bits change between configurations but their function is still mystery
- Adaptation algorithms – how exactly does the ECU learn and store clutch behavior?
- Inter-module communication – how does the MEG talk to the SAM and other modules?
- Hidden diagnostic functions – what other capabilities are buried in the firmware?
If anyone in the Smart community has additional knowledge about MEG 1.1 internals, SCN coding functions, or has discovered other interesting behaviors, please get in touch!
The more we understand these ECUs collectively, the better we can maintain, diagnose, and improve our cars. I’m always keen to collaborate and share knowledge with fellow Smart enthusiasts who are pushing the boundaries of what’s possible.
Looking Forward
More technical posts coming soon, including some exciting developments in gearbox control that build on this EEPROM knowledge…
Big thanks again to Mike Bailey at 223D Developmental and Andrew at Smart Automotive for their ongoing collaboration and pushing the boundaries of what’s possible with these brilliant little engines.
EEprom Decoder:
https://drive.google.com/file/d/1KGevWu-_O8_Ib1LeLYanKZSAPyb6HMDQ/view?usp=sharing
Tom
South Australia
WhatsApp: +61 401 723 903