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

There used to be a thing called Action Replay on the Amiga. It was like a hardware debugger that could cut-in to anything that was running on the system. Really cool. You could browse through RAM and find images, as well as bookmark numbers and see if they changed (when your score changed in a game for example.. to locate where score was stored in ram, and modify), and save the running state of the machine, etc.

Anyway that’s what I was thinking of when I found that 7yuv tool that let me scan through the .bin/.hex in a visual way. I wonder if there are other/better tools? That one was ok. clunky interface, and didn’t cope with my HiDPI screen. I think I might be able to overcome the DPI issue though, as I have been playing with per-app-DPI settings in preparation for the gadget that I ordered last night: DSLogic Plus (the one with the bigger 256MByte on-board buffer). 16 channels of hopefully actually usable logic analyzer for 86 quid. God I wish I was single.

[RogerClark – Tue Apr 24, 2018 1:39 am] –
HxD is a good general purpose hex editor, but it doesn’t view images etc

Yes I do have that installed but I was specifically looking for something to visualise. That 7yuv program worked just fine. At first I could see the image but colours were weird, so I changed colour format. Would have been nice to be able to alter the start/end, kind of like width/margins. When browsing car ECU dumps with WinOLS (for finding maps) you can do all that stuff (fix the widths and start/end to size/shape things properly), and it visualises things for you so you can find tables of map data. That’s an expensive program though for what it does.

Over on the AVR freaks forums I was able to use Ghostscript to decode the encoded numerical states of of a mixed Graphics/Segment display from a Yamaha PSR 620. https://www.avrfreaks.net/forum/yamaha- … d-lcd-dead That was much more difficult as I only had some screen shots in that thread to work with.

I have not had the time to look at this binary to see if there is anything interesting in the dump of this OBD device. Am still attempting to find the time to try the cheap (as in free) non standard TFT display I got from the tradeshows years ago on the STM32.

Edit: I opened the bin in a hex editor and there are quite a few text strings in it. This is where Postscript comes in handy as it can separate text from binary. Looking at the dump it does not look too unlike other things I have dumped such as the Mars Mairner9 data tapes. Often in tables like these there are pointer offsets into other areas of the code/data. As there is alignment in the logo graphics these would be easy to process. The text tables could then be dumped to see if they are in a linked list or an array of fixed length or zero terminated stings. Note that Pascal style strings with a length byte are a form of linked list.

strings autool-x50-16mbit.bin |grep "^P[0-9][0-9][0-9][0-9]" >PXXXX_Codes.txt

@carl0s Does the device offer more than one language option?

I notice that at address 0x13F45F the sequence starts with 0x20 which is a space and the text field ends with a space. The data the follows has high bits set. The next space is at 0x13F480, then there is a <CR><LF> and a space. <CR><LF> is often and end of line or end of sequence. The rest of the P codes seem to be preceded by <CR><LF>. The first one at 0x13F45F is not, so this likely represents the end of the record.

When we get down to 0x14D3B3 the strings do not seem to contain the high bits set. This pattern seems to end at 0x159402 with an eol. It has been 20 years since I worked with non roman graphics. So I would have to re read the chapters on such.

One of the other projects I am working with, is terminal emulation with box drawing characters. Such was used in older MIDI gear for showing value settings. As I am not a motor gear head, I do not know if this sort of things is done. I do know that when I drive my parents Prius that it is like booting up a computer to start and it has all kinds of bar graphs. My own Honda has a lot more on the display than the clock or a backup camera.

I am sort of wondering if such things could use say a java interface. ST makes a really expensive Java development kit for the STM32. I got as far as downloading the Games demo. The MIDI organ emulator is written in java (Why it is called jOrgan) Just blue skying here as it is easy to create graphic widgets Java. Something that could be tested/emulated on a cheap platform.

On the other hand there are libraries such as the STemWin one that The ST reps push with effort in the trade seminars. That might be the more likely API this data plays into.

I think this piqued my weakness for parsing data. Perhaps I will write a script to distill some of this data…

