I post this before consigning the TFT panel to the bin marked ‘bad devices shipped to me’.
I’m trying to get an ILI9341 320×240 LCD display panel working with the Blue Pill.
I’ve checked all my connections about 8 times now – I’m certain I’ve wired it up correctly without shorts or cross-connections with other pins.
The Blue Pill is running the code fine – The TFT screen remains ‘blank’ (just a white screen when the 3.3V backlight power is applied).
With the 3.3V disconnected, the screen ‘flickers’ which seems to correspond with the test patterns being run, but nothing is ever displayed.
The serial monitor seems to show a problem with communications.
ILI9341 Test!
Display Power Mode: 0xD3
MADCTL Mode: 0xD3
Pixel Format: 0xD3
Image Format: 0xD3
Self Diagnostic: 0xD3
Device ID: 0xD3D3D3D3
Benchmark Time (microseconds)
Screen fill 309999
Text 27292
Lines 126060
Horiz/Vert Lines 23695
Rectangles (outline) 15487
Rectangles (filled) 643837
Circles (filled) 104440
Circles (outline) 98367
Triangles (outline) 29306
Triangles (filled) 207032
Rounded rects (outline) 40704
Rounded rects (filled) 689085
Done!
. . . as you can see, continuous references to 0XD3 (1101 0011).
My wiring is correctly matching the settings in Adafruit_ILI9341_8bit_STM.h, specifically:
//Port data |D7 |D6 |D5 |D4 |D3 |D2 |D1 |D0 |
//Pin stm32 |PB15|PB14|PB13|PB12|PB11|PB10|PB9|PB8|
//Control pins |RD |WR |RS |CS |RST|
//Pin stm32 |PA0|PA1|PA2|PA3|PA8|
#define TFT_CNTRL GPIOA
#define TFT_DATA GPIOB
#define TFT_RD PA0
#define TFT_WR PA1
#define TFT_RS PA2
#define TFT_CS PA3
#define TFT_RST PA8
Please try this: https://github.com/prenticedavid/MCUFRI … eadreg.ino and post here the serial printout.
Edit the defines to match your wiring on your BluePill.
Copy-paste the output from the Serial Terminal.
There is no point in expecting anything to work until the pin wiring has been verified.
I am sure that your Adafruit_ILI9341_8bit_STM library will work fine when your wiring is correct.
Does it expect the data bus to be on PB8..PB15 ?
I would always use the recommended official wiring before trying any custom setup.
The readreg sketch will let you test any scheme you want on any target you want e.g. ESP32, STM32, Kinetis, AVR, …
David.
I modified the script thus:
#define LCD_RST PA8
#define LCD_CS PA3
#define LCD_RS PA2
#define LCD_WR PA1
#define LCD_RD PA0
#define LCD_D0 PB8
#define LCD_D1 PB9
#define LCD_D2 PB10
#define LCD_D3 PB11
#define LCD_D4 PB12
#define LCD_D5 PB13
#define LCD_D6 PB14
#define LCD_D7 PB15
I ran the unit from a separate 3.3V rail in case the 3.3V regulator wasn’t up to the job of providing enough current (even though it lights).
Same thing – No go
Ken
This thread looks to address the same TFT Panel:
https://forum.arduino.cc/index.php?topic=450176.0
This board probably has a Himax HX8367-A controller.
Ken
Thanks once again.
I’ll keep this thread updated as to my progress, as perhaps others would like to use this inexpensive panel with their STM32 projects . . . or . . . some chinese gentleman mis-sold them the device on the premise that it was an ILI based controller on board and they still want to try to get it working. 
Ken
The good news: This library is supporting nearly most of all “popular” MCU friend TFT’s:
https://github.com/prenticedavid/MCUFRIEND_kbv
The best news: Working on STM32 without problems and/or modifications
(done it with an “older” MCU friend shield (0x7783) on my nucleo with rogers core straight out of the box)Is it Solved ?
I was hoping to get it going, but playing about with the device for the past few hours . . . writing my own ‘raw’ script to initialize the LCD and even send some basic commands to it . . . even to just switch the panel on and off, all fail to deliver. I just get a white screen permanently.
If you could, could you change the title for the more appropriate ‘Missold ILI9341 is really Himax MX8367-A.’ or something similar.
I guess the issue is solved. Whatever you see fit. I’ll leave it at that.
I’ll keep dabbling with the device, but I still think at this stage that it’s faulty.
If I get it working, I can open another thread including my working sketch.
No doubt, more people will find a similar thing happening to them. I just checked eBay and there are still many of these devices being sold as ‘ILI9341’.
All the best
Ken
Himax controllers behave VERY differently to ILI9341.
I suggest that you use the “BluePill Adapter Shield” wiring or one of the STM32 SPECIAL wiring schemes.
If you have a compelling reason for a different scheme, I will write a SPECIAL for you.
David.
Thank you for your help.
I had a look at the MCUFRIEND stuff, and my initial thoughts were that it was just too complex for me to get my head around.
This was mainly as I tend to not use ‘shield’ type thinking. I just use the raw pins. I usually like a ‘define’ for everything I need in the main code from the outset.
I saw the pointer for altering the #define to support the HX8367, I couldn’t find a way to alter the code to support the pins I was using on the Blue Pill though (PB8 – PB15).
However, if you could please tell me what pins the ‘Bluepill Adapter Shield’ setting uses for the data pins (and any #define I need to either uncomment or comment for it), I can rewire the LCD and see if I can get it to work using that code/library.
Thank you
Ken
Nucleo boards have Arduino sockets. So I support several Nucleo boards. In fact the Beta supports most boards from the ST core.
I suggest that you wire like the Bluepill Adapter Shield. Control pins are on PB5..PB9. Data pins are on PA0..PA7
From mcufriend_shield.h in the current Beta:
...
#elif defined(ARDUINO_GENERIC_STM32F103C) || defined(ARDUINO_NUCLEO_F103C8) || defined(ARDUINO_BLUEPILL_F103C8)
#warning Uno Shield on BLUEPILL
#define RD_PORT GPIOB
#define RD_PIN 5
//#define RD_PIN 0 //hardware mod to Adapter. Allows use of PB5 for SD Card
#define WR_PORT GPIOB
#define WR_PIN 6
#define CD_PORT GPIOB
#define CD_PIN 7
#define CS_PORT GPIOB
#define CS_PIN 8
#define RESET_PORT GPIOB
#define RESET_PIN 9
// configure macros for the data pins
#define write_8(d) { GPIOA->REGS(BSRR) = 0x00FF << 16; GPIOA->REGS(BSRR) = (d) & 0xFF; }
#define read_8() (GPIOA->REGS(IDR) & 0xFF)
// PA7 ..PA0
#define setWriteDir() {GP_OUT(GPIOA, CRL, 0xFFFFFFFF); }
#define setReadDir() {GP_INP(GPIOA, CRL, 0xFFFFFFFF); }
...
[david.prentice – Thu May 03, 2018 7:27 pm] –
The ST Core follows regular conventions.
It is VERY awkward supporting the WEIRD Maple Core that Roger uses.
That’s the heritage leaflabs left behind
A more convenient method (but slower because not the whole 8bits are written at once!) for individual pin toggling at high speed could be using the
gpio_write_bit(PIN_PORT, PIN_BIT, HIGH (or) LOW);
Especially when the ST Core seems more futureproof.
The new ST Core supports BluePill and MapleMini boards as well as many Nucleo and Discovery boards.
David.
Three things to keep in mind:
On the shield Datalines D0 and D1 (in opposite to D2-D7) are in reversed direction so double check the silk print on the shield
On the “master” version (the first you can/would prefer to download):
//#define RD_PIN 5
#define RD_PIN 0 //hardware mod to Adapter. Allows use of PB5 for SD Card[david.prentice – Thu May 03, 2018 8:37 pm] –
There are several handy LeafLabs functions. I do not want to be dependent on them.
Especially when the ST Core seems more futureproof.The new ST Core supports BluePill and MapleMini boards as well as many Nucleo and Discovery boards.
David.
AFIK
Currently although STM’s core, supports generic boards like the BluePill (and MapleMini, you have to upload via USB to Serial or STLink as bootloaders are not supported.
Modern STM32 Factory Bootloader can use multiple interface methods
The “elderly” STM32F103 Factory Bootloader can only use Serial interface.
Yes, for a F103 it is convenient to add a third-party USB Bootloader so that you have a one cable operation.
But you still need an STLink or Serial Adapter to install the third-party Bootloader in the first place.
I would assume that any STM Core built sketch can be linked for your Bootloader in the same way that the Maple Core sketches are linked.
The Maple Core has many useful functions. It has better SPI performance due to DMA.
I would push for improvements to the standard Arduino Core library classes. Then Arduino users would benefit on all platforms.
David.
Strangely the F4 HAL files have he guard ifdef, and I mentioned this to Frederic, but I have not looked at the HAL for ages, so I don’t know if STMs HAL team have now updated the F1 code to make it consistent with the F4.
Rather than using the LibMaole based bootloader, anyone using STMs core that wants to use a bootloader should probably look at the USB HID bootloader by @bootsector and enhanced by @vassilis, as it doesn’t need a driver.
( but this is still a work in progress )
And the STM Core would need other changes to use the HID bootloader as it uses BPK register DR10 as a flag
VECT_TAB_OFFSET is defined in a system_stm32YYxx.c template file provided with the ST HAL so it could be is easily updated or changed to use a guard #ifndef …
STM core uses one for each series in each STM32YYxx/system_stm32yyxx.c
https://github.com/stm32duino/Arduino_C … ter/system
Ex:
https://github.com/stm32duino/Arduino_C … 1xx.c#L113
#ifndef VECT_TAB_OFFSET
#define VECT_TAB_OFFSET 0x00000000U /*!< Vector Table base offset field.
This value must be a multiple of 0x200. */
#endif
Thanks.
I thought perhaps the F4 already had the #ifdef, but I checked the code on github and it does not have it
Perhaps the HAL dev team at STM removed it, or perhaps I just dreamed it was Ok on the F4
I am not sure if this is something STM want to add, but @bootsector has developed a driverless USB HID bootloader, which only takes about 4k, and @vassilis is now improving it.
I think @bootsector may also port the bootloader to the F4.
This will probably eventually replace the Maple DU bootloader, because it does not require a driver, and drivers are always a problem
However all bootloaders (except perhaps USB Mass storage ) need a uploader binary for each platform.
I think this will be never added to CMSIS device from ST as this is in a template file that user could/should customize:
https://github.com/stm32duino/Arduino_C … /Templates
Anyway, I’ve added the possibility to redefine it:
https://github.com/stm32duino/Arduino_C … c8c87a9d35
About using another bootloader, personally I think it will be a great feature to add and probably I will give a try on my personal time to do that (like several other feature )
It don’t think the USB HID bootloader is completely stable yet, as Vassillis has some problems with Ubuntu
I will try to investigate the problems
[RogerClark – Mon May 07, 2018 9:32 pm] –
Hi FredericIt don’t think the USB HID bootloader is completely stable yet, as Vassillis has some problems with Ubuntu
I will try to investigate the problems
When I told I will investigate on this, I talk about coming month not in the coming weeks. 
No worries….
New v2.9.8 Release of the MCUFRIEND_kbv library can be installed/upgraded via the IDE Library Manager
Added controllers: unknown make 0x8031, Himax HX8352-B, HX8357-C, HX8357-D
Added target Nucleo64 boards: F030, F091, F103, F303, F401, F411, F446, L053, L152, L476
No one has ever asked for Nucleo144 board support. Does anyone have a Nucleo144 and Mcufriend display to test?
Please note that the ILI9320 class of controller is too slow for M4 chips.
Ask if you want to use this type with M4 e.g. SPFD5408, UC8230, ILI9325, R61580, …
David.
