HAL_QSPI_AutoPolling_* delay between command and response

[Bob Shankle]

Hi All,

I'm using a STM32H7 MCU with a ISSI IS25LP256D serial flash chip. (32MB.)

I wrote a driver using a simple microcontroller and was able to read the Status Register by adding a 8uSec pause after the 0x05 command and the clock pulses to get the response from the ISSI chip.

Now I'm trying to do the same thing on the STM32H7 chip. (It is failing to read the status register and times out on autopolling.) Here is some relevant code.

  QSPI_AutoPollingTypeDef sConfig;
 
  /* Configure automatic polling mode to wait for memory ready ------ */
  sCommand.InstructionMode   = QSPI_INSTRUCTION_1_LINE;
  sCommand.Instruction       = READ_STATUS_CMD;
  sCommand.AddressMode       = QSPI_ADDRESS_NONE;
  sCommand.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;
  sCommand.DataMode          = QSPI_DATA_1_LINE;
  sCommand.DummyCycles       = 6;//DUMMY_CLOCK_CYCLES_READ;
  sCommand.DdrMode           = QSPI_DDR_MODE_DISABLE;
  sCommand.DdrHoldHalfCycle  = QSPI_DDR_HHC_ANALOG_DELAY;
  sCommand.SIOOMode          = QSPI_SIOO_INST_EVERY_CMD;
 
  sConfig.Match           = 0x00;
  sConfig.Mask            = 0x01;
  sConfig.MatchMode       = QSPI_MATCH_MODE_AND;
  sConfig.StatusBytesSize = 4; // 1
  sConfig.Interval        = 0x10;
  sConfig.AutomaticStop   = QSPI_AUTOMATIC_STOP_ENABLE;
 
  HAL_StatusTypeDef HAL_Status_Return_value =HAL_QSPI_AutoPolling_IT(&QSPIHandle, &sCommand, &sConfig);

Is there anyway to add the delay needed?

I'm using the chip in SPI mode and will eventually move on to QSPI mode.

thanks for any suggestions,

Bob

[Tesla DeLorean]

6 dummy clocks, on a 1-bit instruction/data of 8-bit width doesn't make sense to me, the pattern match is going to get skewed

I think you can push out the response in byte counts. ie at 1-bits multiples of 8, at 4-bits multiples of 2

The pattern match is not 32-bit wide, I don't think, some chips alternate SR1/SR2 repetitively, that would be a 16-bit word, but consider the sync/alignment there too.

[Pavel A.]

From the IS25LP256D datasheet 8.18, the Read Status command does not have dummy cycles.

Check your code against the datasheet.

As Tesla suggested, the output data size is one byte, in 1-line data mode

so in line 17 should be sConfig.StatusByteSize = 1

[Tesla DeLorean]

Yes, but you could probably use them to stall for some time, in most of these QSPI the read status tends to cycle continuously as you clock it, so once the command is sent the status spews forth in a way that could be easily implemented in a state-machine in a CPLD/FPGA case, some parts as I say cycle thru registers, either auto-increment, or tick-tock.

[Pavel A.]

For this specific flash, the datasheet says that repeated reading registers produces the same register multiple times... so with size = 4 it will read 4 times, assemble a 32-bit and match the least bit. This equals doing match on every 4th byte.... well, maybe this will work but why? The QSPI controller offloads all the reads and matches.

[Tesla DeLorean]

These are more generalized observations with this class of devices, applicability here may or may not be the case, but might go to explaining why people do things..

Not all circuits are optimized for 133 MHz clocking

Not all commands are optimized for fastest modes of transfer, data fetch tends to get all the attention because it's the boldest thing specified in the data sheet.

Some parts need additional time to fetch array data into line buffers and initiate a ping-pong prefetch on sequential data. Basically time to prime the pump. The faster you clock the tigher the margins get, give it a couple more cycles at the front-end and your on the right side of the critical timing, and margin on process variations and temperature sensitivities.

When using in Quad Mode the lines have to turn around, if you're clocking at real high-speeds, you have to make accommodations for this, as the timing gets very tight. And you might not have good control of the capacitive loads, pin paths might vary, or pico-second level skewing of different bits.

This chip supports this status read in quad mode, I'd probably throw away the first byte off the wire, because it's liable to be a runt. I imagine Bob is getting the 1-bit mode working first, as I would, to prove that I've got basic functionality for the BSP code nailed down, so when I switch back-n-forth, the thing behaves predictably, and doesn't exit the spin-wait prematurely.

I might also back off on the slew-rates / drive (SPEEDR), because you're often dumping a lot of energy into very short traces, with relative low loading, or termination, and this will get you a lot of ringing. While ST might have a "100 MHz mode" on the pin, that might not be appropriate, because they've also assumed they are trying to overcome significantly more capacitive load than exists in the trace on your board. High speed input buffers are typically designed to present as little load as possible.

[Bob Shankle]

Hi All,

Thanks for the responses. @Tesla DeLorean you are correct 6 dummy clock(cycles), etc doesn't make sense. I'm new to the STM32 HAL library and was hoping I could get some delay after the 0x05 command.

Note, I have the ISSI chip working great with a simple microcontroller on a breadboard. What I need is to understand how to get a STM32H7 to do the same.

Below is a screen shot from the FAE for ISSI who mentioned a 8us delay was needed.

I'll go read the responses closer. I guess what I need is the ability to:

1) Pull /CS low

2) Send a 8 bit command (0x05).

3) delay ~8.48uSec

4) send 8 clock pulses and read the returned value.

5) release /CS

Any ideas?

thanks,

Bob

ps Note there is first a WREN command given, I don't see how this would impact anything but I'll go try adding that command and delay.

[Pavel A.]

@Bob Shankle​ 

> Below is a screen shot from the FAE for ISSI who mentioned a 8us delay was needed.

This looks suspicious: no clocks during the 8us delay contradicts to the ST document on QSPI interface.

Such delay is only possible at slower clock rate (more than 8 us between pulses).

Normally, delays are implemented with dummy clock cycles, and number of the cycles is documented.

[CORRECTION]

For the command 05 the number of dummy cycles is probably the "default" number in footnote of table 6.11 (page 22), which is indeed 6 for QPI mode and 8 for SPI mode.

It's not clear whether this applies to read register commands. But worth to try. 6 or 8 dummy cycles, or none at slower clock rate.

[Bob Shankle]

I agree with you Pavel, but I think the clock pulses during the dummy cycles causes a problem for the ISSI chip.

The "problem" is we can demonstrate how the chip behaves, now to get the STM32 software to support that behavior. (I know it is rewarding bad behavior.)

[Tesla DeLorean]

Are you sure it needs this, or it is just the expectation that the chip will take this amount of time to signal it is ready after the WREN.

You do also control the time between when you dispatch the command, and when you initiate the data transfer.​