samples: subsys: input: draw_touch_events: fix overflow in clear_screen loop

[CharlesDias]

Problem: On STM32U5G9J-DK1 + st_lcd_dsi_mb1835, the sample could BUS FAULT with SCREEN_WIDTH_TO_CROSS_DIM=25 and show only a horizontal line with 20.

Root cause: The tile buffer BPP is derived from the devicetree pixel format (e.g., RGB888 = 3 BPP), but the driver may be using a different current pixel format.

Fix: Explicitly set the driver pixel format to the DT-selected format at init.

EDIT:
The clear_screen loop used fixed-size tiles (CROSS_DIM). When WIDTH/HEIGHT aren’t multiples of CROSS_DIM, the right/bottom tiles exceeded the panel bounds, causing the driver’s row copy (memcpy) to write past the framebuffer and fault.

Fix: clip only the edge tiles

• width = min(CROSS_DIM, WIDTH - x)
• height = min(CROSS_DIM, HEIGHT - y)
• pitch remains CROSS_DIM (source stride)
• buf_size = width * height * BPP

Prevents out-of-bounds writes on edge tiles.

Related with:

• boards: shields: st: enable the touch input on st_lcd_dsi_mb1835 #98717

document_4915927358348723745.mp4

Fixes #98922

[cfriedt]

@CharlesDias - can you link a bug report to this issue? It's required for all bug fixes post RC2.

[CharlesDias]

Hi @cfriedt.

I opened the bug:

• samples: subsys: input: draw_touch_events: BUS FAULT on STM32U5G9J-DK1 + st_lcd_dsi_mb1835 #98922

[CharlesDias]

Hi, @fabiobaltieri, @faxe1008, and @cfriedt.

I've changed this fix to DRAFT because, although this modification seems to have resolved the problem, I suspect the root cause may be something else. I am currently investigating further. I apologize for the inconvenience!

[CharlesDias]

After further investigation, I found that the BUS FAULT was caused by the clear_screen loop writing past the framebuffer. When CROSS_DIM does not evenly divide the panel WIDTH/HEIGHT, the last tile on the right/bottom extends beyond the framebuffer row/column.

Backtrace

#12 0x0800a3ea in memcpy ()
#13 0x08007ece in stm32_ltdc_write (dev=<optimized out>, x=<optimized out>, y=<optimized out>, desc=0x20000000 <buf_desc>, buf=0x800aff4 <buffer_cross_empty>) at /home/charlesdias/zephyrproject/zephyr/drivers/display/display_stm32_ltdc.c:233
#14 0x0800056e in display_write (buf=0x800aff4 <buffer_cross_empty>, desc=0x20000000 <buf_desc>, y=190, x=399, dev=<optimized out>) at /home/charlesdias/zephyrproject/zephyr/include/zephyr/drivers/display.h:288
#15 clear_screen () at /home/charlesdias/zephyrproject/zephyr/samples/subsys/input/draw_touch_events/src/main.c:93
#16 0x08000694 in main () at /home/charlesdias/zephyrproject/zephyr/samples/subsys/input/draw_touch_events/src/main.c:156

Solution:
For each x,y tile, it now creates a local descriptor with:

• width = min(CROSS_DIM, WIDTH - x)
• height = min(CROSS_DIM, HEIGHT - y)
• pitch remains CROSS_DIM (source stride in pixels)
• buf_size = width * height * BPP

This guarantees we never copy past the framebuffer boundaries for tiles at the right/bottom edges.

Additional fix (pixel format)
Additionally, the zephyr_lcd_controller pixel-format did not match the driver configuration, which expects PANEL_PIXEL_FORMAT_ARGB_8888.

Solution (pixel format)
Set the zephyr_lcd_controller pixel-format to PANEL_PIXEL_FORMAT_ARGB_8888 to match the driver configuration.

[CharlesDias]

This solution was validated in:

• STM32U5G9J-DK1 with
  • PANEL_PIXEL_FORMAT_RGB_888 and CONFIG_STM32_LTDC_RGB888
    • SCREEN_WIDTH_TO_CROSS_DIM equal to 20, 25, and 31.
  • PANEL_PIXEL_FORMAT_ARGB_8888 and CONFIG_STM32_LTDC_ARGB8888
    • SCREEN_WIDTH_TO_CROSS_DIM equal to 20, 25, and 31.
• STM32H7B3I-DK
  • PANEL_PIXEL_FORMAT_RGB_565 and CONFIG_STM32_LTDC_RGB565
    • SCREEN_WIDTH_TO_CROSS_DIM equal to 25.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[avolmat-st]

I discovered now this PR and had a look at it. I know it is now merged but am wondering if the fix is actually done at the right place here.
My point is that, due to a miss calculation of the offset in the sample app, this was leading to a memcpy (done by the LTDC driver) going past the framebuffer area (is my understanding correct ?).

Having the application not trying to do invalid stuff is indeed correct, but that doesn't seem suffisant I think and the driver (LTDC) should have been blocking such memcpy as well in the first place.

Looking at the diff, it seems that display_write return value isn't check in this sample so, shouldn't fixes be more like:

1. sample display_write call should be correct (done in this PR)
2. sample display_write call return value should be checked (to be done)
3. ltdc display_write should prevent memcpy which would end up copying outside of the framebuffer area.

This draw_touch_events is just a sample, I think the 3rd point is very important here.

[avolmat-st]

I'm going to open a new PR in order to add display API return value check as well as protect the LTDC driver memcpy.

[CharlesDias]

I'm going to open a new PR in order to add display API return value check as well as protect the LTDC driver memcpy.

Hi @avolmat-st. Thanks for your inputs!

If needed, I can test your new PR on my STM32U5G9J-DK1 board. Please let me know. Thank you!

[avolmat-st]

I'm going to open a new PR in order to add display API return value check as well as protect the LTDC driver memcpy.

Hi @avolmat-st. Thanks for your inputs!

If needed, I can test your new PR on my STM32U5G9J-DK1 board. Please let me know. Thank you!

Thanks @CharlesDias, I've just raised the PR #99166 which tackles this point. Could you recheck your side with your setup, and also for the test purpose only revert your fix commit in the sample in order to ensure that the LTDC driver is properly protecting this case ?

[CharlesDias]

Thanks @CharlesDias, I've just raised the PR #99166 which tackles this point. Could you recheck your side with your setup, and also for the test purpose only revert your fix commit in the sample in order to ensure that the LTDC driver is properly protecting this case ?

Hi @avolmat-st , below is the message log regarding your suggested test. Since we got an error, the application was finished.

*** Booting Zephyr OS build v4.3.0-rc3-3-g67ec1bfe1e3d ***
[00:00:00.632,000] <inf> sample: Touch sample for touchscreen: st1633i@70, dc: display-controller@40016800
[00:00:00.634,000] <err> display_stm32_ltdc: Rectangle does not fit into the display
[00:00:00.634,000] <err> sample: Failed to write to display (error -22)
[00:00:00.634,000] <err> sample: Failed to clear the screen

[avolmat-st]

Thanks @CharlesDias, I've just raised the PR #99166 which tackles this point. Could you recheck your side with your setup, and also for the test purpose only revert your fix commit in the sample in order to ensure that the LTDC driver is properly protecting this case ?

Hi @avolmat-st , below is the message log regarding your suggested test. Since we got an error, the application was finished.

*** Booting Zephyr OS build v4.3.0-rc3-3-g67ec1bfe1e3d ***
[00:00:00.632,000] <inf> sample: Touch sample for touchscreen: st1633i@70, dc: display-controller@40016800
[00:00:00.634,000] <err> display_stm32_ltdc: Rectangle does not fit into the display
[00:00:00.634,000] <err> sample: Failed to write to display (error -22)
[00:00:00.634,000] <err> sample: Failed to clear the screen

So this is happening if the sample is not fixed right (aka your patch is reverted) ? If so, then this is good I think and shows that the LTDC is able to catch incorrect write call. That is the purpose of my patch. Thanks for the check.

[CharlesDias]

So this is happening if the sample is not fixed right (aka your patch is reverted) ? If so, then this is good I think and shows that the LTDC is able to catch incorrect write call. That is the purpose of my patch. Thanks for the check.

Exactly! When I revert my patch, the LTDC gets the issue.