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.

[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.​

[Bob Shankle]

That is probably the part I'm missing. How do I add the space (time delay) between the 0x05 command and when clock pulses start to receive the data back from the ISSI chip.

[Tesla DeLorean]

Ok, so decompose this.

You're just trying to read the register, and check the reported state, so either make a command/receive combo with a delay, or make a HAL_QSPI_AutoPolling_IT_Ex() or HAL_QSPI_AutoPolling_Ex() variant that has some interstage delay.

[Tesla DeLorean]

What's the actual errata on this device?

What does the logic analyzer output look like when you send the 0x05 command and then immediately read half a dozen bytes, after the WREN?

[Bob Shankle]

Hi Tesla,

The screenshot of the LAX was provided by the ISSI FAE, so I can't generate other shots. (The problem was sending WREN and the SR would return 0x04 instead of 0x02. The problem went away with the delay recommended.)

Is it possible to add the delay using the existing HAL library and I can run tests on my end?

Otherwise I'm going to look into writing code that does a simple bit-bang to get the SR to respond correctly.

thanks,

Bob