disco_l475_iot1: BLE not working

[erwango]

Describe the bug
samples/bluetooth/peripheral is not working anymore on zephyr-v3.0.0-483-g145bcd7ab9.
It was working fine on v3.0.0

To Reproduce
Steps to reproduce the behavior:

1. west -p -b disco_l475_iot1 samples/bluetooth/peripheral
2. west flash
3. See error

Expected behavior
BLE should be functional on this board

Logs and console output

*** Booting Zephyr OS build zephyr-v3.0.0-483-g145bcd7ab96e  ***                
[00:00:00.000,000] <inf> flash_stm32_qspi: M

Stack remains stuck in SPI transfer:

spi_stm32_complete (dev=<optimized out>, status=0)
    at /local/mcu/zephyrproject/zephyr/drivers/spi/spi_ll_stm32.c:417
417		ll_func_disable_spi(spi);
(gdb) bt
#0  spi_stm32_complete (dev=<optimized out>, status=0)
    at /local/mcu/zephyrproject/zephyr/drivers/spi/spi_ll_stm32.c:417
#1  0x0800349a in _isr_wrapper ()
    at /local/mcu/zephyrproject/zephyr/arch/arm/core/aarch32/isr_wrapper.S:233
#2  <signal handler called>
#3  0x00004000 in ?? ()
#4  0x000f8000 in ?? ()

Environment (please complete the following information):

• OS: (e.g. Linux, MacOS, Windows): Ubuntu 20.04
• Toolchain (e.g Zephyr SDK, ...)*: SDK 0.13.2
• Commit SHA or Version used: zephyr-v3.0.0-483-g145bcd7ab9

[ABOSTM]

Since introduction of PR #42230 (and especially sha1:cc85c6c518484f44797c287bc559e497f4ee49c9)
samples/bluetooth/peripheral fails on disco_l475_iot1.
It doesn't mean issue is in #42230, but rather that it highlight some latent issues.
All issues are linked to Chip Select management which has changed.

Explanation:

Before #42230, the following code defines cs = NULL

zephyr/drivers/bluetooth/hci/spi.c

Line 135 in 4f8d78c

.cs = NULL,

	static struct spi_config spi_conf = {
		.frequency = DT_INST_PROP(0, spi_max_frequency),
		.operation = (SPI_OP_MODE_MASTER | SPI_TRANSFER_MSB | SPI_WORD_SET(8)),
		.slave     = 0,
		.cs        = NULL,
	};

As a consequence, in SPI drivers, function _spi_context_cs_control() do nothing as ctx->config->cs == NULL

zephyr/drivers/spi/spi_context.h

Line 228 in e2edb3e

if (ctx->config && ctx->config->cs && ctx->config->cs->gpio.port) {

Nevertheless, on BlueNRG-MS module, the CS pin is used for SPI, but also as a wakeup pin.
Consequently, in bluetooth spi HCI driver, there is a dedicated CS management kick_cs()/release_cs() (under compilation switch CONFIG_BT_SPI_BLUENRG)

zephyr/drivers/bluetooth/hci/spi.c

Line 191 in e2edb3e

static void kick_cs(void)

So it worked because CS is managed by bluetooth driver and not SPI driver.

After #42230, the "cs" field (precisely bus-->config-->cs ) is filled with DT information (through imbricated macro calls SPI_DT_SPEC_INST_GET, ..., SPI_CONFIG_DT())

zephyr/drivers/bluetooth/hci/spi.c

Line 119 in e2edb3e

static const struct spi_dt_spec bus = SPI_DT_SPEC_INST_GET(

And this now highlights several issues:

• disco_l475_iot1 DT should define CS as GPIO_ACTIVE_LOW
• kick_cs() and release_cs() should use logic instead of pin value as active low inversion is managed underneath in gpio_pin_set_dt()
• for BlueNRG-MS module, we should prevent SPI driver to release CS, and let bluetooth driver do the job, otherwise, for example, CS is released between sending Read command and effective read transaction, and this cause read failure.
  This could be achieved by setting operation flag SPI_HOLD_ON_CS