HAL_NOR_ProgramBuffer() memfault & supported devices

[regjoe]

Hello,

I want to use the buffer program feature of my IS29GL064 NOR flash in order to increase the programming speed.

For this I replaced HAL_NOR_Program() by HAL_NOR_ProgramBuffer() in the NOR flash demo and got a memfault. Did some debugging and doubt the code, especially because I found this post here

BUGS: HAL_NOR_ProgramBuffer() is riddled with them 

Has the reported bug, if any, been already fixed ?

Second, I wonder if my ISSI flash is supported because of the following comment in stm32h7xx_hal_nor.c

This function must be used only with S29GL128P NOR memory.

IMHO all devices which support the necessary commands, e.g. NOR_CMD_DATA_BUFFER_AND_PROG,  should be able to use this feature and HAL function.

Any hints, news, updates or comments?

Thank you

[Saket_Om · Accepted solution]

Hello @regjoe 

---

@regjoe wrote:

Hello,

Has the reported bug, if any, been already fixed ?

---

The bug has been fixed on the version 1.9.0: The HAL_NOR_ProgramBuffer() has a few defects · Issue #20 · STMicroelectronics/STM32CubeH7

---

@regjoe wrote:

Second, I wonder if my ISSI flash is supported because of the following comment in stm32h7xx_hal_nor.c

This function must be used only with S29GL128P NOR memory.

IMHO all devices which support the necessary commands, e.g. NOR_CMD_DATA_BUFFER_AND_PROG,  should be able to use this feature and HAL function.

---

The better way is to review the IS29GL064 datasheet for its buffer programming sequence and compare it to the HAL implementation. If the command sequence matches, you may be able to use HAL_NOR_ProgramBuffer(). If not, you’ll need to adapt the function for your device.

[Tesla DeLorean]

Doesn't work type reports will generally get less attention than ones calling at specific lines or code sequences. 

Not sure if reporting on Github is active.

[regjoe]

Hello @Saket_Om ,

I'm using the HAL files generated by CubeMx, but it seems to me that this file is outdated, because in the header contains year 2017. It appears to me it is the same as here:

https://github.com/STMicroelectronics/stm32h7xx-hal-driver/blob/master/Src/stm32h7xx_hal_nor.c

This is my CubeMx setup:

What can I do to use the latest version?

[T_Hamdi]

Hello @regjoe 

After carefully reviewing the datasheets of the IS29GL064 and the S29GL128P, it is clear that the Write Buffer Programming method differs between these two devices.

The HAL_NOR_ProgramBuffer() function in the HAL driver is specifically designed to follow the programming cycle of the S29GL128P, as described in its datasheet.

Write Buffer Programming in S29GL128P 

Therefore, using it directly with the IS29GL064, which employs a different buffer programming protocol, can lead to issues such as the memfault you encountered.

To leverage this feature with your IS29GL064 NOR flash , it would be necessary to implement a dedicated function that strictly follows the sequence and timing specified in the IS29GL064 datasheet.

WRITE BUFFER PROGRAM Operation in IS29GL064 

Thank you

Hamdi

[regjoe]

Hello @T_Hamdi 

I agree that the statemachine drawings look different, but if you compare the text in the description, programming of both flash looks the same to me:

So here, the IS29GL64 works but I don't know why. I probably have a problem when step debugging the buffer programm code. Maybe the flash aborts its internal buffer program statemachine if the debugger is reading from flash in order to read the value of a variable displayed in the debug window?

I now give a try to the MX29GL flash. Regarding the datasheet, it should work but doesn't yet. Maybe the same debugging problem? I'll get back soon.

[regjoe]

I finally succeeded running the HAL_NOR_ProgramBuffer() on IS29GL064 and MX29GL640. To me, both flash support the program buffer feature and the programming flow is the same as for the SG29GLxxx. IMHO the HAL comment mentioned in my first post is misleading.

Next, I didn't realize that "address" parameter in HAL_NOR_ProgramBuffer() is not the same as "address" in HAL_NOR_Program().

If you compare the prototypes

HAL_StatusTypeDef HAL_NOR_Program(NOR_HandleTypeDef *hnor, uint32_t *pAddress, uint16_t *pData);

HAL_StatusTypeDef HAL_NOR_ProgramBuffer(NOR_HandleTypeDef *hnor, uint32_t uwAddress, uint16_t *pData,

uint32_t uwBufferSize);

both look quite the same. But for HAL_NOR_Program() a memory address is required,

for HAL_NOR_ProgramBuffer() an offset is required.

So I passed a memory address to HAL_NOR_ProgramBuffer() as parameter by mistake.

This caused the memfault.

As suggested in the following link, I guess it would be better to have the same API for both functions,

even though, inside HAL_NOR_Program() the flash memory base address is set again,

which may conflict with the base address used in the calculation of the "pAddress" parameter.

I suggest to unify API for the whole set of HAL_NOR_* functions 

By mistake, I assumed that all suggestions have been adopted by ST, so I thought that my HAL version is outdated, but this was not the case.

Last not least, I missed that that the MACRONIX flash does only have a program buffer size of 32 bytes.

I tried to program 512 bytes, same as for the ISSI flash, but stopped step debugging.

For test I reproduce it by setting the program buffer size to 64 bytes.

Here is the situation after the last valid/allowed write to flash

By executing the next debugger step, debugging is aborted. The following output is generated:

Performing single step...
ERROR: Cannot read register 15 (R15) while CPU is running
Reading common registers: ERROR: Cannot read register 0 (R0) while CPU is running
Read register 'r0' (4 bytes) from hardware: 0xEFBEADDE
ERROR: Cannot read register 1 (R1) while CPU is running
:
ERROR: Cannot read register 16 (XPSR) while CPU is running
Read register 'xpsr' (4 bytes) from hardware: 0xEFBEADDE
WARNING: Failed to read memory @ address 0xDEADBEEE
ERROR: Cannot read register 17 (MSP) while CPU is running
Reading register 'msp' = 0xDEADBEEF
ERROR: Cannot read register 18 (PSP) while CPU is running
Reading register 'psp' = 0xDEADBEEF
WARNING: Failed to read memory @ address 0xDEADBEEE

I guess that the debugger tried to read from an "invalid" flash memory address outside the program buffer address range. Any idea what exactly happens here?

[T_Hamdi]

Hello @regjoe ,

The issue you are encountering is due to the Macronix flash memory you are using, Which supports a maximum programming buffer size of 32 bytes.

When you try to write 512 bytes (as you do with the ISSI flash) or even 64 bytes in a single operation, you exceed this limit. This causes programming errors and blocks the debugger, as you have observed.

To resolve this issue, it is essential to split your writes into blocks of 32 bytes maximum. Each programming operation must respect this size to ensure system stability and allow proper debugging.

[regjoe]

Hello @T_Hamdi ,

it works well with 32byte but I'd like to know why debugging is halted/crashed if set > 32byte. Is this related to FMC peripheral that is blocked or flash cannot accessed after programming error?

From time to time I have similar problems, knowing what's going on would probably help next time to find the error faster.

Thanks