New STM32_ExtMem_Manager driver for STM32H7S7 won't erase/write sectors

[nico23]

I'm using an STM32H7S78-DK board and I have a part of the firmware that, from the boot, updates the FLASH from a .bin inside an SD card

The code is pretty simple as I loop the FLASH comparing every sector with the one in the SD card and, if different I erase the internal flash sector and write the new one.

Everything was working correctly until a update the code via CubeMX

The read seems to still working

if (EXTMEM_Read(0, fw_offset, flash_buf, br) != 0)

but as soon as I do the

if (EXTMEM_EraseSector(0, fw_offset, FLASH_SECTOR_SIZE) != 0)

I got an error

The crash happens in

 if (EXTMEM_DRIVER_NOR_SFDP_OK != EXTMEM_DRIVER_NOR_SFDP_SectorErase(&extmem_list_config[MemId].NorSfdpObject,
 local_address, sector_type))
 {
 retr = EXTMEM_ERROR_DRIVER;
 }

I've rolled back just the driver in the STM32_ExtMem_Manager, and everything started working again

I've noticed that quite a few files have been changed, including the addition of #define EXTMEM_DRIVER_CUSTOM     0

In the conf_template, it could be helpful to understand what's changed. Everything else has stayed the same. Where should I look?

 

Another thing that has changed, if it is useful to understand the changes, is that in stm32_sfdp_driver.c the 

#define ERASE_COMMAND 0x60 has been deleted

 

What could be the issue?

 

I've just found out that I've updated from SLA0044 Rev5/February 2018 to SLA0044 Rev6/October 2025

[Guenael Cadier]

Hi @nico23 
I guess you are now using ExtMemManager v1.5.0 right ?
And that you were previously using v1.3.0 ?

The 1.5.0 version contains addition of a new driver inside EMM, called CUSTOM. It is fully separated from the NOR_SFDP driver, so should have no impact on the use of NOR_SFDP driver, as in your configuration.

ERASE_COMMAND define was removed in v1.4.0 and has been replaced by SFDP_DRIVER_ERASE_CHIP_COMMAND which is now located in stm32_sfdp_driver_type.h (same value).
(this define corresponds to the full chip erase instraction, so should not be used when performing EXTMEM_DRIVER_NOR_SFDP_SectorErase().)

If you debug inside EXTMEM_DRIVER_NOR_SFDP_SectorErase() what is the command and type of erase operation that will be executed ?
What is the error code returned by EXTMEM_DRIVER_NOR_SFDP_SectorErase() ?

Regards

[nico23]

Hi ​@Guenael Cadier 

for some reason your previous post was deleted by the migration (I guess)

I have increased the CTSACK and HEAP in my .icf from 

define symbol __ICFEDIT_size_cstack__ = 0x1000;

define symbol __ICFEDIT_size_heap__   = 0x1000;

to

define symbol __ICFEDIT_size_cstack__ = 0x4000;

define symbol __ICFEDIT_size_heap__   = 0x2000;

but same issue

[Guenael Cadier]

Hi ​@nico23 
Thanks for recalling/recreating thread history.

Indeed, your original stack/heap sizes looks sufficient for running EMM MW in a classic application project. My original idea for requesting you to test extended sizes was related to your previous feedback, i.e. that you get local_address=0x24004557 when calling function EXTMEM_DRIVER_NOR_SFDP_SectorErase() with fw_offset = 0 as  EXTMEM_EraseSector() input parameter.
I don’t have any clue on how this could happen. Is there a project running on  STM32H7S78-DK board that you could share ?
Regards

[nico23]

feel free to check your DMs for the full project

[nico23]

I’ve just rolled back to version v1.1.0 and everything started to work perfectly (It seems I wasn’t using v1.3.0 before but v1.1.0)

strange

[Guenael Cadier]

Hi ​@nico23 

I made a basic test using your project : 
- Add some calls to EXTMEM_EraseSector in main.c prior mounting of SD volume
- Skip all SD related stuff and configure a dummy fw content to be written in flash using calls to EXTMEM_EraseSector / Write
In all those tests, erase operations at fw_offset 0 are properly executed (no error).
These experiments are done in main_GCA.c and fw_update_GCA.c (compared to original main.c and fw_update.c), i will send you those files using DM.

I come back on your status where you observed local_address=0x24004557 befrore the error.
local_address is initialized from the Address argument, then only updated by adding sector_size in the loop at stm32_extmem.c:688. 
Sector sizes come from SFDP and are powers of two. So starting from Address = 0, local_address must stay aligned and in particular it can never become odd. 
So I wonder if :
- The Address argument was already corrupted before or at function entry.
- The debugger is showing a stale/optimized local value, not the real runtime value.
- Something overwrote the callee state after entry.

Moreover, the boot stack is in DTCM at 0x20000000 in STM32H7S78-DK_Boot.map, so 0x24004557 is not a stack address. It is in AXI SRAM.

So in order to get further in debug of the odd local_address, could you try :
- Disable compilation option (reset C/C++ Compiler/Optimizations to None)
- Break at the first line of EXTMEM_EraseSector and inspect the raw Address parameter at function entry, not local_address later in the loop.
- In the caller, inspect fw_offset immediately before the call at fw_update.c:378. If fw_offset is already 0x24004557 there, the corruption happened before entering ExtMem.
- Also inspect br and sector_idx just before the call in fw_update.c:361. fw_offset is only advanced by br, so a corrupted br can explain a corrupted fw_offset.

Could you also checkif problem remains after increase CSTACK to 8 KB or 12 KB, or move the FatFs locals in update_task out of the stack (not declared them as local variables).

Hope this helps