[__fred__]

OK, so I managed to unbrick my device using the resistor method. Very easy actually, but it was a pain to take it out and put it back in (including the wiring harness), so I'll wait for my test unit to arrive before doing anymore work.

With the unit open I was able to get info on the used IC's:

For anyone interested. The video switching chip is an TW8836 with Intersil still on It (so must be from before 2017 although my unit was produced in October 2018).
The MCU processor is an STM32F105RB. This will probably get me going on the MCU firmware.

Other news: none of the wires in the wiring harness are connected to the ILL pin in the quad lock, so for sure all MCU versions get the light signals through CAN.

Final update: I used the incorrect API version number while applying haystack, so this is most likely why I bricked my unit. As soon as I have a test unit I will verify.

[CleM71]

Nice to know you fixed it.
Yeah the resistor itself is so tiny...
I've replaced it by a bigger one and added a switch to easily change the mode in case I brick it again
But yes, you'd better wait for your dedicated unit to continue your work

[__fred__]

Bingo: The MCU firmware starts with a nice interupt vector table with stack pointer and reset vector pointers that seem valid. Could be pretty easy to decode.

Nice, we have another hobby project ;-)

[nomorebigideas]

Originally Posted by __fred__

Bingo: The MCU firmware starts with a nice interupt vector table with stack pointer and reset vector pointers that seem valid. Could be pretty easy to decode.

Nice, we have another hobby project ;-)

@_FRED_ let me know when the unit arrives - it's actually for a BMW X3 F25, so is 8.8", but all the software / firmware should be the same. Sorry if I didn't explain that earlier. It's still 7.1.1 OS.

Perhaps when you're coding away, could you see if there's any way to change the ringtone of the unit? When connected to Bluetooth via a mobile device, the incoming ringtone is a horrendous early 00's Nokia tone... Would be amazing if this could be muted it changed!

[nomorebigideas]

Originally Posted by nomorebigideas

@_FRED_ let me know when the unit arrives - it's actually for a BMW X3 F25, so is 8.8", but all the software / firmware should be the same. Sorry if I didn't explain that earlier. It's still 7.1.1 OS.

Perhaps when you're coding away, could you see if there's any way to change the ringtone of the unit? When connected to Bluetooth via a mobile device, the incoming ringtone is a horrendous early 00's Nokia tone... Would be amazing if this could be muted it changed!

Also does anyone know if the BATT+, ACC and NEG / GROUND wires on the back of the unit supply power? I'm having a world of trouble finding an ACC power source for an aftermarket kick power tailgate sensor install.

[pipould]

Hi all,

I was following this topic since long time and decided to get a HU for my E84.

Version: Android 8.1, May 2019 Security Patch, 2GB+32GB Rom

Installation: Flawless, with the tools a bit of time all good, didn't have a since issue, didn't have to drill a single hole. USB are in glovebox and Aux output get through a panel corner.

Remarks:
- GPS Antenna installed under dash facing top on a AC tubing or fixation (dunno)
- GPS takes a while to catch up in the morning (maybe like 5 minutes while moving)
- Unit doesn't shutdown that easily, ie. After a 4 hrs stop it stills resume operations in 10-20 seconds
- Here maps works perfect
- Music player is a big sluggish with a 32GB USB drive full of music
- Audio quality via Android is better than original thanks to better equalizer or so (I have normal audio)
- Works perfect with a cellphone set as Hotspot
- Rear/Front sensors switch HU/Original working perfect


Overall I'm quite satisfied. I wanted it for long drives and it's going to answer this point perfectly

Regarding the tuning effort, I'm wondering how convenient it is to modify the .smali files and not try to get the .java's for convenience reasons ? I've been able to get to that point but all my effort in repacking / recompiling the app failed so far.

[NormanGonzalez]

Hello, guys.

I have a F30 with a 10,25 8.1Android, but I have very big problem, when I press the PDC bottom, this system doesnt work on the Android, but it does on the original computer...

the other question is how I could learn the keys in this last system? I see a place to do that called learning keys, but I dont know how it works..

thank you!

[pipould]

Originally Posted by NormanGonzalez

Hello, guys.

I have a F30 with a 10,25 8.1Android, but I have very big problem, when I press the PDC bottom, this system doesnt work on the Android, but it does on the original computer...

