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

nucleo_g431rb: Hello world not working #21716

Closed
martinjaeger opened this issue Jan 6, 2020 · 7 comments · Fixed by #21739
Closed

nucleo_g431rb: Hello world not working #21716

martinjaeger opened this issue Jan 6, 2020 · 7 comments · Fixed by #21739
Assignees
Labels
bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 priority: medium Medium impact/importance bug

Comments

@martinjaeger
Copy link
Member

Describe the bug
The basic hello world example does not work for the Nucleo G431RB (STM32G431 MCU).

To Reproduce
Try the steps according to board description in docs and see that hello world does not output anything on the terminal.

Environment (please complete the following information):

  • OS: Linux 5.4.2-1-MANJARO zephyr-master_fork #1 SMP PREEMPT Thu Dec 5 09:55:57 UTC 2019 x86_64 GNU/Linux
  • Toolchain: West v0.6.3, Zephyr SDK v0.10.3
  • Commit SHA: ac09bb3

Additional context
The Nucleo board manual states on page 24: "Communication between the target STM32G4 and the STLINK-V3E MCU is enabled on LPUART1 to support the Virtual COM port".

However, the board DTS file selects UART1 for the console:

zephyr,console = &usart1;

Just changing it to use &lpuart1 didn't fix the problem. As this issue might be related to the clock configuration (#21715), I also tried with baud rates divided by two on host side without any success.

LPUART on the board should be connected to PA2 (TX) and PA3 (RX), so that's correct in board spec. However, looking at pinmux.c file, PA2 is used for both USART2 and LPUART1, which might not be the best idea. I wonder if there was any reason for that or if it was just a mistake.

@martinjaeger martinjaeger added the bug The issue is a bug, or the PR is fixing a bug label Jan 6, 2020
@azeemshatp
Copy link

There seems to be another mistake in the doc in that case (https://docs.zephyrproject.org/latest/boards/arm/nucleo_g431rb/doc/index.html).
It says the Zephyr console output is assigned to UART2.
Does this mean DTS and doc are not matching?.

@FRASTM
Copy link
Collaborator

FRASTM commented Jan 7, 2020

Actually, the nucleo_g431rb board outputs the console on LPUART1 (on VCP_Tx/RX pin PA2, PA3)
This has to be changed in the board config (and doc. ). I will proceed to update that.

Note that baudrate > 115200 is reached with LPUART1 clock source different from LSE clock.

@martinjaeger
Copy link
Member Author

Please have a look at the PR mentioned above. I guess that implements what you describe.

I tested the fix and it worked fine with my Nucleo board.

@FRASTM
Copy link
Collaborator

FRASTM commented Jan 7, 2020

That's fine, we could also choose to output USART2 on PA2, PA3 (and leave LPUART on PC1, PC0 if needed).
It works if USART2 is selected for console.
The nucleo_g431rb board refers to UART1 and LPUART1, should it be mentioned USART2, USART3 ( available on pin PB10, PB11 ) and UART4 (available on pin PC10, PC11).

@martinjaeger
Copy link
Member Author

Well, you're right. We could wire UART2 to those pins. But in the board manual they state that LPUART is the default for the VCP (as far as I understand it). So I guess it makes sense to keep it that way to avoid confusion and be consistent with the manual.

So you are saying that we should also configure UART3 and 4? Not sure if that's needed by anyone, but would be easy to add to the PR if you like to have it.

@FRASTM
Copy link
Collaborator

FRASTM commented Jan 7, 2020

I agree, we keep LPUART 1 for console. However for UART_2 pin PA14 & PA15 are already assigned to T_SWCLK and T_JDTI, so could we omit any reference to UART2 in boards/arm/nucleo_g431rb/pinmux.c for nucleo_g431rb.
--> only UART1 and LPUART1 are mentioned.

An interesting note ( in the index.rst) is that LPUART1 baudrate is limited to 9600 if it is clocked by LSE.

@martinjaeger
Copy link
Member Author

Ok, I'll update the PR accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 priority: medium Medium impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants