Stm32f407vet6 black board and ili9341 tft lcd display

According to the documentation I have with the board, it takes 3.3 volts, not 5. I’m not going to risk frying my board.

I’m still trying to find a way to get the debugging working with my STLink. Which pins on the STLink do you connect to PA9 and PA10?

Have you tried https://github.com/texane/stlink? I think it works with v2 but not v3 debuggers.

I have the software, but I don’t know which pins to use on the st-link v2 clone to connect to the board.

I think the clone does not have a virtual COM, there should be Pins like TxD and RxD. But there are many cheap USB-RS232 TTL converters, these can be used also.
I have checked the schematics, the display board also needs only 3.3 V. But the debug probes cannot deliver much power, so you should measure if the 3.3 V is ok. There is an onboard voltage regulator, so connecting 5V to only the 5V pins is save also. And the USB port will also supply the board, but then only USB and no external 5V.

When you have eclipse installed, you can export an eclipse projectfile from the Mbed project:
‘mbed export -m STM32F407VE_BLACK -i gnuarmeclipse’

My github repo is updated, I have added a precompiled binary in the ./bin directory, maybe you can try to flash this one, it should run the demo screens.

Thank you so much! That will resolve the question of where the problem lies in what I’m trying to do. I’m giving an exam at the moment (I’m a university professor) so I’ll check it after lunch. My development computer is in my office.

no problem, you’re welcome. Don’t surrender :slight_smile:

Your pre-compiled binary works perfectly. However, I cannot compile it myself and get it to work.

I converted over to Eclipse and the build failed, complaining:

