Skip to content

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

@Jarvis-cpu

Description

@Jarvis-cpu

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions