External Flash assets updates while touchgfx is running

[KHeye.1]

Hi,

I am implementing a product that uses touchgfx and needs to support remote updates. As the downloading of the assets is slow (~30min), the updated assets to be written into external flash must be written while touchgfx is running.

I know that other similar questions of writing to external flash in memory mapped mode in this forum get answers of "just dont do that" or "work around that" but I have been unable to find any other viable solution.

Currently, my write process is: stop touchgfx task, stop ltdc interrupt, stop dma2d interrupt, wait until dma2d finishes, reinit qspi (exit mem map), write to ext flash, enter mem map, enable ltdc interrupt, enable dma2d interrupt, and finally resume touchgfx task. If touchgfx is idle (i.e. a static screen) touchgfx survives, but if the screen is non static touchgfx stops working and somehow locks out access to the debugger core in the mcu (rtos and other code still runs).

Has anyone had any luck in this? And specifically to the touchgfx devs, has this been attempted internally?

Cheers,

Kevin

[Tesla DeLorean]

Do you provide any other memory in which to stage the update? ie eMMC, SD-Card, USB MSC, SDRAM, ..

Does the update go into a different location within the QSPI?

Can you use touchfgx in a way that it requests the resources it wants to pull from external memory, rather than have it be memory mapped? ie via a file system type method

[KHeye.1]

I am using a single external flash with qspi with no other external flash options. It is being written into a different location and then moved during a modified SBSFU.

Unfortunately, we do not have the ram to cache bitmaps in ram and cpu overhead to do non memory mapped.

[RetroInTheShade]

Hi Kevin,

Can I please confirm that you are only varying contents of image assets? Size and format not changing?

Cheers

[MM..1]

When you properly suspend TGFX i mean error is in other place. You need check why code hang.

Use debug leds or uart messages ...

[KHeye.1]

As I am updating both the code and the assets, I do not see how this would matter but no I am currently not planning on having any of these limitations.

[KHeye.1]

This is not a touchgfx suspension issue as I am able to stop and start touchgfx without any problems (with the ltdc interrupt).

The problem is disabling memory mapping and reenabling memory mapping that is causing issues inside of touchgfx code that halts the touchgfx task. All other tasks are working properly.

[RetroInTheShade · Accepted solution]

Hi Kevin,

I misunderstood your objective and thought you were trying to update the live asset region (ambitious!).

We have similar requirements and I have been investigating options.

I have had success periodically dropping flash out of / into memory mapped mode on the STM32F469.

I have not put it though serious testing, but have inserting a page read/write between every frame while forcing constant changes of screens/images. I've successfully transferred many MB onto the flash without issue.

My process is:

1. disableInterrupts() and block touchgfx process when endFrame() called to confirm frame generation complete
2. exit memory mapped mode by calling HAL_QSPI_Abort().
3. Read / Write Flash as required
4. enable memory mapped mode again
5. enableInterrupts()
6. continue

Some caveats which may be relevant...we are running in video mode with double buffers which will sidestep some of the intermediate logic. For my initial test, the flash read/write was using blocking functions.

Given the general discussion around the topic, I'm approaching with caution and have alternative options. At this stage, I haven't found anything to suggest it is not a viable solution.

What processor are you using?

Cheers.

[KHeye.1]

Hi,

Thanks for letting me know this is doable! We are using the STM32L4R9 also in double buffered video mode.

Are the interrupts that you disable just ltdc and dma2d?

Cheers,

Kevin

[RetroInTheShade]

Yes - we just disable the ltdc, dma2d.