SPI transmission and reception are not functioning as expected for stm32g0c1ret3 controller

[RiyaKori-eaton]

Describe the bug

The primary issue encountered is that SPI transmission and reception are not functioning as expected on stm32goc1ret3 board using zephyr 3.6.0 . Firstly, the SPI clock is not visible on the oscilloscope during transmission and reception. Despite the configuration being correctly set within the code, the expected waveforms for the SPI clock are not observable, indicating a potential issue with the signal generation or transmission. Secondly, the CS (Chip Select) pin is not setting and resetting as it should during SPI communication. Although the configuration for the CS pin is also correctly set in the code, the oscilloscope does not display the corresponding waveforms, suggesting that the pin is not being toggled as intended during data transfer.

Additionally, the RX (Receive) buffer remains perpetually empty, and the RXNE (Receive Not Empty) flag is not being set for the G0 controller. This indicates that no data is being received, which further compounds the issue of SPI communication failure

Please also mention any information which could help others to understand
the problem you're facing:

• What target platform are you using?
  -->Zephyr 3.6.0 for STM32G0C1RET3 (SPI)

• What have you tried to diagnose or workaround this issue?
  -->CONFIGURATION MADE
  //////////////// Overlay file ////////////////

/ {
aliases {
spi1 = &spi1;
gpiob = &gpiob;
};

};
&spi1 {
pinctrl-0 = <&spi1_sck_pb3 &spi1_miso_pb4 &spi1_mosi_pb5>;
pinctrl-names = "default";
cs-gpios = <&gpiob 0 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
status = "okay";
};

////////////////Dts file /////////////////

&clk_lsi {
status = "okay";
};

&clk_hsi {
status = "okay";
};

&clk_hsi48 {
status = "okay";
crs-usb-sof;
};

&pll {
div-m = <1>;
mul-n = <8>;
div-p = <2>;
div-q = <2>;
div-r = <2>;
clocks = <&clk_hsi>;
status = "okay";
};

&rcc {
clocks = <&pll>;
clock-frequency = <DT_FREQ_M(64)>;
ahb-prescaler = <1>;
apb1-prescaler = <1>;
};

&spi2 {
pinctrl-0 = <&spi2_nss_pd0 &spi2_sck_pd1
&spi2_miso_pd3 &spi2_mosi_pd4>;
pinctrl-names = "default";
status = "okay";
};

Below are the action that we have performed and the observation that have been seen :-

1. Debugging the Clock, Baud Rate, and CS Pin:
   • Action: Attempted to debug to verify if the values for the clock, baud rate, and CS pin were being set.
   • Observation: The values are being set in the code.
2. Changing the Baud Rate:
   • Action: Changed the baud rate from 1 MHz (desired for our microcontroller) to 8 MHz and 16 MHz to test functionality at higher frequencies.
   • Observation: No effect was observed.
3. Observing the CS Pin Waveform:
   • Action: Attempted to observe the waveform of the CS pin when set in the code.
   • Observation: No waveform was visible on the oscilloscope.
4. Observing the SPI Clock and CS Pin Waveforms During Code Execution:
   • Action: Attempted to observe the waveforms of the SPI clock and CS pin while the code was running.
   • Observation: No waveforms were visible on the oscilloscope.
5. Manually Setting the CS Pin:
   • Action: Manually set the CS pin to high or low.
   • Observation: The CS pin was visible as high or low when set externally.
6. Observation by using 2 different zephyr version and 2 different controller
   Zephyr 3.6.0:
   • We checked the SPI clock on the Nucleo-G071RB and Nucleo-G474RE boards.
   • On the Nucleo-G071RB, we were unable to observe the SCLK waveform.
   • On the Nucleo-G474RE series, the SCLK waveform was observed and functioning correctly.
   • The screenshot below is for the Nucleo-G474RE.
   Zephyr 4.0.0:
   • The attached zip file contains the code used to test the SPI example.
   • The example code for SPI has been added to the \zephyr-v4.0.0\zephyr\samples\basic path.
   • For the Nucleo-G071RB, we observed the same issue: there is no activity on the SCLK.
   • For the Nucleo-G474RE, the SCLK waveform was observed and functioning correctly.

• Is this a regression? If yes, have you been able to "git bisect" it to a
  specific commit?
• ...
  --> NA

To Reproduce

1. The pin configurations which was supported by our microcontroller has been done .

2. Necessary files have been updated, including the DTS file, overlay file, prj.conf file, and CMakeLists.txt.
3. The build process has been completed, and the firmware has been successfully flashed onto the microcontroller.

Expected behavior

In SPI (Serial Peripheral Interface) communication, if values are transmitted via the transmission buffer, corresponding values should be received in the receiver buffer. This is a fundamental aspect of SPI's full-duplex communication capability.

Impact

showstopper

Logs and console output

**In Zephyr 3.6.0**

we checked SPI clock on nucleo-g071rb and nucleo-g474re
In nucleo-g071rb we are not able to see sclk waveform and nucleo-g474re series its working fine

below screenshot is for nucleo-g474re

In Zephyr 4.0.0
we checked SPI clock on nucleo-g071rb and nucleo-g474re
In nucleo-g071rb we are not able to see sclk waveform and nucleo-g474re series its working fine
For nucleo-g071rb we observed same issue there is no activity on sclk

for nucleo-g474re sclk we are able to see the waveform

Environment (please complete the following information):

• OS: (e.g. Linux, MacOS, Windows)
• Windows
• Toolchain (e.g Zephyr SDK, ...)
• Zephyr 3.6.0
• Commit SHA or Version used
  -->NA

Additional context

[](url) @AmolMeshram-eaton

@bhardadinesh-eaton
@VividhaDhengre-eaton

[github-actions]

Hi @RiyaKori-eaton! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[bhardadinesh-eaton]

Any suggestion for this issue @erwango , @gautierg-st

[realhonbo]

I thought it maybe a old bug of hardware nss caused, it occurred in stm32f1xx and stm32f4xx, and fixed in stm32h7xx:
pb-0 is the hardware nss of alternate spi1, Even though you choose it to soft-nss, may dtc processed it to hard-nss? Could you have a try to change a cs pin?

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[RiyaKori-eaton]

According to the Zephyr documentation, when using spi_transceive() and providing a valid spi_cs_control structure in the spi_config (via the .cs member), the chip select (CS) pin should be automatically asserted (set low) before the transfer and de-asserted (set high) after the transfer. However, if the CS pin is not being set and reset automatically during the SPI transaction, would manually controlling the CS pin resolve this issue?

Additionally, as previously mentioned, the SPI clock signal is not visible for G0 series during the operation. Could you provide possible reasons for the absence of the clock signal in this scenario? @realhonbo @JarmouniA @erwango