246 views
in GUI Development by

I'm seeing a hard fault in EwExecuteTasks when drawing certain screens.

The fault appears to be because the task list has an invalid pointer in it.

This is being called from EwFlush when our mail loop calls EwProcess.

The MCU is a STM32U599 and we are using the stm32f4 V11 framework.

This only happens in two use cases, always the same screens.

These are the compiler settings.

-mcpu=cortex-m33 -std=c11 -g3 -DUSE_HAL_DRIVER -DEW_USE_FREE_RTOS=1 -DEW_USE_EXTERNAL_FLASH=1 -DEW_CPU_LOAD_MEASURING=1 -DEW_MAX_SURFACE_CACHE_SIZE=0x400000 -DEW_MAX_GLYPH_SURFACE_WIDTH=256 -DEW_MAX_GLYPH_SURFACE_HEIGHT=256 '-DEW_BITMAP_PIXEL_SECTION_NAME=.SectionEwResource' '-DEW_FONT_PIXEL_SECTION_NAME=.SectionEwResource' -DEW_FRAME_BUFFER_COLOR_FORMAT=EW_FRAME_BUFFER_COLOR_FORMAT_RGB888 -O0 -ffunction-sections -Wall -fmessage-length=0 -include stm32u5xx.h -fstack-usage  -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb

I'm a bit baffled by this.

I added some prints to the function and am seeing this:

task=90740c08 ssue=9073e5dc
task=90740bf4 ssue=9073e5dc
task=90740be0 ssue=9073e5dc
task=68581e9a ssue=9073e5dc
 

Where the last task before the hardfault is an invalid pointer.

There are no other threads using an Ew API calls, we've made sure all other threads send messages to the main GUI thread to perform any UI updates.

 

1 Answer

+1 vote
by

Hello,

first of all, it seems to me that you are using parts of the project from older versions than V11. Meanwhile (also in V11) most of the options are not set within the makefile or project file. Instead, the file ewconfig.h is used to configure the project.

Anyhow, what STM32U599 target are you using? Is this a custom specific hardware or a discovery board?

I am asking, because the reported error seems to be more related to some unreliable memory content than to a bug within EwExecuteTasks(). Have you tried the SDRAM memory test? Btw, are you using SDRAM or some RAM via QSPI?

Furthermore, does the problem change, when you change the compiler optimization level?

Best regards,

Manfred.

by
Hi Manfred,

All the EW runtime from the old version (9) has gone, we're using just the V11 one - we've modified the BSP to remove the 'two halves' update on DSI as it's no longer needed on the 599. (Advice from ST's engineers)

SDRAM - 4MB on Osctospi

FLASH.- 16MB on Octosapi (But running as Quad SPI)

We've done tests on both SDRAM and FLASH.

The board is a custom board. We've modified the ewconfig.h file to use the options we want. The project is a port from a board using a F4 - apart from the SDRAM on Octospi and a few port assignments, they are identical boards.

Good point on the optimisations, I recall from 3 years ago we modified these settings for the F4 board and found that at certain levels we saw problems.

I just discovered that this problem has been introduced by the addition of two 'trace' statements - one at the start Application::Init and one at the end. Removing these causes the problem to go away. Of course, this doesn't mean the problem has 'gone away', but that it is being masked.
by
Hi,

what compiler are you using?

I assume there is some issue in the combination of SDRAM via Octo/Quad-SPI and FLASH via Octo/Quad-SPI...

If you need more information, you as a customer can use our direct support via support@embedded-wizard.de.

Best regards,

Manfred.
by

Hi,

I just want to come back to this issue. Are there some news on this topic? Do the data read accesses from RAM or FLASH provide reliable data - especially in case you do byte or word access?

Just for others reading this thread: the AN5050 from ST describes a lot of details about Octo-SPI interface on STM32 microcontrollers. 

Best regards,

Manfred

by
The memory accesses did prove reliable - the  problem went away, but has now returned again.

I will have a look at the document you referenced.
by
Further investigations:

The current 'Task' data in EwExecuteTasks is getting corrupted when a call is made to CopySurface (Which performs a DMA transfer - from EwBspGraphicsCopyBlend.)

When returning from this function the Task data is corrupt so the ->Next pointer is pointing to an out of memory range address so the function crashes.

So it looks like there's some sort of issue with the PSRAM (On OctoSPI) to me - the parameters for the transfer are fine.

This always happens  at the same place.
by
Maybe the errata sheet for STM32U5 can give you some additional hints - there are a couple of issues noted in the context of OctoSPI. No idea if this is relevant for your target.
by
Thanks, I have been looking at that.

It appears that Octospi has issues that could indeed cause the problems I am seeing.

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint

...