Apologies if you think this should be on a CPP forum rather than LVGL but i’ve been banging my head against this for weeks and struggling with this weird inconsistency. Just wanted to check there is nothing fundamental I’m missing on the LVGL end.
This code works perfectly to take the text on a button and load a midi file of the same name.
const char *FileToLoad;
char TuneName[100];
String FileName
strcpy(TuneName, lv_list_get_btn_text(obj));
FileName = TuneName;
FileName += ".midi";
FileToLoad = FileName.c_str();
SMF.load(FileToLoad);
However it only works when the text on the button is below 28 character. Any more and it load process errors, file not located.
On my serial monitor it does looks like the full filename is getting through to the SMF.load() function just fine. Could be a buffer issue thought the guy that wrote the SMF library but here is where it gets weirder…
If i manually push a long filename by replacing
strcpy(TuneName, lv_list_get_btn_text(obj));
with
strcpy(TuneName, "My Lovely Audio File With A Longer Filename");
then the load works just fine. As i missing something fundamental about the text that comes off the button? Carriage returns? Null pointers? Why is it working fine for smaller filenames? 
Button text is allocated dynamically, and your buffer is already 100 characters long, so overflow doesn’t look like an issue.
Is SMF.load asynchronous? Does the function which calls it return and possibly deallocate FileName before SMF.load finishes using that string? I rarely use C++ strings but I think c_str() just returns a pointer to dynamically allocated memory. That would explain why the serial monitor doesn’t show an issue, since it would print the value before the function returns.
1 Like
After tears (almost), swearing (lots), multiple fiverr debug cpp experts (that couldn’t work it out) and a few long weeks of frustration… I solved this issue and it was somewhat lvgl related.
YUUUUSSSS
OK So here is where it was tripping up…
Months ago I had found the initial setting of #define LVGL_TICK_PERIOD 100 a little sluggish so i updated to #define LVGL_TICK_PERIOD 20. Now the interface feels snappy and great with no side effects on performance elsewhere. At some point in my noodling I updated this further to #define LVGL_TICK_PERIOD 2 with no ill effects so i forgot about it.
A few weeks ago I started to add the full extended dataset to my program, pulling small files off an SD card. The file with long names start to trip up my code but i cannot see what is tripping up and where. No errors from the file handler or the sd card handler, interface works just fine but the file isn’t processing properly…
Today I was working through my code bit by bit and just on a whim reset back to #define LVGL_TICK_PERIOD 20 and shazzam as if by magic all of my files now work including the long filenames.
I am nowhere near smart enough to know what is really going on here. I can only say I am thankful for finding it and for others in the future if you are getting mysterious happenings, try noodling with the tick period, you might be suprised.
Off for a strong cup of tea.
Thanks heaps for your help and support, you’re amazing.
Hmm. It’s great that the issue is solved (for now), but the solution seems a bit suspicious. 
Are you using an OS? If changing the tick period solves the issue, this would suggest that the real issue lies in the timing of interactions between threads, meaning that it could reappear at any point in the future. Maybe you’re missing a mutex somewhere?
1 Like