the other question is how I could learn the keys in this last system? I see a place to do that called learning keys, but I dont know how it works..

thank you!

On the E84 you've got different settings, either the switch to original system, or camera, or just sound

[NormanGonzalez]

Originally Posted by pipould

On the E84 you've got different settings, either the switch to original system, or camera, or just sound

what do you refer with E84?

Thank you very much!

[__fred__]

Originally Posted by nomorebigideas

@_FRED_ let me know when the unit arrives - it's actually for a BMW X3 F25, so is 8.8", but all the software / firmware should be the same. Sorry if I didn't explain that earlier. It's still 7.1.1 OS.

Perhaps when you're coding away, could you see if there's any way to change the ringtone of the unit? When connected to Bluetooth via a mobile device, the incoming ringtone is a horrendous early 00's Nokia tone... Would be amazing if this could be muted it changed!

Unit has not arrived yet. I will tell you when it has. I'll look at the ringtone when I've got time.

I've also made notes on unassigned steering wheel keycodes on the CAN bus. This might make it possible to reassign functions. Can key codes are:

17 = Telephone
25 = Up
26 = Down
4 = right
5 = Pushed in

[__fred__]

Originally Posted by nomorebigideas

Also does anyone know if the BATT+, ACC and NEG / GROUND wires on the back of the unit supply power? I'm having a world of trouble finding an ACC power source for an aftermarket kick power tailgate sensor install.

Why would you need power near the radio for that?
Anyway, I don't know how much milliamps you need, but ACC is powered with the ignition key, does not seem logical to power a tailgate sensor from to open the boot. You could use BAT++, it's permanently powered, but it could drain the battery.

I think the most logical option is to lookup schematics and choose a circuit that is powered off when the car goes to sleep and powered back on when you unlock the doors.

[pipould]

Originally Posted by NormanGonzalez

what do you refer with E84?

Thank you very much!

In settings you can change the unit behavior when parking sensors/camera kicks in.

[pipould]

Originally Posted by __fred__

Unit has not arrived yet. I will tell you when it has. I'll look at the ringtone when I've got time.

I've also made notes on unassigned steering wheel keycodes on the CAN bus. This might make it possible to reassign functions. Can key codes are:

17 = Telephone
25 = Up
26 = Down
4 = right
5 = Pushed in

I have the feeling that part form up/down and +/- buttons on steering wheel, the phone functions and aux switch are messing up with the original system behavior, correct ?

Another point, what's the unit microphone is useful for ? When I use the phone function the original system kicks in as-well in the background :/

[NormanGonzalez]

Originally Posted by pipould

In settings you can change the unit behavior when parking sensors/camera kicks in.

What part of setting?

Thank you so much for your helping.

[nomorebigideas]

Originally Posted by __fred__

Why would you need power near the radio for that?
Anyway, I don't know how much milliamps you need, but ACC is powered with the ignition key, does not seem logical to power a tailgate sensor from to open the boot. You could use BAT++, it's permanently powered, but it could drain the battery.

I think the most logical option is to lookup schematics and choose a circuit that is powered off when the car goes to sleep and powered back on when you unlock the doors.

Long and boring story... but essentially, the kick sensor for the aftermarket powerlift boot / tailgate I had installed wasn't working - at all.

I'd connected the 12v BATT line (yellow) to an always on 15a fuse, the GND (black) line to the brown wire point in the rear fuse box (this is apparently the ground wire colour for the X3 F25) and the ACC (red) line to a 15a switched live fuse (voltage drops after 10-15 minutes when the doors are locked).

The Chinese manufacturer told me to reconnect GND (as per image) and disconnect the ACC line. Now it works, but they insist I need to connect the ACC line somewhere.

According to them, the sensor isn't always consuming power - it only draws current when it senses motion... but I'm not sure how this can be the case!

EDIT: BTW, both power lines have inline fuses, hence no fuse tap insert in the picture

[__fred__]

Some updates on the MCU:
I've created a processor configuration for the STM32 in IDA Pro so that all registers and memory area's are documented:

https://github.com/jspuij/LoadProcConfig

I also started mapping interrupt vectors in IDA pro, but I've hit a snag: A couple of them are most certainly correct (e.g. the reset vector and nmi vectors). Others point into data and lead to IDA complaining about incorrect instructions and addresses. Most logical conclusion would be that the mcuupdate.bin file is not stored in memory contiguously. There are probably empty regions that are not in the bin file, but exist in flash. So I'll either have to analyze the flash update procedure in one of the APK files, or I'll try and dump the flash memory through JTAG once I have a test unit.

Whether an interrupt is assigned or not seems to make sense: e.g. Only CAN rx (read) is assigned, not TX. ADC1 is assigned and TIM2,3,4 (the first three general use timers).

For now some pretty pictures from IDA:





Update: I've found an interesting drawing routine, that has screen coordinates and function calls for drawing of all layers. Now the video chip (TW8836) supports 8 layers and the resolution is 1280 * 480. It also lists a few memory addresses (likely image data) that are past the end of the flash file. I've come to the conclusion that the flash image most likely is contiguous, but starts at a higher offset because the bootloader code is not included in the flashfile, as it is not overwritten. If i'm able to match the relative differences of the memory addresses to locations inside the flash image, I will be able to calculate the exact offset for the flash file.



Update 2: And the calculated offset is 0x08002800, which makes complete sense. The bootloader is 10K. The image actually starts with the reset routine after the IVT. Fault interrupts lead to branch functions to itself and the CAN RX interrupt leads to a CAN read function. Happy!

[dice66]

^^^
I guess some beers will need to be sent to your location
Awesome job, i tried to disassemble the mcu, but my knowledge in this area is almost non-existent.

Btw, i just got another update from the seller with the ID7 UI for Android 8.1

[therick3]

Originally Posted by dice66

Btw, i just got another update from the seller with the ID7 UI for Android 8.1

Update as in a new update file? Any other improvements or changes? My seller does not respond anymore.

[__fred__]

nomorebigideas the test unit arrived. Thanks! It’s cic which makes it more interesting as mine is CCC.

[__fred__]

So I found the dimming routine. It's at 080047AC. This means that I will be able to patch the MCU to disable auto-dimming. Pseudocode:

signed int __fastcall set_destination_brightness_from_lookup(char a1)
{
  signed int result; // r0

  if ( byte_20000CC9 == 1 )
  {
    byte_20000D50 = a1;
    result = max_at_0x84((unsigned __int8)brightn_lookup[(unsigned __int8)byte_20000854 / 2]);
  }
  else
  {
    result = max_at_0x84((unsigned __int8)brightn_lookup[(unsigned __int8)byte_20000854]);
  }
  byte_20000855 = result;
  return result;
}

The source value (between 0 and 100) is converted to a destination value using a lookup table. When in night mode, the source value is divided by 2 and used as index in the lookup table, effectively halving brightness.

It's late, I'm off to bed. But I can patch this.

[koutsouk]

Originally Posted by __fred__

So I found the dimming routine. It's at 080047AC. This means that I will be able to patch the MCU to disable auto-dimming. Pseudocode:

signed int __fastcall set_destination_brightness_from_lookup(char a1)
{
  signed int result; // r0

  if ( byte_20000CC9 == 1 )
  {
    byte_20000D50 = a1;
    result = max_at_0x84((unsigned __int8)brightn_lookup[(unsigned __int8)byte_20000854 / 2]);
  }
  else
  {
    result = max_at_0x84((unsigned __int8)brightn_lookup[(unsigned __int8)byte_20000854]);
  }
  byte_20000855 = result;
  return result;
}

The source value (between 0 and 100) is converted to a destination value using a lookup table. When in night mode, the source value is divided by 2 and used as index in the lookup table, effectively halving brightness.

It's late, I'm off to bed. But I can patch this.

If you look some pages back there is a member that shared an MCU file that actually eliminated the dimming issue.
His seller gave him the file.
I tried to install it but I couldn’t manage to do it.
Have a look and compare your file and his.

[__fred__]

Originally Posted by koutsouk

If you look some pages back there is a member that shared an MCU file that actually eliminated the dimming issue.
His seller gave him the file.
I tried to install it but I couldn’t manage to do it.
Have a look and compare your file and his.

Crap, i thought i had read the entire thread. And you’re only telling me after I’ve spend all this time reverse engineering it.

Well, i’ll compare and i can probably patch the cic and nbt variants too, so it was still useful.