STMicroelectronics / x-cube-azrtos-h7

X-CUBE-AZRTOS-H7 (Azure RTOS Software Expansion for STM32Cube) provides a full integration of Microsoft Azure RTOS in the STM32Cube environment for the STM32H7 series of microcontrollers.

Home Page:https://www.st.com/en/embedded-software/x-cube-azrtos-h7.html

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

"Concerns about Write Position Offset in NAND Flash Driver - Seeking Clarification for FileX + LevelX Porting

Jarvis-cpu opened this issue · comments

Hello, I'm currently working on porting filex + levelx to my NAND flash. While referencing the STM32H743I-EVAL example in the x-cube-azrtos-h7 repository (https://github.com/STMicroelectronics/x-cube-azrtos-h7/blob/main/Projects/STM32H743I-EVAL/Applications/FileX/Fx_Nand_Write_Read_File/), I observed that in the NAND flash driver (lx_stm32_nand_custom_driver.c) when calling the lx_nand_flash_driver_pages_write function, the parameter used is SPARE_BYTES_PER_PAGE (https://github.com/STMicroelectronics/x-cube-azrtos-h7/blob/main/Projects/STM32H743I-EVAL/Applications/FileX/Fx_Nand_Write_Read_File/LevelX/Target/lx_stm32_nand_custom_driver.c#L430).

In the same file (lx_stm32_nand_custom_driver.c), at line 359, an offset is applied to the write position. I'm concerned that this offset might lead to accessing addresses beyond the allocated space during the copy operation at line 365 (https://github.com/STMicroelectronics/x-cube-azrtos-h7/blob/main/Projects/STM32H743I-EVAL/Applications/FileX/Fx_Nand_Write_Read_File/LevelX/Target/lx_stm32_nand_custom_driver.c#L365).

I'm curious if there's a specific reason for this offset, or if there are any internal arrangements within levelx that I may not be aware of.