ST-LINK does not communicate with STM32F407VGT

[Gregorio Vidal]

Posted on January 23, 2017 at 16:19

Hi everybody,

I have a problem with my project. I designed and produced a PCB with two MCUs, the STMF401RB and the STM32F407VGT. I am using the ST-LINK V2 to program them and SWDIO and SWCLK. The problem that I have is that I can connect to the STMF401 but I can't connect to the STMF4 I checked the VDD and VSS in every pin and they seem to be ok. I think the design is ok but may be i missed something. I have attached the schematic that I used for the STMF4 I would be grateful if you can help me.

Thank you very much

Regards

Gregorio

#st-link #stm32f407 #pcb-design Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Tesla DeLorean]

Posted on January 24, 2017 at 18:57

>>

Can I used the USART3 PB10/PB11? 

Yes, these should be viable. We always make the System Loader accessible in our designs

The quick test with RealTerm is to send the 0x7F character at 9600 8E1 (Even Parity), and see if you get the 0x79 response.

[Nemui Trinomius]

Posted on January 25, 2017 at 07:06

Dear Gregorio Vidal,

Wire NRST on target board to STLink/V2's RST output.

And use ST-Link Utility with 'connect under reset' option.

Connect under reset is useful for recovery from any unstable state.

[Gregorio Vidal]

Posted on January 25, 2017 at 18:12

I tried the boot-loader as you told me using USART3. When I sent 0x7F I received strange characters but not 0x79. 

After that I used the sofware STM Flash Loader, with the same configuration as in the previous test ( USART 3 and BOOT0 High) and I could erase the memory and load a program in the microcontroller and it worked, what Is good. At least, I can load my program in the micro and continue with the project But I would like to know why the SWD does not work and why I don't receive 0x79 when i send 0x7F ? What does it mean? Could the chip be damaged?

Thank you

[Tesla DeLorean]

Posted on January 25, 2017 at 21:30

How exactly do you have it wired? You need to use a CMOS-to-Serial type converter for the 3V signalling, as this isn't compatible with RS232 levels.

You must use Even Parity, but you could try different baud rates. It uses a timer to measure the bit timing on the 0x7F pattern. The System Loader is going to be sensitive to transitions on any of the pins it is initially monitoring. If you have action on PA9/PA10 this may be an issue.

[Gregorio Vidal]

Posted on January 26, 2017 at 12:38

I used a USB to USART cable converter which has a label where you can read 'TTL-232R-3V3' so I suppose that it is right. I used even parity and i tried different baud rate with the same result. The pins PA9 and PA10 are not connecting and are not being used.

As I put in my l last post I could load a simple program which changed the state of PD2 every second and It worked. But today when I tried to use the boat-loader again to load a different program i couldn't. I tried the

STM Flash Loader but it did not connect. I tried to send to send 0x7F and I did not receive a repond or sometimes i received 00 or strages characters but no with a pattern.  I am using the same configuration as yesterday. An the program that i load yesterday is running as the PD2 changes every seconds, so the micro is working. But why I cant connect via USART today? Could the program that I loaded change something? any idea?

Thank you

[Mon2]

Posted on January 26, 2017 at 14:03

Please share more details of your USB to USART cable. Which controller is onboard this cable ?

Is this the FTDI based USB to USART cable ? Is there a 1 x 6 header at the end of this cable ?

That should be ok to use. This cable also features hardware flow control lines so please short pin 2 & 6 together on the cable connector (CTS & RTS) to disable hardware flow control.

We are performing similar testing with the STM32F070 with the ROM DFU and no issue to use the USART pins to access the boot loader with the STM Flash Loader. We are using a Silicon Labs cable @ 3v3 CMOS levels.

=============

Please confirm the wiring between the USB USART cable and your micro on your custom board.

What is the datecode of your micro ? Do you have the related STM Discovery board for similar testing ? That board should be helpful to compare notes on the USART Bootloader operation.

http://www.st.com/en/evaluation-tools/stm32f4discovery.html

 

=============

With the external USB to USART cable connected to your custom board, launch the STM Flash Loader software. Leave the STM Flash Loader running and confirm that BOOT0 on your CPU = VDD (3v3). Then power cycle your custom board for a power on reset to kick on. Does the STM Flash Loader detect the CPU ? You must have both the TX & RX pins of the USART interface connected along with a common ground between the cable and custom PCB. Confirm that your USB USART cable device driver is current and the latest version for your Windows operating system.

[Gregorio Vidal]

Posted on January 26, 2017 at 14:25

Yes, I think is the FTDI USB to USARTcable, with the 1x6 header at the end of the cable as you said. I used it before for the arduino nano. I will try to short pin 2 and 6 and let see what happens. Yesterday I did not have problem to access, but after loading a program I could not, so I was wondering if it is the reason of that or not.

I checked the level of Boot0 and is hight and even i put Boot1(PB2) low, with no success.

Thank you

[Gregorio Vidal]

Posted on January 30, 2017 at 10:35

I did everything that you said and It did not work. The configuration was right as I tried with the STM32F407 Discovery board and It worked. Finally solder two wires to the pins of the micro to use the USART1(PA9 and PA10) and It worked. It is not the best solution but at least I can load a program in the MCU. But why the USART3 doesn't work? Any ideas?

Thank you

[pohtv]

Posted on February 05, 2017 at 08:42

Mmmm...

Target:Detection fail and Target voltage: Detection fail

doesn't seem to sound good.

[Mon2]

Posted on February 05, 2017 at 14:11

I agree. Perhaps obvious by now, but there is something not correct on the STM32F407 custom PCB.

Are you in SWD mode with your ST-Link/V2 tool ?

What is the measured voltage of the VDD rail without connection to the ST-Link/V2 tool ?

What is the measured voltage of the VDD rail with connection to the ST-Link/V2 tool ?

You should be able to make use of the ST-Link/V2 interface from a Discovery board as well.

Target voltage detected: 2.904680

That is very low and should be closer to the 3v3 value. What is your power source ? Strip down the design to just the STM32F407 CPU and test again. Confirm your power source voltage without a load and then again with your custom PCB.

How much current is your custom PCB sinking ?

Reference:

http://electronics.stackexchange.com/questions/206521/how-to-use-external-st-link-to-debug-program-stm32f103-mcu?rq=1

 

http://electronics.stackexchange.com/questions/230036/problems-connecting-st-link-v2-and-stm32f4-discovery-board

 

http://electronics.stackexchange.com/questions/182763/how-to-use-an-external-st-link-v2-with-the-stm32f4-discovery-board?rq=1

Update:

=====

Your VDDA and VDD rails are tied together. That is risky. There should have been at least a ferrite bead between these 2 rails.

The ST reference schematics feature this component (L1) is missing from your custom PCB. You can source very low cost yet high quality ferrite beads from Max Echo (Taiwan). We have used this vendor for many years with success.

The ST reference schematics feature a 47 ohm resistor between VDD and VREF. This component (R23) is missing from your custom PCB.

Remove the LCD display noted in your custom PCB schematic and confirm the voltage on the CPU only. What is the LCD BACKLIGHT on PD2 ? How does that work ?

Something in this custom PCB is tanking the voltage rails...