Spark Logic

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

carl0s Wed Apr 11, 2018 5:27 pm

Hi!

I’m Carl

My first project with STM32 will hopefully be to get some code onto this GD32F103 board, and drive the LCD. I first need to figure out what the driver is. It appears to be using 17 pins.. Hopefully the ILI9341.

I will then use this as a screen / controller for my vehicle datalogger that I have already built on an Adafruit Feather M0.

Here’s the thing I want to hack..

Note that the mini-USB on the back here is actually for a vehicle OBD connection, and will be expecting +12v as well as K-Line, L-Line, CAN-Hi/CAN-Lo, etc.. It’s *not* a Mini-USB connection!

(in most web browsers, you can right-click on the images below and choose Open Image in New tab, to view at full resolution).

Image

Image

Image

Image

Image

Replies

ahull Sat Apr 14, 2018 9:38 am

The display should be relatively easy to interface. In fact Adafruit did (still do?) an ST7789 based display

https://www.adafruit.com/product/3787

You should be able to compare how that works with say the STM32Duino Adafruit_ILI9341_STM examples. I think the two controllers are similar.

I think you can control the backlight with analaogWrite, so something like.. (untested)..

#define TFT_LED PB1
#define LRD_PIN {whatever you discovered}
...
...
pinMode(TFT_LED, OUTPUT);
analogWrite(TFT_LED, 127);
...

etc.

carl0s Sat Apr 14, 2018 9:47 am

[ahull – Sat Apr 14, 2018 9:38 am] –
The display should be relatively easy to interface. In fact Adafruit did (still do?) an ST7789 based display

https://www.adafruit.com/product/3787

You should be able to compare how that works with say the STM32Duino Adafruit_ILI9341_STM examples. i think the two controllers are similar.

I think you can control the backlight with analaogWrite, so something like.. (untested)..

#define TFT_LED PB1
#define LRD_PIN {whatever you discovered}
...
...
pinMode(TFT_LED, OUTPUT);
analogWrite(TFT_LED, 127);
...

etc.

ahull Sat Apr 14, 2018 10:01 am

All five pins of the USB connector go *somewhere*, or at least there are tracks leading off to vias on the PCB. It would be useful to know where exactly they go.
Screenshot from 2018-04-14 11-02-30.jpg
Screenshot from 2018-04-14 11-02-30.jpg (106.66 KiB) Viewed 349 times

ahull Sat Apr 14, 2018 10:07 am

Regarding the ST7789 I also uncovered a site that does a (paid for) driver, which also suggests there is a lot of similarity between the ST7789 and the ILI9431 and its close cousins. -> https://www.ramtex.dk/display-controlle … st7789.htm

carl0s Sat Apr 14, 2018 10:08 am

[ahull – Sat Apr 14, 2018 10:01 am] –
All five pins of the USB connector go *somewhere*, or at least there are tracks leading off to vias on the PCB. It would be useful to know where exactly they go.
Screenshot from 2018-04-14 11-02-30.jpg

I will trace them out. But the cable supplied has mini usb on one end, and a 16 pin OBD2 connector on the other. So there will be can hi, can low, K-line, maybe L-line (both iso 9141, L-line usually not needed), gnd, and +12v I expect.

ahull Sat Apr 14, 2018 10:10 am

[carl0s – Sat Apr 14, 2018 10:08 am] –
[ahull – Sat Apr 14, 2018 10:01 am] –
All five pins of the USB connector go *somewhere*, or at least there are tracks leading off to vias on the PCB. It would be useful to know where exactly they go.
Screenshot from 2018-04-14 11-02-30.jpg

I will trace them out. But the cable supplied has mini usb on one end, and a 16 pin OBD2 connector on the other. So there will be can hi, can low, K-line, maybe L-line (both iso 9141, L-line usually not needed), gnd, and +12v I expect.

EDIT: None the less, it would be interesting to see which pins go where. We may be able to make use of some of the pins on that weird USB connector for our own purposes. I vaguely recall he STM32 uses the same memory area for USB and CAN, and perhaps even the same pins. If there is some active circuitry in the cable, the USB port might actually have D+ and D- wired directly to the GD32.. in which case, you never know, you may be able to use the USB connector as a USB connector. I would check for high voltages coming out of it before I risked plugging it in to a PC of course.

It is possible that the high voltages have to be switched on in software, and the port may therefore power up like a USB port, and go in to ODB mode only when the software instructs it to.

carl0s Sat Apr 14, 2018 10:14 am

[ahull – Sat Apr 14, 2018 10:10 am] –
[carl0s – Sat Apr 14, 2018 10:08 am] –
[ahull – Sat Apr 14, 2018 10:01 am] –
All five pins of the USB connector go *somewhere*, or at least there are tracks leading off to vias on the PCB. It would be useful to know where exactly they go.
Screenshot from 2018-04-14 11-02-30.jpg

I will trace them out. But the cable supplied has mini usb on one end, and a 16 pin OBD2 connector on the other. So there will be can hi, can low, K-line, maybe L-line (both iso 9141, L-line usually not needed), gnd, and +12v I expect.

None the less, it would be interesting to see which pins go where. We may be able to make use of some of the pins on that weird USB connector for our own purposes.

Yes true. I was thinking the same.. change out the canbus or lm393 (used for k line) for something else maybe.

ahull Sat Apr 14, 2018 10:17 am

It is possible that the high voltages have to be switched on in software, and the port may therefore power up like a USB port, and go in to ODB mode only when the software instructs it to.

