Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
RiyaKori-eaton opened this issue Mar 6, 2025 · 1 comment
Assignees
Labels
area: SPI SPI bus bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 priority: low Low impact/importance bug

Comments

@RiyaKori-eaton
Copy link

RiyaKori-eaton commented Mar 6, 2025

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 .
  1. Necessary files have been updated, including the DTS file, overlay file, prj.conf file, and CMakeLists.txt.
  2. 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

Image

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

Image

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

Image

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

@RiyaKori-eaton RiyaKori-eaton added the bug The issue is a bug, or the PR is fixing a bug label Mar 6, 2025
Copy link

github-actions bot commented Mar 6, 2025

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. 🤖💙

@JarmouniA JarmouniA added the platform: STM32 ST Micro STM32 label Mar 6, 2025
@erwango erwango added priority: low Low impact/importance bug area: SPI SPI bus labels Mar 6, 2025
@erwango erwango assigned gautierg-st and unassigned erwango Mar 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: SPI SPI bus bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 priority: low Low impact/importance bug
Projects
None yet
Development

No branches or pull requests

4 participants