Issue with latest X-CUBE-DISPLAY
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-10-10 9:09 AM
I'm using a NUCLEO-L476RG with a X-NUCLEO-GFX01M1 (MB1642-DT022CTFT-B01). With X-CUBE-DISPLAY v2.0.1, it works fine, but with v2.2.0, after reset, the display just flickers. Any ideas?
Solved! Go to Solution.
- Labels:
-
STM32L4 Series
-
TouchGFX
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-10-28 3:45 AM
Hello,
Yes indeed there is a bug with 2.2.0 when using DMA.
The BSP_[LCD|MEM]_WriteDataDMA was unlocking the APIs at the exit of the API call so transfers could overlaps.
To continue you work until getting the new release which will provide the fix, you can remove call to
MEM_OS_Unlock(Instance); at the end of these functions
lcd_io.c : remove line 462
mem_io.c : remove line 363
Or just disable DMA from the test application and recompile.
app_display.c:
#define USE_MEM_DMA 1
#define USE_LCD_DMA 1
to
#define USE_MEM_DMA 0
#define USE_LCD_DMA 0
Best Regards,
Karim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-10-10 9:50 AM
Check #defines, or compiler command line options.
Check it's building for the right screen and pins
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-10-10 10:26 AM
This was done using the pre-compiled binaries. They are built for the target Nucleo board and Expansion board.
This works:
\ST\X-CUBE-DISPLAY_v2.0.1\Projects\NUCLEO-L476RG\Applications\GFX01M1_HelloWorld\Binary\GFX01M1_HelloWorld.hex
This does not:
\ST\X-CUBE-DISPLAY-V2_2\Projects\NUCLEO-L476RG\Applications\GFX01M1_HelloWorld\Binary\GFX01M1_HelloWorld.hex
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-10-10 1:22 PM
Yes does sound like a problem.
But you'll likely have to rebuild and check what's happening with more specificity and detail, to establish what's actually broken. Probably diff the source to see what changed between versions.
Default pin usages may have changed, support for the M2 display/board also likely added.
Not sure the owner's of the project are active in the forum. If you can establish what the problem is you might get someone to fix or address it.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-10-28 3:37 AM
Hi @paswenson​,
As suggested by @Community member​, if you can identify the exact issue, this will be very helpful.
Based on your description, there is an issue and I reported it internally.
Internal ticket number: 137684 (This is an internal tracking number and is not accessible or usable by customers).
I'll keep you informed when I get an answer.
-Amel
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-10-28 3:45 AM
Hello,
Yes indeed there is a bug with 2.2.0 when using DMA.
The BSP_[LCD|MEM]_WriteDataDMA was unlocking the APIs at the exit of the API call so transfers could overlaps.
To continue you work until getting the new release which will provide the fix, you can remove call to
MEM_OS_Unlock(Instance); at the end of these functions
lcd_io.c : remove line 462
mem_io.c : remove line 363
Or just disable DMA from the test application and recompile.
app_display.c:
#define USE_MEM_DMA 1
#define USE_LCD_DMA 1
to
#define USE_MEM_DMA 0
#define USE_LCD_DMA 0
Best Regards,
Karim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-10-28 9:12 AM
Great, thanks for the update.
