Missing SPI SCK on STM32F103vctx

[calaghann]

Describe the bug
A custom board using stm32F103vctx MCU uses SPI1 with remaped sck pin pb3 does not output any clock signal. The SPI1 peripheral was used and configured with the stm vendor dts / dtsi. However once I tried to sent out some SPI commands using the stm spi driver I noticed that no spi clock signal is emitted on pb3 (using an oscilloscope). The other spi signals (MOSI, MISO and nCS on pb4, pb5 and pb8) are correctly pushed by the stm spi driver.
A quick implementation using only STM HAL produces the same register contents of the affected register banks GPIOB, AFIO, and SPI1. However using STM HAL the clock signal is emitted correctly on pb3.

To Reproduce
Steps to reproduce the behavior:

1. Grab a plattform using a stm32F103 MCU (preferably stm32F103vctx)
2. configure SPI1 in the dts e.g. like this
   pinctrl-0 = <&spi1_sck_master_pb3 &spi1_miso_master_pb4 &spi1_mosi_master_pb5>; cs-gpios = <&gpiob 8 (GPIO_ACTIVE_LOW)>; pinctrl-names = "default"; status = "ok";
3. try to send something on SPI using stm spi driver and spi_transceive_dt
4. measure spi clock on pb3 (e.g by using oscilloscope or logic analyzer)

Expected behavior
SPI communication with remapped Pins pb3, pb4 and pb5 is working

Impact
In that case no SPI communication can be established which is a show stopper on my board right now.

Environment (please complete the following information):

• OS: Windows
• Toolchain Zephyr SDK
• Commit SHA 49d08c2

[FRASTM]

when remapping the SPI1 (REMAP_1), I suspect a pin conflict between SPI1 and DEBUG pins
PB3 and JTDO
PB4 and NJTRST

--> if SPI1 is remapped then it is needed to LL_GPIO_AF_DisableRemap_SWJ(); or LL_GPIO_AF_Remap_SWJ_NOJTAG();

[calaghann]

Thanks for your update. We had a further look into that and found the config option GPIO_STM32_SWJ_NOJTAG. After setting this option we were able to see the clock (so pin conflict seems the right idea). Unfortunately after that we were not able to debug with SWD - the program is getting stuck in the ARM reset (reset.S).

[GeorgeCGV]

This is the same issue as #38354 and relates to the #38741 PR (regarding AFIO and SWJ). Unfortunately, the issue seems to exist in the latest Zephyr.

[erwango]

Setting the CONFIG_GPIO_STM32_SWJ_NOJTAG results in getting stuck within z_arm_reset.

Do you get the same issue even when not using SPI1 at all (eg: hello_world)?

[GeorgeCGV]

Setting the CONFIG_GPIO_STM32_SWJ_NOJTAG results in getting stuck within z_arm_reset.

Do you get the same issue even when not using SPI1 at all (eg: hello_world)?

@erwango, yes.

When CONFIG_GPIO_STM32_SWJ_NOJTAG is set, then the custom board is stuck (even when SPI 1 is not used).
Here is the OpenOCD output.

O0x00000000 in ?? ()

Program stopped, probably due to a reset and/or halt issued by debugger

target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08008b84 msp: 0x20003130

target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08008b84 msp: 0x20003130

Fail reading CTRL/STAT register. Force reconnect

Program stopped.
z_arm_reset () at [<workspace-path>\zephyr\arch\arm\core\aarch32\cortex_m\reset.S:103]()
103 movs.n r0, #_EXC_IRQ_DEFAULT_PRIO

The board is connected via SWD using ST-LINK/V2.

ST-Link/V2 firmware version: V2J39S7.

Connection of ST-Link/V2 to MCU:

• TCLK/SWDCLK - PA14
• TMS/SDWIO - PA13
• nRESET - NRST (indirectly)
• GND - GND

What works

• STM32CubeMX generated project for STM32CubeIDE (no Zephyr) - can be flashed and debugged with OpenOCD "Connect under reset" configuration.
• STM32CubeProgrammer is able to connect to the target with "Hardware Reset" reset mode and "Under Reset" mode (standalone usage)
• Zephyr without enabled CONFIG_GPIO_STM32_SWJ_NOJTAG (works with CONFIG_GPIO_STM32_SWJ_NOJTRST, and with CONFIG_GPIO_STM32_SWJ_ENABLE) - but that prevents us from using PB3 as SPI 1 SCK
• Nucleo F103RB - enabled CONFIG_GPIO_STM32_SWJ_NOJTAG with on-board and external ST-Link/V2 programmers

What doesn't work