make: *** No rule to make target `../libService/toolchain_rules.mk'.  Stop.

I found that Makefile in mbed-os/features/nanostack/sal-stack-nanostack-eventloop but I can’t find the libService directory anywhere.

I know it’s part of the mbed-os, and as far as I can tell my mbed-cli is working correctly. Is there any way I can import mbed-os manually into the directory structure instead of using the mbed-cli tool?

I downloaded mbed-os manually but I can’t find the missing directory or file.

Which version of mbed-os are you using? I have the latest as of today - 5.14.1

OK - I can now compile with mbed, but the executable still doesn’t work. It’s 395456 bytes long instead of your working version which is 392488 long.

mbed complains that the compiler is the wrong version:

[Warning] @,: Compiler version mismatch: Have 7.3.1; expected version >= 6.0.0 and < 7.0.0

I’m going to try to downgrade my compiler. I really don’t want to do that, but i can’t think of anything else I can do to make this work. I wiped out my directories and re-downloaded your code with mbed now that mbed is (in theory) working correctly on my computer.

Once that failed, I tried the export to eclipse and received the same error on the compile as I noted in my previous message.

Attempted both compiler downgrade and upgrade (6 and 9). No luck. Same error on eclipse compile, same flaw with the program (blinking LED only) as before. :frowning:

I’m going to try to play with your LittlevGL port, though, and try to build something that is not using mbed-os, because I’m pretty sure the problem is with mbed-os and not my compiler since I can compile other code and it works. I’ll keep you posted.

yesterday evening (german timezone here) I was offline, now I can continue.

I guess this is something from the gcc installation, this file is not part of the Mbed installation. When the eclipse configuration is working then it is a great environment, but it is very fragile when there are Mbed updates. Mbed itself is heavily tested, under Linux/Windows it is running very stable now. But it is used by Mac users also, so it must work somehow…

For the first step I would suggest to start with a simple blinky. The warning about the wrong version can usualy be ignored, it may be a problem in very seldom cases. For reproducable results, Mbed is tested with a certain compiler version. But I have used different versions also and did not run into any problem.

The different code sizes will be a result of different compiler versions. A simple test is also to use different compiler settings. Mbed uses sets of settings, called profiles. Default is ‘developer’, but you can use also ‘release’ or ‘debug’. Apply the the switch ‘–profile release’ to the compile command, e.g. ‘mbed compile --profile release’. You will find appropriate directories under ./BUILD. The compiler settings that are used are in ‘./mbed-os/tools/profiles’

a simple blinky looks like this:

#include "mbed.h"

DigitalOut led1(LED1);

int main()
{
    while(1) {
        led1 = !led1;
        ThisThread::sleep_for(200);
    }
}

To create a new project, make a new directory and execute there ‘mbed new .’. Then copy the custom_targets directory and custom_targets.json from my repo to the new project. Compile with ‘mbed compile -m STM32F407VE_BLACK -t GCC_ARM’, it must work…

The blinky works, but your LvGL code still won’t work correctly. I even tried building the new mbed project as you specified and then copying the other files from your project to that directory. Always the same result - white screen and blinking LED.

The same with using --profile release. :frowning:

I’m going to try taking the blinky code and creating my own test LvGL code to see if I can make it work. I’ll let you know what happens. Thanks again for your help.

I’ve tried copying your code to the new directory and I get the same result. I’ve tried modifying the blinky to include the other code and I get the same result.

Is it possible that you’re using different code than is in the github repository? I know your binary works.

What version of the compiler are you using? I’ve tried three different versions. The blinky works just fine with any of them, but the LvGL code won’t work.

Really strange. My compiler version is 7.2.1, I can try also other. But there must be some other reason, I just have no clue what it could be.
When the blinky is working then also the rtos is working, this should be more complex than the other code.
The bin was exactly from the latest repo code with the demo enabled.

Neither do I. I have 6, 7, and 9 all available on my machine. I’ve been switching the environment variables for mbed and it has indeed been using the correct compiler each time.

I’m on the latest version (updated yesterday) of Mac OS Catalina and my version 9 of the compiler is the latest as of yesterday as well.

could you put this code at the beginning of main:

    tft.begin();
    tft.setRotation(1);

    while(1) {
        tft.fillScreen(RED);
        ThisThread::sleep_for(1000);
        tft.fillScreen(GREEN);
        ThisThread::sleep_for(1000);
        tft.fillScreen(BLUE);
        ThisThread::sleep_for(1000);
    }

Still won’t work. I’m trying to reduce this down to the bare minimum code. It compiles just fine, but once again does not work. This is frustrating. I’m not sure what else to do other than to try to port the library myself, but your code obviously works on your computer and your executable works on my board.

This is my entire main.cpp

#include "mbed.h"
#include "Adafruit_TFTLCD_16bit_STM32.h"


#if !defined(MBED_CPU_STATS_ENABLED) || !defined(DEVICE_LPTICKER) || !defined(DEVICE_SLEEP)
#error [NOT_SUPPORTED] test not supported
#endif

#define USE_HW_TIMER


Thread threadIO;
Thread threadLvHandler;
Thread threadStepper;
Ticker tickerStepper;
Ticker tickerLvgl;

Adafruit_TFTLCD_16bit_STM32 tft(NC);

// main() runs in its own thread in the OS
int main()
{
    tft.begin();
    tft.setRotation(1);

    while(1) {
        tft.fillScreen(RED);
        ThisThread::sleep_for(1000);
        tft.fillScreen(GREEN);
        ThisThread::sleep_for(1000);
        tft.fillScreen(BLUE);
        ThisThread::sleep_for(1000);
    }
}

when I compile the Adafruit graphics, I get a warning like this:

Compile [100.0%]: Adafruit_TFTLCD_16bit_STM32.cpp
[Warning] stm32f4xx_hal_rcc_ex.h@2060,48: conversion to void will not access object of type 'volatile uint32_t {aka volatile long unsigned int}'
[Warning] stm32f4xx_hal_rcc_ex.h@2067,48: conversion to void will not access object of type 'volatile uint32_t {aka volatile long unsigned int}'
[Warning] stm32f4xx_hal_rcc_ex.h@2320,46: conversion to void will not access object of type 'volatile uint32_t {aka volatile long unsigned int}'

digging into that, I find:

That could be a problem when the compiler produces different code. When my code above does produce a filled color screen we can try a workaround for the

I’m not having that problem, and I am using the HAL library in my code (linked via mbed-os, I believe), so I don’t know what to do here.

can you try this, in the beginning of .l\libs\Adafruit_TFTLCD_16bit_STM32-master\src\Adafruit_TFTLCD_16bit_STM32.cpp

int fsmc_lcd_init() {

  // enable peripherial clocks
  //__HAL_RCC_GPIOD_CLK_ENABLE();
  //__HAL_RCC_GPIOE_CLK_ENABLE();
  //__HAL_RCC_FSMC_CLK_ENABLE();

  volatile uint32_t dummy;
  RCC->AHB1ENR |= RCC_AHB1ENR_GPIODEN;
  dummy = RCC->AHB1ENR;
  RCC->AHB1ENR |= RCC_AHB1ENR_GPIOEEN;
  dummy = RCC->AHB1ENR;
  RCC->AHB3ENR |= RCC_AHB3ENR_FSMCEN;
  dummy = RCC->AHB1ENR;

the problem maybe a combination of the HAL macro and gcc with C++14 option.