Same problem - error code coming up.
I’m ordering a debug probe (USB-TTL/RS232) to see if I can track down the issue.
I can’t imagine any LvGL code much simpler than the hello world example, so I’ll keep trying to track down the issue.
Thanks again for all of your help!
what error code do you mean, a compiler error in the hello_world? Check my repo, there is a lv_ex_conf.h file for this settings. There the tutorial code can be enabled:
The concept with the conditional code enabling is used widely in lvgl.
Or do you mean the runtime error with the blink code?
This can be caused also by the printf that prints on the serial line. It uses the Serial class and this is also derived from Stream. So the root of the problem is somewhere in the fdopen() or setbuf() call to the newlib that gcc uses.
When the debugging with eclipse is possible it is also easier to trace the problem.
I mean the blink code.
I’ve tracked down the error to this line:
threadIO.start(callback(treadFnIO));
I used several tft.fillScreen() calls with different colours to track the error, but I’ve found where the error is occurring.
I’m guessing that the Thread class is from mbed. I’m going to investigate that when I have a chance. I need to go teach a class in a few minutes.
you can send me the .elf file and the main.cpp, then it is easy to check the call stack.
Have you tried again to compile with eclipse? Is the eclipse installation using the same toolchain or the gnuarmeclipse installation?
For windows, I use the toolchain from the ARM website: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
There is also a Mac version.
I’m using the same compiler - that’s where I downloaded it.
The only way I can send you the files is to include them here. Here are the main.cpp file adapted from your Test-lvgl and the resulting debug binary.
jojo.zip (84.9 KB)
That is the big example, I guess also the printf is causing a problem. Please try a simple main with printf(“hello”); and then a blinky Loop. Will this show also die blink code?
The printf seems to be fine. I just created a simple blinky that turns the screen red and then uses a printf to output to the serial line (not that I can see the serial data - I am waiting for my debugger to arrive).
The other example was intended to show where the lvgl code was causing an error.
mbedblinky2.zip (39.9 KB)
This does not cause the error. The Thread.start is causing the error. I’ll try to make a smaller example without the lvgl code in it to see if it’s truly the mbed-os code or if there is a problem with the lvgl code as well.
Here is an example that uses the mbed Thread class and causes the error on the start as evidenced by the fact that the screen turns red but not green (the green happens after the thread starts). There is no lvgl code in here, but it seems that the problem is in mbed-os.
mbedthreadtest.zip (41.5 KB)
Thanks again for all of your help.
I’m going to try to install these dev tools on my windows machine at work and see if I can generate working code - try to eliminate the other difference we have. I believe you said you’re using a Windows machine.
I moved the code to the online mbed compiler and it works just fine. I’m going to check a Windows machine tomorrow.
For checking I need the .elf file because this contains the debug symbols, the .bin does not.
I’ve some more clues, but I must check this later.
The first mbedblinky2 that I checked with the debugger, I have traced further. The problem is that ::fdopen(3, “w+”); does return NULL and not a valid file handle. The first handles a preserved for STDIN, STDOUT and STDERR, then there should be 16 or more avaliable handles. The NULL is returned als for the predefined handles. So this may be an initialization problem.
Another thing is my custom target for the STM32F407VE. When I started this, there was a similar board, called ARCH_MAX. But this had an MCU with 1 MB flash instead of 512 kB. Also the pin definitions for LED and other stuff was different.
Now, Mbed has a definition for the STM32F07E and it looks better than mine. I rewrite my custom target and use the Mbed definitions, they will be better up to date.
For now, you can use ‘mbed compile -m ARCH_MAX’ to use this, then my custom_target will not be used.
Note, the definitions for LED1 and LED2 are different, you must use own defs or PA_6 / PA_7.
see also: https://os.mbed.com/users/hudakz/code/STM32F407VET6_Hello/shortlog/
Maybe you have used this already when using the online compiler.
I tried that (changing LED1, etc) on the online compiler and it worked.
Here is the elf file, the bin, and the main.cpp.
mbedthreadtest.zip (543.2 KB)
I’ve installed the tools on my Windows machine at work and it’s compiling now. (It’s slower than my Mac). I have to go teach a class now. I’ll let you know how it works after class.
Your code works perfectly when I compile it on a Windows machine.
The problem is clearly in the Mac compiler, so at least I can work on my project now.
Thank you so much for your help! Now I need to get the people who made the compiler to fix their bugs.
we are getting closer to the problem.
I did not understand everything in the Mbed retargeting code, so I stepped further. The fdopen() function exits twice with different arguments, a little bit confusing.The fdopen(Filehandle,) calls fdopen(int,). The second is calling the c-runtime fopen(). This function fails and sets errno=12, which means ENOMEM 12 /* Not enough space */ So it looks like some problem with the memory interface to the c-library. I guess that something like malloc() will also fail.
Have you tried if it makes a difference when you compile with ‘-m ARCH_MAX’ on your Mac?
I think I’ve got it
There is a difference in the used linker scripts. This is an issue with the magic Mbed build system, nothing to blame gcc or lvgl. The crazy thing is that in my opinion the Mac does it the correct way and the build system under windows not 
in .\custom_targets\TARGET_STM32F4\TARGET_STM32F407xE\device\TOOLCHAIN_GCC_ARM\ is a custom linker script, different from the mbed-os/targets/. Compiling under MacOS is using this custom (possibly wrong or no more matching to actual mbed-os) linker script, compiling under windows is using the mbed-os linker script.
The easy solution must be to delete the complete directory ./custom_targets/TARGET_STM32F4/TARGET_STM32F407xE/device and also the file objects.h there.
Then building under MacOS will only find the correct linker script.
To verify, I have done the reverse test now: using the wrong linker script is producing, Tada: mbed_die and the error message ‘Stream obj failure’
This prooves that you can’t do enough tests.
Well, your fix works perfectly on my Mac. I can compile the code and it works! I even redownloaded your original code without the changes we made and ONLY removed the device directory and the objects.h file and the compiled code works perfectly.
Thank you so much for your help! I can now develop this project using LittlevGL instead of having to draw the GUI manually.
Thanks. I’ve learned also more about mbed-os. This was a very hidden trap now, but in general mbed has a very good quality now. The people at ARM are doing a great job. I think there is also a headquarter in Texas.
I will continue updating my repo, I have also a SD card driver that I need also.
But now, happy coding with lvgl, that was the original subject
Now that the issue is solved, do you need some help with that SD card driver software? I am going to need it for my project.
I found working code
https://os.mbed.com/users/hudakz/code/STM32F407VET6_SDCard/
The only thing I don’t like is that I need to use up 8 pins to do it. I’m going to play with the code to see if I can eliminate the need to take up 8 pins, because I’m going to need pins for my project.
I hope this helps you.
I have written a SDIO driver that acts as a Mbed Blockdevice and works with the MBed filesystems. This code was written a year ago, the I had to do other things. Now I need to test if it still works with the actual version. Compiling is fine already.
My driver also uses the fast SDIO, this is also the connected to the onboard SD card slot. The pins that are used for this hardware have no alternative SPI functions. In that case, you would need to use a software SPI and that would be very slow for a SD card. I’m also not sure that the pins for the onboard slot are also available on the external header pins.
There is a repo to collect File system interfaces for LittlevGL.
If you have a working code with mBed a Pull request would be very welcome in this repo
ok, I will try. At first sight, the interfacing should be easy because the posix file functions are available and the assigning to the lvgl interface did not complain when I set LV_USE_FILESYSTEM = 1. I have not checked if there is a sample code for using some images, is there one that I can use for testing?
@querist:
I had a look at the page from Zoltan, he uses the older SDFilesSystem implementation for mbed2. This is using the SPI interface and need additional wires bescause SPI is not connected to the SD slot on board. This is not necessary with using the SDIO component.
Hi Johannes,
Is that SDIO driver in the LvGL code I already have? That would be great.
Thanks,
-glyn
Just updated my repo, very hot
The integration works like a charm. This creates the filesystem in Mbed:
// Physical block device, can be any device that supports the BlockDevice API
SDIOBlockDevice bd;
// File system declaration
FATFileSystem fs("sda", &bd);
to read files from the drive, standard C or C++ functions can be used, that is some magic by Mbed. So I tried tutorial/images and the only thing I had to adjust was the filename, prepend the suffix ‘sda’ instead of ‘./’ and I put the files into the root instead of the directory tree. So just copy everthing from the lvgl/examples/tutorial/6_images into the root of a SDcard with FAT32 format. The tutorial code will show the red flowers on the left, loaded from images linked to the binary. And on the right the images loaded from SDC.
Mbed allows also multiple blockdevices and filesystems, with another driver it could read files from the additional SPI flash on the board. So there are plenty of possibilities now.
Wow, the flowers can be moved with the touchscreen. Pretty cool, @kisvegabor!
Fantastic! Thank you again. This will be very useful. I don’t have my board with me at the moment, so I’ll have to test this at home and then read up on the FATFileSystem object so I can obtain directory listings, etc.
Thank you for your help!