RogerClark Sat Apr 14, 2018 10:38 am

I think if you select STLink upload it still keeps USB serial enabled, as STLink dongles do not have serial USB built into them

I’d recommend you pick the Generic stm32f103c8 and STLink

Run the driver installer

upload then upload any sketch with USB connected to the to the PC.

And see if anything appears in Windows device manager

carl0s Sat Apr 14, 2018 10:41 am

[RogerClark – Sat Apr 14, 2018 10:38 am] –
I think if you select STLink upload it still keeps USB serial enabled, as STLink dongles do not have serial USB built into them

I’d recommend you pick the Generic stm32f103c8 and STLink

Run the driver installer

upload then upload any sketch with USB connected to the to the PC.

And see if anything appears in Windows device manager

Thanks Roger I will try after I have found a usb hub to isolate it from my laptop’s usb ports. I just tried running it (the working unit) off the car cigarette lighter adapter that runs my dashcam and there were no signs of life. No beep or screen on.

ahull Sat Apr 14, 2018 10:49 am

This is how a “real” USB plug should be wired.
Screenshot from 2018-04-14 11-47-33.png
Screenshot from 2018-04-14 11-47-33.png (23.64 KiB) Viewed 204 times

ahull Sat Apr 14, 2018 11:07 am

I suspect D+ and D- probably go (directly or indirectly) to PA11 and PA12 since these are the pins for both USB-/USB+ and CANrx/CANtx

Image

carl0s Sat Apr 14, 2018 12:11 pm

[ahull – Sat Apr 14, 2018 11:07 am] –
I suspect D+ and D- probably go (directly or indirectly) to PA11 and PA12 since these are the pins for both USB-/USB+ and CANrx/CANtx

Image

CAN Rx and CAN Tx have to go via a CAN transceiver chip. It’s chip U2 on the board.

ahull Sat Apr 14, 2018 1:22 pm

CAN Rx and CAN Tx have to go via a CAN transceiver chip. It’s chip U2 on the board.

Indeed, but the output of U2 doesn’t necessarily need to go to the D+ and D- pins of the USB connector.

Since VBus does not seem to be present, that leaves potentially four pins of the five, (the other being GND) that we haven’t really mapped.

I still think it would be interesting to follow those tracks from the USB connector to see where they go.

carl0s Sat Apr 14, 2018 7:34 pm

Ugh.. it’s time I tried to use Fritzing. I’m going to try now.

Here’s what I have so far, if you can even follow it.

Here’s one thing I don’t understand. The LDR. It goes GND->LDR->PA2<-R14(10k)<-3.3v.

I get that this is a voltage divider and that’s how PA2 can read the value of the LDR. What I don’t get, is why does the value that my multimeter shows for R14 vary from 7k to 8k depending on whether I have the LDR covered or not? I have my meter right across R14. 10k is the value printed on it.

Image

Image

As you can see, I have put U1 (LM393 comparator, used for K/L line iso9141), in two places on the diagram. I’m off to Tesco for a beer, then I’m going to check out Fritzing.

carl0s Sat Apr 14, 2018 10:43 pm

Sheesh. That isn’t easy either, and neither is Eagle CAD! Any recommendations ?

Nevermind. I think DipTrace is the one to go for.

RogerClark Sun Apr 15, 2018 11:56 am

Use KiCAD

Non of the CAD packages are easy, but KiCAD is open source and favoured by most people on the forum

carl0s Sun Apr 15, 2018 12:09 pm

[RogerClark – Sun Apr 15, 2018 11:56 am] –
Use KiCAD

Non of the CAD packages are easy, but KiCAD is open source and favoured by most people on the forum

I have installed KiCad. I’ll give it a look. I am a big open source libre fanatic. DipTrace was looking easy because it has LQFP64 stm32 parts in there already and is reasonably priced for what looks to be high quality software.
Maybe I can download LQFP-64 stm32 components for KiCad. The stm32f407 lqfp-64 parts seem to have almost identical pin names/numbers to the lqfp-64 F103

I am currently trying to get my head around transistors.. I know it should be simple, but I’ve never tried to understand before.

The buzzer (piezo) on this board seems to have its +ve wired to the output of the main step-down IC (MP1482).
Its -ve is wired to the Collector of a general purpose NPN transistor (1AM).
The base of that NPN transistor goes through a 2K resistor R8 to PB6 of the MCU
and the emitter goes to GND.

How does that work then? NPN transistor is switched on with PB6 goes High (because that’s how NPNs work apparently?). Does that then just switch collector <-> emitter on. Are the Collector and Emitter back to front in this, or does it not matter?

Sorry for the elementary questions.

carl0s Sun Apr 15, 2018 12:36 pm

OK, well it’s more of a tick rather than a buzz or beep, but at least I have the correct MCU pin for the piezo buzzer.

I guess you have to PWM a buzzer..

ahull Sun Apr 15, 2018 1:58 pm

I guess we just need to know what the trend is with the LDR, i.e. if it sees less light, we need to increase the LCD brightness and vice versa so if ADC value increases, brightness decreases (assuming the LDR is set up that way). The range of a typical LDR is quite broad, so anything from a few hundred ohms in bright light to perhaps a megohm or more in total darkness.

Using relative values should be doable without necessarily knowing the exact numbers coming from the ADC.

If you are a bit of a masochist you could of course blink out the numbers in Morse code :P
People have blinked out entire firmware dumps this way, but I don’t think we are quite that desperate.
http://chdk.wikia.com/wiki/Blinking_the … _interface

Sign in to reply