Serial over usb/stlink doesn't work on F7 disco/nucleo

[k0d]

I have tried different gpio settings according to the stm32cube code. Have you had this working?

[k0d]

Both Stm32f746

[danielinux]

Hello, we don't have a CDC-ACM driver at the moment. I am adding this as feature request, but we need to wait until the new USB support makes into unicore-mx before adding new drivers. Ref: insane-adding-machines/unicore-mx#26

This is now superseeded by #85

[k0d]

Sorry, I described this issue badly. I was referring to the serial console that is accessible over the st-link when you plug it into the computer. On the STM32f746-DISCO board, it's connected to A9 and B7 I think.

In code I have from STM32Cube/Mbed/Nuttx, it all works...so I think it's just some settings. I actually get some output but it's garbled...I wonder if something else is pushing out data on those ports.

[k0d]

I've tested a lot more now, and I'm still getting garbage on the in-built serial debugger (D8/D9 on nucleo). It works on USART6 just fine.

[danielinux]

I was not aware of such interface. However, A9 pin is normally connected to UART1.

To check which pins are in use, you can always use cat /sys/pins.

Where can I find more info about this serial interface towards the st-link chip? Can you try enabling a UART with correct pin muxing in kernel/stm32f7/stm32f746nucleo-144.c and see if you can get a console on that interface?

[k0d]

Nucleo_printf.zip

The attached file is a project from mbed, that will compile for the Nucleo-F746ZG and output on the USB serial at 9600bps. There is a precompiled binary in the .build folder.

I first learnt about it from this site. http://www.carminenoviello.com/2015/03/02/how-to-use-stm32-nucleo-serial-port/

It is very convenient to use this instead of an external usb2serial device.

[danielinux]

Ah, this should be the debugger semihosting interface. I don't think we ever compiled the kernel with semihosting enabled, and that's not a real serial interface. @maximevince do you know whether we can enable semihosted printfs?

[k0d]

#ifdef CONFIG_USART_3
    {
        .devidx = 3,
        .base = USART3,
        .irq = NVIC_USART3_IRQ,
        .rcc = RCC_USART3,
        .baudrate = 115200,
        .stop_bits = USART_STOPBITS_1,
        .data_bits = 8,
        .parity = USART_PARITY_NONE,
        .flow = USART_FLOWCONTROL_NONE,
        .pio_tx = {
            .base=GPIOD,
            .pin=GPIO8,
            .mode=GPIO_MODE_AF,
            .af=GPIO_AF7,
            .speed=GPIO_OSPEED_25MHZ,
            .optype=GPIO_OTYPE_PP,
        },
        .pio_rx = {
            .base=GPIOD,
            .pin=GPIO9,
            .mode=GPIO_MODE_AF,
            .af=GPIO_AF7,
            .pullupdown=GPIO_PUPD_NONE
        },
    },
#endif

This screenshot has both USART3 and USART6 with FrostedSH outputting on them.

[k0d]

I don't think semihosting is the issue actually...I have it working with many other examples from mbed/nuttx/stm32cube. I believe it's something to do with the timings, as the data comes out...just garbled. I did try editing the gpio speed (.speed=GPIO_OSPEED_25MHZ) but I don't really know how that works or if that is the issue.

[danielinux]

by default the shell points to /dev/ttyS0, which is the first serial port discovered. If as you said it's possible to access the FTDI on the st-link as a normal serial port, this is indeed interesting because it would allow us to run a shell without an external FTDI, but I suspect that's more to do with semihosting interface rather than plain serial ports.

If you expect this to work as a normal serial port, you might want to try and set a different baudrate...

[k0d]

I've added a 2nd fresh instance (fresh -t /dev/ttyS1 &).

It works for sure in other OS's, so I think it's just a config issue

I've tried a different baud rate, and I've even connected a logic analyzer to the pins on the st-link tx/rx pins (they're clearly marked on that part of the board), and all it gives me is badly timed output.

My next step...I'll connect both USARTS to the logic analyzer and check the exact timings to see if it's the right 'on/off/on/off' signals, just badly timed.....

[k0d]

I solved it :) :) :)

I checked the timings with my logic analyzer as I said, and it turns out it was working at half the speed it should be. So if I have 115200 in the config, but set my mac to communicate over 57600 it works.

So I guess there is some underlaying timing issue that needs to be fixed, any ideas on that?

[danielinux]

Could it be an issue of unicore-mx, not properly supporting speed setting on F7 yet?

Related code: https://github.com/insane-adding-machines/unicore-mx/blob/07f9079fa59179b4ba7b9f3cdfbb2a2be580bed1/lib/stm32/common/usart_common_all.c#L47

If we can write a small example (e.g. in unicore-mx-examples), it could prove that the problem is actually there.

Thank you very much for enlightening us on this (very comfortable) USART3 crossing the st-link chip.

[k0d]

I'll look into it more, and will check unicore-mx as you suggest.

It is very nice to use, cuts down on the number of cables!

I also wonder if the timings issue is causing issues with the ethernet also. As I had the exact same problems on my STM32F746-DISCO board.

[danielinux]

This is really appreciated, thanks. Could you also be so kind to make a PR with the USART3 config you posted a few comments above, on the board files where this applies?

If you want quicker feedback, you can find us on irc://irc.freenode.net/#frosted

[k0d]

Same issue with unicore-mx-examples, but this time I used the DISCO. So I'll investigate more with that project now.

I'll add a PR when I've tested it on both boards and fixed things a bit more...maybe today, maybe tomorrow.