Binary translations from external flash

[moredatalesscenter]

The example in the help link below shows loading loading the translation from a file, but not from memory addressed external flash. This is what I'm using and mem_addr contains the expected data. The second argument to setTranslation() is a void pointer, so is uint8_t * correct type to use? Does the pointer always have to remain in scope, i.e. I can't switch back to block mode?

uint8_t *mem_addr;

OSPI_NOR_EnableMemMappedQuadMode()

FrontendApplication::FrontendApplication(Model& m, FrontendHeap& heap)

  : FrontendApplicationBase(m, heap)

{

OSPI_NOR_EnableMemMappedQuadMode();

mem_addr = (uint8_t *)(OCTOSPI1_BASE);

Texts::setTranslation(GB, mem_addr);

Texts::setLanguage(GB);

}

https://support.touchgfx.com/4.18/docs/development/ui-development/touchgfx-engine-features/using-binary-translations

[Tesla DeLorean]

Block and Memory Mapped can't exist concurrently.

The memory/abstraction is frequently reset to switch back, but it should be possible to disengaged more simply.

I'd expect the pointer to fault or fail if memory mapping is disabled, and the OSPI unit won't acknowledge the memory decode.

[moredatalesscenter]

Are you saying that TouchGFX requires it to stay in memory mapped mode forever? Is the code correct to make use of the stored translation data, after invalidating the root container?

[Tesla DeLorean]

I'm saying the MCU needs to remain in Memory Mapped mode if you expect to touch the OSPI 0x90000000..0x90xxxxxx memory region. And you'll need to switch out of it to use direct commands.

What TouchGFX expects, I don't know. The pointer will fail outside of memory mapped mode, but it is enabled when it exits the function.

[moredatalesscenter]

OK thanks, it doesn't sound feasible as I also need to use the flash in block mode (for a file system). If I use the method of loading a file at runtime from the help link, is there any way to reduce memory usage? I want to avoid having a large buffer in RAM, as the translation is large.

[Tesla DeLorean]

The STM32 is poorly architected for that type of mixed use, and you'd likely need to use a mutex or semaphore to manage ownership and mode of the memory.

The HAL has historically made the transition back more difficult than actually necessary, basically changing the State so that direct commands fail. It should be possible to disengage without a complete re-initialization.

If you can do your file system stuff first, that would be ideal.

Otherwise perhaps consider eMMC for mass-storage, as it's much faster than NOR Flash, and better tailored to the task, including block management, erase, wear leveling, and error correction, etc.