Writing and reading to external NORFlash using QuadSPI on STM32H743 mcu and successfully test erase, write, and read the flash a few days ago but now only read works. What could cause the erase and write command to not fail but not work either?

[PFlor.2]

A few days ago I successfully tested erasing the NORFlash as entire chip erase, block erase, and sector erase. I also was able to write a string to Flash and read the string back out of Flash into a buffer. After working on other development I came back and tested the QSPI again and now I cannot erase or write but can still read out of Flash the test string that was written several days ago. I'm using the exact same code as the first test, trying to just erase and read and get the same string so proved it's not erasing also try to write a different test string and still get the old string when I read. Also during the initial test it would take a little time for a full chip erase and now it just goes through quickly also indicating an erase is not happening. I do have MPU setup for the the 0x90000000 Flash address as well for MPU_PRIVELEDGED_DEFAULT but have access set for ALL_ACCESS so thought this was ok.

[PFlor.2]

Thanks! So how do I use this, I loaded this into my STM32 programmer as an external loader and it works great to read the Flash! So how do I use it to unlock the erase/write capability?

[Tesla DeLorean]

I've had a couple of people who've managed to lock out their Winbond W25Q chips, generally BPx or CMP bits get set in SR1/SR2 (non-volatile), and then erase or mass-erase fail quickly as the chip errors if it thinks that includes any protected blocks.

[PFlor.2]

So is there likely something is my driver functions for Erase or Write that would've done this that I need to correct? I'm not sure what to look for.

[Tesla DeLorean]

The bits are sticky, and the people involved couldn't provide any reason why they'd get set.

I would assume that the memory got in a mode such that invalid commands were rejected (ie 4-bit commands with QE=0), or misinterpreted and then data that was supposed to go to memory went into the non-volatile status bits and got stuck there. There's not a good way to query error/status from the chips, and most code ploughs on in any case.

[PFlor.2]

Yikes, so get it out of this state and hope it doesn't happen again huh? That's scary!

Thanks so much for the help you've provided, I had no idea what to do...you're a life saver!

[Tesla DeLorean]

It should get the Status Registers into a usable state, a Full Erase should take a few minutes, not return instantly.

[PFlor.2]

Did a Read of external flash starting at 0x90000000 for 0x1000 bytes. It read ok but didn't seem the get it back to a usable state. So then I went to try to erase the external flash chip and it seems to be hung...had to reboot to get it back. I tried to erase entire chip again and said it was successful but only took a few seconds...I went to read and the string was still there so it did not erase. Any ideas? By the way this is a W25Q64JV NORFlash.

erase entire chip:

read:
 

[PFlor.2]

I was able to put code in to read all 3 status registers:

StatusReg1 = 0

StatusReg2 = 66

StatusReg3 = 96

So the BP register bits are not set but it appears the CMP register bit is set.

I put together another function to do the write enable and then write status register 2 with the cmp bit cleared and hallelujah the erase and write functions are operational again!!!

Thanks you so much for walking me through all this, you're a God-send!

I guess if nothing else it forced me to understand how to read/write the status registers and understand the QSPI interface to the NORFlash a little better.

Would you be willing to share your external loader code with me in order to better understand how to create that as well? If nothing the else the Dev_Inf.c, Dev_Inf.h, Loader_Src.c, Loader_Src.h, and linker.ld files?? I watched the ST videos on creating a loader and might be able to put one together next time with those files to go by with this part.

[PFlor.2]

I spoke too soon. I was able to clear the CMP bit but then the next time through it gets set again. I commented out all my test erase, write, and read functions....just doing the QSPI initialization and then reading status registers and the bit is set again after I read it cleared previously. Attached my quadspi.c file if you wouldn't mind taking a look. See below everything I'm doing with qspi in the main.c...

/**

 * @brief The application entry point.

 * @retval int

 */

int main(void)

{

 /* USER CODE BEGIN 1 */

 /* USER CODE END 1 */

 /* MPU Configuration--------------------------------------------------------*/

 MPU_Config();

 /* MCU Configuration--------------------------------------------------------*/

 /* Reset of all peripherals, Initializes the Flash interface and the Systick. */

 HAL_Init();

 /* USER CODE BEGIN Init */

 /* USER CODE END Init */

 /* Configure the system clock */

 SystemClock_Config();

 /* USER CODE BEGIN SysInit */

 /* USER CODE END SysInit */

 /* Initialize all configured peripherals */

 MX_GPIO_Init();

 MX_DMA_Init();

 MX_FMC_Init();

 MX_TIM1_Init();

 MX_TIM3_Init();

 MX_LTDC_Init();

 MX_UART4_Init();

 MX_CRC_Init();

 MX_DMA2D_Init();

 MX_USART1_UART_Init();

 MX_QUADSPI_Init();

 /* USER CODE BEGIN 2 */

 if (CSP_QUADSPI_Init() != HAL_OK)

 {

  Error_Handler();

 }

 HAL_Delay(100);

// CSP_QSPI_ClearCmpBit();

 CSP_QSPI_ReadStatusRegs();

[Tesla DeLorean · Accepted solution]

I'd recommend clearing the sCommand structure on all occasions, you've got it on most but not all. This will limit odd/unpredictable operation.

Watch also the Status 2 Write, not all generations of Winbond parts support this, and it's hard to determine which you're talking too. Might need to unpack the SFDP (0x5A)