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

Right. tft.begin(mySPI2); gives an 18MHz clock, and the 24MHz $5 logic analyser can’t cope with it.

tft.begin(mySPI2, 8000000); gives a 4.5MHz clock according to the scope, and 4MHz according to the L/A. It’s pretty dirty though.

It looks like D/C (data/command) never changes.

I wonder, is there an issue with PA11 ?

I have just found out about the PA15 issue (it is wired for TFT_RST here), and since I’m using ST Link, I have set afio_cfg_debug_ports(AFIO_DEBUG_SW_ONLY);

Right! At 1MHz SPI, which for some reason gives a 500KHz clock, the correct commands are being interpreted by my really crap logic analyzer.

That’s a good sign!
compare:
Image

with: https://github.com/adafruit/Adafruit_IL … 1.cpp#L270

but I think D/C line is never changing
http://www.internetsomething.com/autool … .logicdata

PA11/12 are USB pins.

[stevestrong – Mon Apr 16, 2018 9:01 pm] –
PA11/12 are USB pins.

In my case they are not wired as such. Is there some code that is switching them into USB mode that I can try to override?

The default for the chip is for PA11 to be PA11. Apparently USB is an alternate mode.

I have no USB port currently!

They are configured as USB pins on reset.

For STLINK uploads the USB is enabled by default in the core

Take a look in boards.txt at the menu option for serial upload as it has the switches to disable USB Serial as it uses hardware Serial

[RogerClark – Mon Apr 16, 2018 9:07 pm] –
For STLINK uploads the USB is enabled by default in the core

Take a look in boards.txt at the menu option for serial upload as it has the switches to disable USB Serial as it uses hardware Serial

I’m tinkering with board.cpp and board.h as we speak, although I’m not really sure what I’m doing Commenting out USB assignments, increasing BOARD_NR_ADC_PINS, adding PA11 into the boardADCPins list. Still no worky

Oh. pa11 isn’t an adc pin anyway. i’ll try adding into into pwmpins

Change boards.txt not board.cpp

I think there is something like -DSERIAL_USB

In the upload menu option for STLink

Just remove that and save and then realised the IDE

[RogerClark – Mon Apr 16, 2018 9:16 pm] –
Change boards.txt not board.cpp

I think there is something like -DSERIAL_USB

In the upload menu option for STLink

Just remove that and save and then realised the IDE

You know I’m using PlatformIO as my IDE though right?

No,

But I think it must retain some of those config somewhere otherwise nothing would work

You could try making sure that SERIAL_USB ( or perhaps it’s USB_SERIAL) is not defined as the core will use it as a flag to run all the USB Serial code

HOLY CRAP

HOLY CRAP

I just did this:

Image

and now I have THIS

Image

It works fine with default 48MHz SPI too (I removed frequency from tft.begin. I think that then uses 48MHz. Although my scope shows the clock as being 18MHz.)

So the problems were simply RST pin being claimed by JTAG, and D/C pin being claimed by USB.

Also, I have had to switch the width and height in the ILI9341_STM file:
#define ILI9341_TFTWIDTH 320
#define ILI9341_TFTHEIGHT 240

Cool

BTW. The GD32 will run fine at 120Mhz and also with zero wait states in the flash, so you may want to change your settings as that would give you a considerable performance boost even over the 108Mhz it may be currently running at.

[RogerClark – Mon Apr 16, 2018 11:18 pm] –
Cool

BTW. The GD32 will run fine at 120Mhz and also with zero wait states in the flash, so you may want to change your settings as that would give you a considerable performance boost even over the 108Mhz it may be currently running at.

Thanks Roger! Well, I am using genericSTM32F103R as a board definition.

I’m not sure how to override board settings in PlatformIO. I suspect your boards.txt might be pulled into in a database, or cached… it might be too late after I have created the project and chosen the board definition. Certainly I tried removing -DSERIAL_USB from the upload options but it didn’t work for my TFT problem. I’m still only able to get it working with the above change to the init function in boards.cpp.

Must say though, I’m rather chuffed that all of this is possible. When I ordered this thing I thought, hmmm.. I wonder if I’ll be able to use the screen. Someone on the arduino forums said it might just have a blob of epoxy over the chips, and here I am with a useable screen, microcontroller, and a couple of i/o things (I might use the CAN transceiver as my connection between this screen/controller and the separate datalogger device).

[RogerClark – Mon Apr 16, 2018 11:18 pm] –
Cool

BTW. The GD32 will run fine at 120Mhz and also with zero wait states in the flash, so you may want to change your settings as that would give you a considerable performance boost even over the 108Mhz it may be currently running at.

I found it You have to put the options in platformio.ini within the project.

I could only choose 128MHz though. I got “error: ‘BOARD_RCC_PLLMUL’ was not declared in this scope” if I tried 120MHz.

The screen sure looks to be updating quickly with the CPU at 128MHz

Scope says the SPI clock is now 32MHz.

Incidentally, I was not able to get the SPI clock above 18MHz any other way. I tried setting the divider to DIV2, as well as specifying frequency in tft.begin, but I never got an SPI clock above 18MHz. It’s using a divider of 4 over CPU freq regardless.

By the way, being the RB version of the chip (GD32F103RBT6), this one has a full official 128KB of flash. I think a few people were thinking it didn’t.

Ah OK

I thought it was the GD32F103C8 which only has 64k flash (and it only has 64k shadow / program RAM)

See

https://github.com/rogerclarkmelbourne/ … 9e1aa8c15a

Change that to zero wait states, as only the STM32 need wait states