[BUG] Nucleo-L432KC NSH (USART2) no RX (wrong pin map?)

[davidgnx]

Description / Steps to reproduce the issue

The "nucleo-l432kc:nsh" config does not work out of the box since a few months. As of today, it still does not work.

Symptoms: NuttX NSH is capable of outputting data via UART (USART2 of the MCU connected to the on-board virtual COM of the ST-LINK) but nothing happens when the user tries to type in commands (e.g. using minicom).

The root of the issue seems to be this commit: 7b9b630

I don't know what this commit tries to fix or solve, on my Nucleo-L432KC board USART2 RX is connected to PA15 and not to PA3. According to the user manual, PA15 is used, so my Nucleo board matches the specifications.

For more information, see:

Nucleo board documents:
https://www.st.com/en/evaluation-tools/nucleo-l432kc.html#documentation

User manual (scroll to Page 20 or Chapter 6.9):
https://www.st.com/resource/en/user_manual/um1956-stm32-nucleo32-boards-mb1180-stmicroelectronics.pdf

So actually the commit mentioned above breaks NSH and actually the whole USART2 by mapping it to the wrong pin.

If I check out the actual master and manually revert this single commit (map USART2 RX to PA15 instead of PA3), then it works again as it should.

If anyone has this particular Nucleo board, feel free to verify the presence of this issue.

On which OS does this issue occur?

[Linux]

What is the version of your OS?

Ubuntu 22.04 LTS

NuttX Version

master

Issue Architecture

[arm]

Issue Area

[Board support]

Verification

• I have verified before submitting the report.

[davidgnx]

@rcsim : Could you please check this? I don't know if you've just mixed up PA3 and PA15 or are there multiple revisions of the board out there?

[davidgnx]

Here is some extra information.
I've just checked the NuttX documentation:
https://nuttx.apache.org/docs/latest/platforms/arm/stm32l4/boards/nucleo-l432kc/index.html

Based on the documentation (is it up-to-date?), I am not sure if the default nsh config should use the virtual COM provided by the on-board ST-LINK, I find it fairly practical, because a single USB cable is enough to program and then to communicate with the MCU. Before this commit it worked out of the box. I assumed that this is the goal of the nsh config, to make NSH work with the virtual COM, but maybe it isn't, I just wanted to make you aware of this use case (and possible other use cases) in mind before changing something.

[rcsim]

Hi @davidgnx ,

I will double-check this and update you as soon as I can, sorry for any inconvenience.

Thanks

[davidgnx]

Thank you, no worries, I figured out how to make it work for my use case, just wanted to make you aware of this. I don't know if it was intended or whether the virtual COM should be the default way to use NSH or not.

[rcsim]

Hi @davidgnx ,
I'm reverting 7b9b630 as I agreed that accessing NSH via virtual COM port is a preferred solution.

Thanks for bringing my attention to this issue and sorry for any inconvenience I may have caused.

Best regards,

[davidgnx]

Thank you for the quick fix, I assume it is not just for me, I guess many others like the fact about the Nucleos that they can be used with a single USB cable. No worries about any inconveniences, I just wanted to ask whether it was intended or not, anyway thanks again!