STM32L4R9 OSPI auto polling won't stop

[_EFrie]

I'm using a STM32L4R9 with a W25G128, using non HAL code. The problem I'm seeing is that auto polling isn't stopped on match per logic analyzer. I have this set up to auto poll for write complete, register 0x05 busy bit 1. The match happens, I clear the flags, but the polling won't stop unless I abort. Any clues for me?

This has errata smell, the sheet says "Automatic status-polling mode with octal memories is not functional" so perhaps this means quad as well?

This basic code structure has been working on the F7, so I think it is somewhat valid.

Other info:

Device at 120mhz, qspi clock prescaler 4, boardMemory->readStat = 0x05, QSPI_PAGEP_POLL_INTERVAL = 1000, SPI_FLASH_WIP = 0x01

void OCTOSPI1_IRQHandler(void) {
  BaseType_t xHigherPriorityTaskWoken = pdFALSE;
  if (OCTOSPI1->SR & OCTOSPI_SR_TCF) {
    OCTOSPI1->FCR = OCTOSPI_FCR_CTCF; //Clear flag
    if (qspiAction == QSPI_ACTION_WRITE || qspiAction == QSPI_ACTION_ERASE) {
      //Set up auto polling to flag us when device is not busy.
      OCTOSPI1->PSMKR = SPI_FLASH_WIP;
      OCTOSPI1->PSMAR = 0;
      if (qspiAction == QSPI_ACTION_WRITE) {
        OCTOSPI1->PIR = QSPI_PAGEP_POLL_INTERVAL;
      } else {
        OCTOSPI1->PIR = QSPI_ERASE_POLL_INTERVAL;
      }
      OCTOSPI1->CR |= (OCTOSPI_CR_SMIE | OCTOSPI_CR_PMM | OCTOSPI_CR_APMS);
      OCTOSPI1->DLR = 0;
      OCTOSPI1->TCR = QSPI_TCR_DCYC(0);
      MODIFY_REG(OCTOSPI1->CR, OCTOSPI_CR_FMODE_Msk, QSPI_CR_FMODE_AP);
      //     OCTOSPI1->IR = boardMemory->readStat;
      OCTOSPI1->CCR =
          QSPI_CCR_SIOO |
          QSPI_CCR_DMODE(QSPI_CCR_4LINES) |
          QSPI_CCR_IMODE(QSPI_CCR_4LINES);
      OCTOSPI1->IR = boardMemory->readStat;
    }
  }
  if (OCTOSPI1->SR & OCTOSPI_SR_SMF) {
    OCTOSPI1->FCR = OCTOSPI_FCR_CSMF;
    OCTOSPI1->CR &= ~(OCTOSPI_CR_SMIE);
    vTaskNotifyGiveFromISR(xqspiTaskHandle, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
  }
}

[Tesla DeLorean]

Some of the code in the HAL needs to use Abort in the Timeout cases to terminate the interaction. ​

[_EFrie]

The equivalent HAL code doesn't use abort. The STM32F769 project I imported this from doesn't require it. At present I just moved on using an abort workaround.

[Tesla DeLorean]

>>The equivalent HAL code doesn't use abort.

Sure, and my observation is that it probably should be, having read the manual and walked the code. There's a bunch of threads on this class of failure.. just saying

[Tesla DeLorean]

There's also a bunch of parts where the polling method actually breaks them. Not in a bricking them sense, but in you delivering misprogrammed equipment sense.

[_EFrie]

Overall, I do like the qspi module, it is set up reasonably easy to use (without HAL). Some past projects with the PIC32mz qspi were quite challenging.

[_EFrie]

Do you think this would be declared in the errata? Perhaps I should reconsider the use, although it does seem to work with what I'm doing right now, I'm just polling for the write completion on this flash.

[Tesla DeLorean]

>>Do you think this would be declared in the errata?

Not behaving as you'd like, is not the same as not behaving as designed.

Reading continuously and repetitively looked to be the actual design goal. A bit like the adage this it's not the fall from a large building that kills you.

Perhaps there's a race condition, on the starting/matching side? A misalignment of the data from the pattern matching point of view.

There are two ways out of the operation, a MATCH and an ABORT. There's not a count or a timeout on the hardware, so you'd need to be sure it's actually stopped, and there's a flags to determine that.

Like I said seen a couple of reports of this mode of failure, and the exit paths on at least a number of the HAL implementation are wrong, as a software side timeout needs to actually do something to stop the hardware, and it doesn't. It just walks off with the hardware broken, and likely fails later and resets it to recover, sometimes.. half the time the errors don't propagate properly or the user simple ignores them, per all the reference examples.

On the L4 there are several BSP examples that don't use the HW method, but decompose it to more normative read interactions. The HW method is also entirely unsuited to how the Micron Multi-Die parts behave. Certainly all the MT25 and MT35 ones, and a bunch I haven't been able to directly do regression testing on because finding specific parts is a challenge.

[Tesla DeLorean]

Yes, it's not bad, but like a lot of things with STM32 designs it could have been a lot better, with a little bit of thinking and foresight. Back in the day people designing ICs could also code drivers in assembler, etc, and had a better appreciation of what is required, and what is desirable. Today we have engineers who are either SW or HW, and don't understand, or desire to understand, what happens in the middle.

[Tesla DeLorean]

Related materials

https://community.st.com/s/question/0D53W00001dcUMOSA2/micron-flash-versus-macronix-flash

https://community.st.com/s/question/0D53W00001gVe1ySAC/stm32h7-qspi-flash-write-issue

Related failures

https://community.st.com/s/question/0D53W00001daH2PSAU/unable-to-use-quadspi-status-flag-polling-mode-with-instruction-on-4-lines-on-stm32h753

https://community.st.com/s/question/0D53W00000e2OYkSAM/autopolling-mode-with-octal-memories-is-not-functional

https://community.st.com/s/question/0D53W00001WJBQOSA5/qspi-strange-behavior-when-autopolling

https://community.st.com/s/question/0D53W00001WJOrnSAH/hal-qspi-autopolling-support-4lines