WSPI driver hangs in wspiCommand with wspip->thread NULL on STM32H743

[Alex]

Hi,
I'm using ChibiOS on STM32H743 with the WSPI driver. In wspiCommand (hal_wspi.c), execution hangs at msg = osalThreadSuspendS(&wspip->thread) because wspip->thread is NULL. The driver is initialized with wspiStart(&WSPID1, &wspi_config), end_cb is NULL. What could cause wspip->thread to remain NULL? Any known issues or fixes for WSPI on STM32H7?
Thanks, Alex

[Giovanni]

Hi,

No known issues, that is strange because it is in the high level driver.

Try to enable assertions, checks, state checker and stack overflow checker, that problem could not be so obvious.

Giovanni

[Alex]

Hi,
I'm using ChibiOS on STM32H743 with QUADSPI in Quad SPI mode (XSNOR_BUS_MODE_WSPI_4LINES, N25Q/4Wire config adapted for MX25L12835F and W25Q128JV, dummy cycles = 8, prescaler = 15 for 12.5 MHz from PLL2_R_CK at 25 MHz, HSE = 8 MHz, PLL2: DIVM=4, DIVN=400, FRACN=0, DIVR=32).

JEDEC ID (0x9F) reads incorrectly in real-time mode: first byte is 0x8F instead of 0xEF for W25Q128JV, but the second and third bytes (0x40 0x18) are correct. Similarly for MX25L12835F. The full ID (0xEF 0x40 0x18) reads correctly only in step-by-step debugger mode. Command is in Single SPI with dummy = 0.
Tried:
SSHIFT = 1 and 0 in QUADSPI_CR.
CSHT = 3 in DCR.
Errata workaround in wspiStart after wspi_lld_start (without restoring CR/CCR due to BUSY hang).
Pinout: PB2-AF9 (CLK), PB6-AF10 (NCS), PD11-AF9 (IO0), PD12-AF9 (IO1), PF7-AF9 (IO2), PD13-AF9 (IO3).

What else can I try to stabilize JEDEC ID reading for the first byte?

Thanks,

[Giovanni]

What ChibiOS version are you using?

Giovanni

[Alex]

I'm using ChibiOS 21.11.x 2024,
but hal/lib/complex from last version Chibios (commit 9dd2b400e7ec5532ac598cc4de1077a1d695ab7b (HEAD -> master, origin/master, origin/HEAD)

Additionally, the project fails to run properly with the latest ChibiOS version. The issue is in the ChibiOS-RT kernel, specifically in the priority queue insertion function:
static inline ch_priority_queue_t *ch_pqueue_insert_behind(ch_priority_queue_t *pqp,
ch_priority_queue_t *p) {

/* Scanning priority queue, the list is assumed to be mostly empty.*/
do {
pqp = pqp->next;
} while (unlikely(pqp->prio >= p->prio));

/* Insertion on prev.*/
p->next = pqp;
p->prev = pqp->prev;
p->prev->next = p;
pqp->prev = p;

return p;
}
The code gets stuck (infinity cycled)at the line:
} while (unlikely(pqp->prio >= p->prio));

[Giovanni]

Hi,

That was caused by a bug already fixed, make sure to use the released version 21.11.4 or to checkout from subversion, apparently the git mirror has not been updated for a while.

Giovanni

[Alex]

Hello!
I continue my unsuccessful attempts to run littlefs/wspi on QUADSPI Flash W25Q128JV. The problems I described in my two previous messages are now absent. I am using the latest version of ChibiOS from GitHub, commit from September 24, 2025. I also switched from the STM32H743 processor to the STM32F746 processor, because according to the errata for the STM32H743, it has serious problems with the QSPI interface.

The current situation is as follows: In the __n25q_init_impl() procedure, reading the JEDEC ID in single-bit mode is always successful and returns the value 0xEF, 0x40, 0x18. Then, the procedure continues with the initialization of the 4-bit mode and reading the JEDEC ID in this mode. It is here that the reading always fails and returns the value 0x4F as the first byte. I don't have the opportunity to purchase n25q chips and I am using Winbond chips – could this be the reason for my failures?

Thanks in advance,
Alex.

[Giovanni]

Apparently, for some reason, the switch to 4 bits mode fails so it cannot read the ID again, I never used those Winbond chips so cannot suggest anything but search for some initialization procedure for those chips, following the N25Q procedure is probably not valid, the answer is buried somewhere in the datasheet.

On the ChibiOS side make sure you programmed all QSPI GPIOs correctly.

Giovanni

[FXCoder]

Hi Alex,
I have a prototype NUCLEO H753 board with 2 x Winbond W25Q512JV parts attached.
One is normal SPI connected the other is QSPI connected.
Both Winbond chips are on breakout boards with 10cm Dupont leads back to Nucleo.
This is not ideal of course and to make this work I put snubbers (47R + 82pF in series to GND) on the SCK line on each breakoout to kill the clock ringing.
Not wonderful but it works for prototyping purposes.

Anyway just to let you know the chips work well for quad mode but I use only the instructions of the W25Q512JV set that perform 1 bit CMD, 1 bit ADDR and then 4 bit data transfers.
Flash sectors all work, LFS works, etc. but note I do only ever use the normal 1 bit ID command at the init/start of the flash.

The prototype is on the back burner for now due to other priorities.
However if I get a chance in the next few weeks I'll see if 4 bit ID command can be made to work.

I'm using my own flash driver (pretty similar to XSNOR in functionality).

Regards
--
Bob