st67w61 holds MISO pin low and doesn't allow other slaves to communicate

[Nkh]

Summary: When enabled st67w61 forcefully keeps MISO low and doesn't let other slaves use SPI.

In our setup:

- STM32L452: Is master SPI with latest mission_profile_t02.

- st67w61: Is SPI slave 1 with dedicated CS pin

- 3rd party SPI slave 2 with dedicated CS pin

SPI bus speed is 2MHz, and CPOL, and CPHA are 0

Reproducing problem:

1.  st67w61 is enabled (CHIP_EN is HIGH),

1. - BLE initialized W6X_Ble_Init() successfully
2. - Advertisement starts
3. - We are able to pair with st67w61 successfully via our phone
4. - We then try to start SPI slave 2 with no success. Data is being sent via MOSI but MISO stays low. We have tried this with other types of slaves with no success.
5. After turning OFF (CHIP_EN to LOW) st67w61 module, we can communicate successfully with Slave 2. However we need to have both slaves enabled for our application to work.

Note that CS pins are in the correct state.

It seems like the st67w61 forcefully pulls MISO line low when enabled and doesn't let other SPI devices communicate via it. The only way to allow Slave 2, to work is by turning OFF (CHIP_EN to LOW) st67w61 module.

I'm wondering if this is a firmware bug in st67w61 module. Have you tried cosharing SPI with other slaves. NOTE that if we either turn off or remove ST67w61, other slave devices communicate fine so there's no issue with our HW or code. Please help.

[TarikAb]

Hi @Nkh ,

I confirm the behaviour you described. I am checking with R&D to analyse what happens and if something can be done about it.

In the meantime, are you testing on your hardware or using separate boards? Can you use separate SPIs for the two devices?

[Nkh]

@TarikAb thank you for the quick response. We have a custom PCB with other SPI slaves. So a firmware update or some type of solution from ST would be really appreciated. We don't have another SPI bus that we can use, nor a bus isolator.

[Nkh]

@TarikAb please let us know if you find a workaround to our problem above or timeline of a hotfix firmware ? This is a blocking problem for our boards. Thanks

[Nkh]

Can you please give us an update on this issue? Right now we are dead in the water with our hardware using this module. Thanks.

[Chris21]

It certainly sounds like a significant issue for a product that is advertised as supporting SPI communication.

[Nkh]

Agreed. This is a blocking issue for our product. Hope ST finds a firmware workaround for this.

[TarikAb]

Hello,

I’ve received the final input from our R&D team along with the results of their analysis. It appears that the behavior you observed is, in fact, intended/expected. The ST67W611 operates as a wireless transceiver and relies on real‑time data exchanges over SPI, which is why R&D recommends using a dedicated SPI bus for this device. Adding another slave on the same SPI bus could lead to data loss or, in the worst case, uncontrolled deadlock situations.

I understand this is not the outcome you were hoping for, and I apologize for any inconvenience this may cause. We will update our documentation with the necessary details to help avoid similar situations in the future.

Best regards,
Tarik

[Nkh]

This answer from your R&D team doesn't sound reasonable. To enable near real-time communication, SPI slave devices use the SPI_READY pin. You already have that in this module then why not use that instead of breaking SPI rules and monopolizing the bus.