Usart2 on STM32F401RE is not working after cutting st-link

[SLise]

As I know, Virtual COM port of ST-Link connection is connected to Usart2 on a STM32F401Re. When, ST-Link part is still attached everything is working fine on Usart2.

However, after cutting ST-Link part of the PCB, I am trying to connect a USB-TTL converter to PA2/PA3 pins and it is not working.

Power is maintained by USB-TTL converter, therefore JP5 is settled to E5V. Power delivery is quite OK. However, I can not get TX-RX work. I also tried to close SB62 & SB63 bridge solders. Nothing changed.

How can I connect F401RE board using usart2 to PC without using VirtualCom supplied by ST-link? Thanks.

[Ozone]

Not sure about the actual wiring between the target and your USB-TTL converter, but that doesn't work that way.

The STM32 is 3.3V, and cannot drive a proper TTL H level. The UART pins are, AFAIK, 5-Volt tolerant.

Try a 3.3V compatible converter, or add level-shifting hardware. I used to have simple BJT-based level shifters, that works fine at least up to 115,2 kbps.

[Tesla DeLorean]

PA2 (D1) -> USB-TTL-RX

PA3 (D0) <- USB-TTL-TX

Review schematic for board

Review signals with a scope

Without the debug board the 8 MHz HSE signal will not be present, use the HSI to drive the PLL

[SLise]

I already tried the pin connections that you suggest. I tried solder bridge configurations written in manual. I reviewed schematics. Then I tried every possible pin connections. Not working. I am driving two 5V small homemade boards with STM32F401RE. Therefore working with 3.3 V is not suitable for me.

[SLise]

I am driving two 5V small homemade boards with STM32F401RE. These boards also producing 5V TTL levels, and they are working fine. My problem is understanding the difference between STMF103 driving STMF401 and USBTTL converter driving STMF401. The latter is not working.

[Ozone]

Have you noticed the last comment about HSE ?

The "newer" discovery and Nucleo boards have no quartz crystals for the target anymore, but clocked by MCO from the STLink MCU.

When cutting the STLink off, you need to rework the clock setup.

Else the setup fail, falls back to HSI default settings (no PLL), which surely doesn't fit you clock/baudrate calculations.

[SLise]

Thanks for noticing. When you mentioned, I understood the problem. However, I have got only the bin file. Therefore, for now, I can not change the calculations.

Therefore, reconnecting ST-Link to Nucleo can be logical. For this, I opened SB13-14 on ST-Link board (As I understood from schematics, after cutting, open or close are not important for SB13-14) and I closed SB62-63 on Nucleo board (also tried opened, nothing changed). Changed JP5 to E5V. I drove the circuit from ST-Link's T2 chips pin1 (VCC) 5V to CN7's E5V pin. I connected ST-Link's CN3 pins to Nucleo's CN10 PA2-3 ports (also tried CN9 TX-RX ports when SB62-63 closed). Not working :(

[Ozone]

> However, I have got only the bin file. Therefore, for now, I can not change the calculations.

Sounds pretty much like an unfortunate "black box " situation. If you know neither the firmware internals, nor the actual state of the hardware, you probably have a hard time.

I would trying to get and build the project from source, and get it running. That would not "kill" your bin file option.

[Tesla DeLorean]

Skiing this problem uphill both ways..

You're going to have to change the way you're approaching this. Being inflexible and not looking at what is actually going on at a signal level is not the approach I would take. Debug the solution before breaking off the debugger, not afterwards. Remove the MCO solder bridges first to check the clock source issues. Instrument the infinite loops, ie Hard Fault and Error Handler, so you can get data from a secondary UART connection in the absence of the ST-LINK. Perhaps also provide a means of doing a firmware update over said UART.