NOR Flash driver does not support large flash chips (i.e. greater than

[david-oz00]

Describe the set-up Hardware: Proprietary hardware containing STM32H743 and external NOR FLASH and external SDRAM.

Describe the bug In the latest version of stm32h7xx_hal_nor.c, the HAL_NOR_Init() function gets an invalid CommandSet when using a large NOR Flash chip containing more than 1 bank. Consequently, the driver asserts when it attempts to use the invalid CommandSet. In this code, the driver attempts to get the CommandSet:

 /* Get the value of the command set */
NOR_WRITE(NOR_ADDR_SHIFT(deviceaddress, uwNORMemoryDataWidth, NOR_CMD_ADDRESS_FIRST_CFI), NOR_CMD_DATA_CFI);

hnor->CommandSet = *(__IO uint16_t *) NOR_ADDR_SHIFT(deviceaddress, uwNORMemoryDataWidth, NOR_ADDRESS_COMMAND_SET);

The CommandSet must be read from the base address of the chip, i.e. 0x00000000 (VMA 0x60000000). However, if the chip contains more than one bank, when it is called for the second bank, it will read from 0x04000000 (VMA 0x64000000) which is invalid. It would only work, if all banks were in separate FLASH chips.

How To Reproduce

1. Connect a single 1Gb NOR Flash chip to a STM32H7

2. Call HAL_NOR_Init for Bank 1. (It reads the CommandSet from the base address 0x0000000. In my environment CommandSet is assigned 0x02)

3. Call HAL_NOR_Init for Bank 2. (It reads the CommandSet from address 0x04000000. In my environment CommandSet is assigned 0xFF)

4. HAL NOR Driver asserts because CommandSet is invalid.

Additional Context I can't think of an elegant solution to this issue. The driver doesn't know if the banks are in one chip or multiple chips. I would recommend passing the base address of the chip (not bank address) to the function to obtain the CommandSet like here:

/* Get the value of the command set by reading the base address of the CHIP (not bank) */
baseAddress = 0x60000000;

NOR_WRITE(NOR_ADDR_SHIFT(baseAddress, uwNORMemoryDataWidth, NOR_CMD_ADDRESS_FIRST_CFI), NOR_CMD_DATA_CFI);

hnor->CommandSet = *(__IO uint16_t *) NOR_ADDR_SHIFT(baseAddress, uwNORMemoryDataWidth, NOR_ADDRESS_COMMAND_SET);

So initialising each bank you pass the base of address of the Flash the chip and not the Bank address.

In the meantime, I have added this patch to my driver:

/* Get the value of the command set */
#if READ_COMMAND_SET
  NOR_WRITE(NOR_ADDR_SHIFT(deviceaddress, uwNORMemoryDataWidth, NOR_CMD_ADDRESS_FIRST_CFI), NOR_CMD_DATA_CFI);
  hnor->CommandSet = *(__IO uint16_t *) NOR_ADDR_SHIFT(deviceaddress, uwNORMemoryDataWidth, NOR_ADDRESS_COMMAND_SET);
#else
  hnor->CommandSet = 0x02;    
#endif

I hope this issue can be resolved or at least find a workaround that doesn't need to patch the driver.

[RKOUSTM]

Hi @david-oz00,

Thank you for your report. This issue is related to a limitation of the stm32h7xx_hal_nor.c driver which supports a few NOR manufacturers. Actually, this point has been discussed internally, before we receive your request. A fix in the NOR FLASH driver will be available in a future release to support different memory, very soon hopefully.

Thank you again for you report. We are looking forward to reading from you again.

With regards,

[ALABSTM]

ST Internal Reference: 168587

[ALABSTM]

Hi @david-oz00,

I hope you are fine. In your first comment, you said: "In the latest version of stm32h7xx_hal_nor.c". Do you mean the issue is not present when using older versions of the driver?

Another point please. You mentioned that the 2nd command set is set to 0xFF. When looking into the different command sets supported by version 1.11.1 of the driver, none is defined to be 0xFF. Could it be that you are using a command set not supported by the driver?

/* Command set code assignment (defined in JEDEC JEP137B version may 2004) */
#define NOR_INTEL_SHARP_EXT_COMMAND_SET       (uint16_t)0x0001 /* Supported in this driver */
#define NOR_AMD_FUJITSU_COMMAND_SET           (uint16_t)0x0002 /* Supported in this driver */
#define NOR_INTEL_STANDARD_COMMAND_SET        (uint16_t)0x0003 /* Not Supported in this driver */
#define NOR_AMD_FUJITSU_EXT_COMMAND_SET       (uint16_t)0x0004 /* Not Supported in this driver */
#define NOR_WINDBOND_STANDARD_COMMAND_SET     (uint16_t)0x0006 /* Not Supported in this driver */
#define NOR_MITSUBISHI_STANDARD_COMMAND_SET   (uint16_t)0x0100 /* Not Supported in this driver */
#define NOR_MITSUBISHI_EXT_COMMAND_SET        (uint16_t)0x0101 /* Not Supported in this driver */
#define NOR_PAGE_WRITE_COMMAND_SET            (uint16_t)0x0102 /* Not Supported in this driver */
#define NOR_INTEL_PERFORMANCE_COMMAND_SET     (uint16_t)0x0200 /* Not Supported in this driver */
#define NOR_INTEL_DATA_COMMAND_SET            (uint16_t)0x0210 /* Not Supported in this driver */

Thank you in advance for your answers.

With regards,

[JRASTM]

Dear,

Come to you on this subject and understand your interrogation, about the fact that you use a memory size upper than a ST bank size support.

Now, up to this, for sure the ST driver is compliant with the bank size and common management of each of them.

Yours issue, seems out of FMC bank management. As you know each bank is link to a specific chip select. And one interrogation on ST side, is how your application manage those toggle of chip select link to bank1 and chip select for bank2 ?

And so other point, how your application management the address swap between bank1 and bank2 during operational process ?

Thanks for your answer, Regards

[ALABSTM]

Hi @david-oz00,

I hope you are doing well. Any feedback please?

Thanks,

[ALABSTM]

Hi @david-oz00,

So far, we could not reproduce the issue you reported.

• As suggested by @JRASTM here, "Yours issue seems out of FMC bank management".
• As suggested in this comment, you may also be using a command set 0xFF not supported by the driver.

Anyway, as no feedback received so far. Please allow me to close the issue. Thank you for your comprehension.

With regards,