Hacking the GD32 based ‘Autool X50 OBD2 Monitor and diagnostic Display’

Serial will make code debugging so much easier.

I wonder if there is anything interesting coming from the serial pins of the untouched device.

[ahull – Fri Apr 20, 2018 8:00 am] –
Neat. That just leaves the flash to decode and the ODB II interface to de-cypher. Pretty good progress in a few days considering we started knowing nothing about the thing.

Serial will make code debugging so much easier.

I wonder if there is anything interesting coming from the serial pins of the untouched device.

Yep

I was wondering the same about the original device. Unfortunately I returned it (the one I ordered after I accidentally erased this one) to Amazon after very carefully checking whether I could dump its software (I couldn’t because read-out protection was enabled).

When the X60 round-version comes, I’ll be sure to check.

Do we know which pins on it go where?

[ahull – Fri Apr 20, 2018 2:52 pm] –
BTW did we figure anything out about the “mystery” chip, I think it was U5, the one with no writing on it?

Do we know which pins on it go where?

That’s right, U5. No I haven’t looked at it yet.

My Black Magic Probe arrived today. I don’t know what to do with it, other than use it instead of my ST Link V2, and instead of the USB to TTL converter. I think it does both of those in one.

I still need to watch that Hackaday video on debugging that Rick posted.

[Rick Kimball – Sun Apr 15, 2018 6:05 pm] –

[carl0s – Sun Apr 15, 2018 1:51 pm] –
I was about to try some code to vary the screen brightness based on the LDR, but, without a serial console, I don’t know what numbers are coming back from analogRead(LDR_PIN), so I don’t know what maths to do for the analogWrite to the TFT_LED.

Am I approaching this properly? Should I come back to it once I have a serial console?

You could use your stlink programmer as a debugger and look at the values in arm-none-eabi-gdb … Al from Hackaday did a nice video describing how to do basic debugging.

https://www.youtube.com/watch?v=D-MbC9N5U7o

Damn that’s awesome. I just need to try to do that with my BMP, and also see how PlatformIO integrates it. A job for tomorrow’s rainy day.

Thanks for posting it.

I don’t think the pinouts match any kind of i2c eeprom, nor do the MCU pins match up with any clues on the GD32 datasheet.

It goes like this:

1-VCC GND-8
2- -7
3- PC8-6
4-PC7 PC9-5

The 120 ohm end-of-line CAN resistor is present across IC pins 6 and 7 (CAN High and CAN Low). This is R16. For some projects where you are sniffing an existing bus, I think you would want to remove this resistor.

Image

I have to admit, I don’t understand how this thing works.

On my own project, I used an ST L9637D for UART <-> K-Line.

Regardless, you could just configure UART1 to 10400 bps and away you go.

I spent a lot of time scratching my head when it didn’t work because I had #include SPI.h before #include SPIFlash.h

It only works if you #include SPIFlash.h before SPI.h

Image

I’m going to try it with Paul S (teensy)’s SerialFlash library.

Have you seen this UI ? I want it! It’s all written around UTFT though.

I was finally able to read it in-circuit with the SOFI SP8a, by choosing Device Type: Winbond W25X16V [ISP]. You have to choose a chip definition that says [ISP] otherwise it insists on something being put in the ZIF socket. There were no Spansion chip definitions that said [ISP] so I went with a 16mbit Winbond of the 25x series that I read was supported by the same Arduino SPIFlash library that I already found to work with the chip, and that I’d verified commands match the Spansion data sheet.

I made sure the board was already running, but not with anything that was using SPI1, so that the ISP didn’t end up trying to power the MCU and everything else.

You can see lots of car diagnostics related strings in the dump. I expect it’s just a list of codes and their descriptions. I should try binwalk on it though.

Here’s the file: http://www.internetsomething.com/autool … 16mbit.bin

Image

Image

bit of messing around in MS Paint…

Image

[carl0s – Sun Apr 22, 2018 12:42 pm] –
OK the mystery chip is still a mystery.

I don’t think the pinouts match any kind of i2c eeprom, nor do the MCU pins match up with any clues on the GD32 datasheet.

It goes like this:

1-VCC GND-8
2- -7
3- PC8-6
4-PC7 PC9-5

[RogerClark – Sun Apr 22, 2018 10:15 pm] –

[carl0s – Sun Apr 22, 2018 12:42 pm] –
OK the mystery chip is still a mystery.

I don’t think the pinouts match any kind of i2c eeprom, nor do the MCU pins match up with any clues on the GD32 datasheet.

It goes like this:

1-VCC GND-8
2- -7
3- PC8-6
4-PC7 PC9-5

[RogerClark – Sun Apr 22, 2018 10:20 pm] – PC7 ???

Sorry I hit Submit by accident before finishing

[ahull – Mon Apr 23, 2018 4:24 am] –
Those graphics suggest this device is a close relative too -> http://carpro.com.my/shop/index.php/eas … splay.html

Yup

I didn’t get much further than you, but I suspect there is more graphical “stuff” in that flash chip image.

These are some of the “images” I extracted using convert ….

convert -depth 8 -size 320x240 bgr:autool-x50-16mbit.bin -roll +240+32 out2.png


Because although the number of pixels per line if the same for all parts of that image, the start address of the next part of the image is not directly after the end address of the previous image.

I would suggest perhaps there is a small header befor each image but I can’t see any evidence of that in the photos , but perhaps I just can’t see it