Not able to debug and run Zephyr application when CONFIG_GPIO_STM32_SWJ_NOJTAG is set (doesn't matter if SPI 1 is used or not).

Tried different OpenOCD binaries:

• Official OpenOCD v0.11.0
• OpenOCD 0.11.0+dev-00438-ga75fc63 (2021-11-03-15:27) from STM32CubeIDE

With different configurations:

• Zephyr's Nucleo-F103RB board configuration with modified CHIPNAME, reset-config, and set CONNECT_UNDER_RESET
• STM32CubeIDE generated OpenOCD configuration for STM32F103VCTX that uses dapdirect_swd transport with "hardware reset" and "connect under reset"
• Tried hla_swd transport

Every configuration hangs within the aforementioned reset.S line.

SWD

Without CONFIG_GPIO_STM32_SWJ_NOJTAG

works

Captured with CONFIG_GPIO_STM32_SWJ_ENABLE (similar is observed with CONFIG_GPIO_STM32_SWJ_NOJTRST).

With CONFIG_GPIO_STM32_SWJ_NOJTAG

stuck in reset.S

[GeorgeCGV]

Found a fix.

Every LL example for F103 that uses MAPR sets the value of a remap with AFIO_MAPR_SWJ_CFG.

__STATIC_INLINE void LL_GPIO_AF_EnableRemap_SPI1(void)
{
  SET_BIT(AFIO->MAPR, AFIO_MAPR_SPI1_REMAP | AFIO_MAPR_SWJ_CFG);
}

__STATIC_INLINE void LL_GPIO_AF_EnableRemap_I2C1(void)
{
  SET_BIT(AFIO->MAPR, AFIO_MAPR_I2C1_REMAP | AFIO_MAPR_SWJ_CFG);
}

__STATIC_INLINE void LL_GPIO_AF_EnableRemap_USART2(void)
{
  SET_BIT(AFIO->MAPR, AFIO_MAPR_USART2_REMAP | AFIO_MAPR_SWJ_CFG);
}

The AFIO_MAPR_SWJ_CFG is equal to 111 of SWJ_CFG[2:0].

/*!< SWJ_CFG configuration */
#define AFIO_MAPR_SWJ_CFG_Pos                (24U)                             
#define AFIO_MAPR_SWJ_CFG_Msk                (0x7UL << AFIO_MAPR_SWJ_CFG_Pos)   /*!< 0x07000000 */
#define AFIO_MAPR_SWJ_CFG                    AFIO_MAPR_SWJ_CFG_Msk             /*!< SWJ_CFG[2:0] bits (Serial Wire JTAG configuration) */

The reference manual (RM0008) doesn't say why such configuration has to be applied when setting the remap value.

From the reference manual, page 184:

000: Full SWJ (JTAG-DP + SW-DP): Reset State
001: Full SWJ (JTAG-DP + SW-DP) but without NJTRST
010: JTAG-DP Disabled and SW-DP Enabled
100: JTAG-DP Disabled and SW-DP Disabled
Other combinations: no effect

After the following modification in stm32_pins_remap of pinctrl_stm32.c:

	*reg = reg_val | AFIO_MAPR_SWJ_CFG;

the board can be debugged and SPI 1 SCK signal is present.

The SPI will be revalidate, then PR will be created.

[erwango]

@GeorgeCGV Thanks for the investigation and finding the issue!
For the fix, I suggest to purely remove gpio_stm32_afio_init and move its logic directly in pinctrl_stm32.c (and pinmux_stm32.c while it's still there).

[GeorgeCGV]

The PR is created. I can confirm that the SPI 1 SCK signal is present on PB3.

Some notes:

HAL and LL don't disable the LL_APB2_GRP1_PERIPH_AFIO clock.

There is a difference in the order of how SWJ and remap are being set between HAL and LL:

• HAL
  • Enables the clock and disables JTAG in HAL_MspInit (HAL_Init)
  • Enables remap after GPIO initialization
• LL
  • Enables the clock and disables JTAG
  • Reads MAPR and awaits AFIO_MAPR_SWJ_CFG_JTAGDISABLE to be set (SWJ_CFG part, it is supposed to be write-only ??? if you do that in Zephyr it loops forever).
  • Enables remap before GPIO initialization

Unfortunately, we didn't manage to communicate with the external IC over the SPI 1 on F1VC in Zephyr yet.
Everything works with HAL (without Zephyr) using F1VC, so it is not HW/Board issue.
Another board (L5 MCU) works with that IC over SPI in Zephyr, so it is not a driver issue. Investigating further...

[GeorgeCGV]

Everything works now.

What helped is the usage of AFIO_MAPR_SWJ_CFG (111) during every remap setting. The LL_APB2_GRP1_PERIPH_AFIO can be disabled after SWJ_CFG bits are set. However, there is not much gain from disabling it. It will be re-enabled in the remap (generated HAL project and LL examples leave LL_APB2_GRP1_PERIPH_AFIO enabled).

Unfortunately, it is unknown why setting the AFIO_MAPR_SWJ_CFG (111) helps. However, HAL and LL do the same.

For example:

__STATIC_INLINE void LL_GPIO_AF_EnableRemap_SPI3(void)
{
  SET_BIT(AFIO->MAPR, AFIO_MAPR_SPI3_REMAP | AFIO_MAPR_SWJ_CFG);
}

purely remove gpio_stm32_afio_init

The SWJ initialization is moved into pinctrl and pinmux modules.

I don't think that we shall get rid of the SYS_INIT approach.
There might be a case when no remap is used but someone needs an IO pin that is occupied by the JTAG or SWD in the project. Therefore, we have to provide a way to free desired IO pin (e.g. PB4, PA15, etc...).

The PR also follows your suggestion regarding the DTS usage instead of Kconfig for the SWJ. That makes more sense, as it is a setting that is more or less F1-specific.