As a followup on my display venture, I have managed to make the LCD work by sending commands and data to the board.
I found code written for a MSP430 board here: https://luan.eng.br/index/electronic/19/using-the-35-inch-320x480-tft-lcd-ili9488 (https://luan.eng.br/index/electronic/19/using-the-35-inch-320x480-tft-lcd-ili9488)
I modified the code to work with the blue pill board that is available everywhere.
Zip file contains the source and header files, binary file, ioc file, and picture of I/O pin configuration.
The system clock is running at 72 MHz and all I/Os are set low and are set for low speed operation.
I did run into a strange issue that I have been unable to solve. After programming the board, it will not start working without a power down and power back up. Even pressing the reset button on the blue pill will not make it run. I don't know if this is just a problem with my board. It may have something to do with the LCD being connected to the I/O pins.
I tried powering the board and LCD from an external 5 volt power supply instead of the USB connector. That did not make a difference. I also put a 5 second delay in the startup code as a test. I kept the 5V off of the LCD board. When the blue pill got to the 5 second delay I then applied power to the LCD board. But the blue pill board did not continue to run. The only thing that makes it run is the power up and power down sequence. After that the board will restart and run when I press the reset button.
If someone uses the code with a blue pill and LCD they can report what happens after programming is complete.
I still haven't worked with any graphical software yet. I wanted to figure out how to manually talk to the LCD before proceeding. The less unknowns there are the easier it is to trouble shoot when problems occur.
On the topic of strange issue, what programmer are you using, what environment are you using ? what steps do you use to flash ?
I mention this as some systems will program the device then wait for you to click run (it will then take the device out hold or SWD reset) or debug, so disconnecting the programmer after you have written the bin file might work, proving that theory at least. Some code bases required boot from cold flag to operate in a defined manner, in mbedos for example it's boot path is different depending on cold boot, warm boot, reset or vector table IRQ all of which the stm32 core supports. |O that had me stumped for days until i found some random reference to it, it was so long ago i cant even remember why i was using mbedos , how ever i did learn how to write my own vector code from that and now all my projects with stm code use the same file (it does nice things like when it crashes it dumps the core to the serial port)
You have not posed code so we cant say if there is a issue in the code either (a watchdog for example or stray irq setup) , this is where having the right dev environment setup helps, if done right you have a batch of tools like openocd, gdb available that allows you to see into the cpu and it's operations. I also dont know if you are on windows or linux, i use both so it's no difference to me but i do feel my linux tools work better for me like gdb (yes i know it's available under WSL/2 but serial ports have permissions issues i dont want to fight and wsl2 uses a old gdb with no gdb-gui )
to be fair writing code for ili9xxx devices is quite simple, my repos show many examples from full blown lvgl setup to simple text only, no gfx support.
but basics is this,
in 8 bit mode bitbash style,
assert _CS low
assert Command pin Low
send 8 bit command to port
de-assert command high
send 8 bit colour data
deassert _CS high
spi models are different in that the spi decoder has a extra bit for command pin so you send two lots of 8 bits data and in the first it sets the command pin
i wont go into that here, it gives me a headache , but it you want a tl;dr then i will post a link to rasberyypi based lcd hacks.
darkspr1te