Edit: I did some online reverse image search, looking for the owners manual. It looks like some of this text is menu screens, like the Yamaha PSR MIDI keyboard. I found one You tube video that showed a language section option menu item. This only showed EN. The website in the links indicate that the price is in Malaysian currency. TinEye and Google find similar displays and others looking for owners/user manual links.

These things are pretty cheap I guess they sell high volume enough to handle the injection molds and some decent graphics designers. Interesting to contrast to the MIDI gear which is in simple steel boxes, and valued and priced, by weight and the number of knobs and blinkelights.

cobd18424.jpg

cobd18424.jpg (145.59 KiB) Viewed 229 times

For example …
grep --text --color='auto' -P -n "[\x80-\xFF]" autool-x50-16mbit.bin |grep -a "P[0-9][0-9][0-9]"


[ahull – Wed Apr 25, 2018 3:23 am] –
@Sheepdoll it is possible to grep for say utf8 with some clever trickery.
…
Its also possible that characters with the high bit set, simply map to characters above 128 in the font that we assume is in the flash dump, so in other words, we may need to decode the font before we can make sense of these strings.

From what I was able to find in online documentation the languages are English French and Spanish.

In looking at the big picture with postscript I have not been able to find any graphics in the front of the file. It looks like font or icon, but I can not find any color space that makes sense. The repeat is 72 bytes 8 bit pixel gray scale this is the pattern:

cobd1824B.jpg

cobd1824B.jpg (47.52 KiB) Viewed 162 times

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


cobd18425A.jpg

cobd18425A.jpg (26.98 KiB) Viewed 157 times

convert -depth 1 -size 8x480 gray:autool-x50-16mbit.bin out2.png


I suppose it would be good to get an image in hex, i.e. with a clear start, end and format specification, then it might be possible to replace the image with your own choice of logo. I wonder if they are stored as simply as bitmap arrays, or if they are files in some kind of filesystem?

I’ve come to a bit of a standstill on the project for now because, basically, I’ve got what I wanted – the hardware is open! I suppose I could do a proper job of documenting it – proper diagrams.

I need to see if the round version (X60) can be used the same – has the same display controller etc, so I will be repeating with that when it finally arrives, but, apart from that, I now have a big project of learning how to do a nice GUI menu system from scratch. If only there were more hours in the day.

I grabbed the first 256 bytes of that flash dump.
dd if=autool-x50-16mbit.bin of=chunk.bin bs=256 count=1


[carl0s – Wed Apr 25, 2018 8:26 am] –
Interesting work

… its keeping me entertained

I suppose it would be good to get an image in hex, i.e. with a clear start, end and format specification, then it might be possible to replace the image with your own choice of logo. I wonder if they are stored as simply as bitmap arrays, or if they are files in some kind of filesystem?

Re-using the existing fonts in your own project, and replacing the existing images should be fairly easy. There doesn’t appear to be any file system. As you can see from my previous post, the first font appears to start at the start of the flash file. There may be some pointers hidden in the dump somewhere, pointing to each of the chunks of data but I suspect the pointers are (were) in the firmware.

I’ve come to a bit of a standstill on the project for now because, basically, I’ve got what I wanted – the hardware is open! I suppose I could do a proper job of documenting it – proper diagrams.

I need to see if the round version (X60) can be used the same – has the same display controller etc, so I will be repeating with that when it finally arrives, but, apart from that, I now have a big project of learning how to do a nice GUI menu system from scratch. If only there were more hours in the day.

There may be some existing Arduino gui libraries that you can re-purpose. You also have the luxury of lots of flash to put stuff in, so you should be able to make a pretty professional job of it. There is nothing to say you need to keep any of the existing fonts or images, since we now have a dump of them.

[ahull – Wed Apr 25, 2018 9:11 am] –

There may be some existing Arduino gui libraries that you can re-purpose. You also have the luxury of lots of flash to put stuff in, so you should be able to make a pretty professional job of it. There is nothing to say you need to keep any of the existing fonts or images, since we now have a dump of them.

Yeah I want to do it like this: https://forums.adafruit.com/viewtopic.php?f=19&t=134574

I’ll make a start on it one day soon..

Since you have a big chunk of flash there to play with, you should be able to produce something a bit more professional.

This should probably go in a separate topic, but does anybody know of a good looking menu system for Arduino?