cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L475RE Connection lost

netsbats
Associate II

Hello together,

I am currently trying to program a STM32L475RET6. But I have the problem that when I connect the programmer and click on connect, a connection can be established, but it disappears after only a short time with the error "connection lost".

I have already made a few designs and projects with the L4, but never observed such behavior. Has anyone been able to observe this behavior?

Message from STM32Cube Programmer: 

Spoiler

06:57:38 : UR connection mode is defined with the HWrst reset mode
06:57:38 : ST-LINK SN : 0036004F3331511934333834
06:57:38 : ST-LINK FW : V3J10M3B5S1
06:57:38 : Board : STLINK-V3SET
06:57:38 : Voltage : 3.29V
06:57:38 : SWD freq : 8000 KHz
06:57:38 : Connect mode: Normal
06:57:38 : Reset mode : Hardware reset
06:57:38 : Device ID : 0x415
06:57:38 : Revision ID : Rev 4
06:57:38 : Debug in Low Power mode enabled.
06:57:38 : UPLOADING OPTION BYTES DATA ...
06:57:38 : Bank : 0x00
06:57:38 : Address : 0x40022020
06:57:38 : Size : 20 Bytes
06:57:38 : Bank : 0x01
06:57:38 : Address : 0x40022044
06:57:38 : Size : 16 Bytes
06:57:38 : UPLOADING ...
06:57:38 : Size : 1024 Bytes
06:57:38 : Address : 0x8000000
06:57:38 : Read progress:
06:57:38 : Data read successfully
06:57:38 : Time elapsed during the read operation is: 00:00:00.002
06:57:40 : Error: Unable to get core ID
06:57:40 : Error: Unable to get core ID
06:57:40 : Error: Unable to get core ID
06:57:40 : Warning: Connection to device 0x415 is lost
06:57:40 : Disconnected from device.

 

1 ACCEPTED SOLUTION

Accepted Solutions
netsbats
Associate II

I think I have it now, and it's pretty stupid.

Out of desperation I changed the programmer or used a ST-Link V2 from a Nucleo board. First only with the most necessary pins, VCC, SWCLK, SWDIO, NRST and GND.

With this configuration I could suddenly program and debug.
Next I connected the USART pins for the debug outputs and it didn't work anymore.
Then I swapped the USART pins and it suddenly worked again.

So I took the ST-Link V3 again, swapped the pins on the MCU by firmware and lo and behold, that works too.

That means, I will have to swap the RX/TX lines on my PCB

 

I have now tested this for an hour and it seems to work.

View solution in original post

7 REPLIES 7
netsbats
Associate II

Since I don't know for what I have to look, I measured the voltage on each Pin: 

  • +3.3V -> 3.30V
  • SCLK -> 72mV
  • SWDIO -> 65mV
  • NRST -> 3.29V
  • SWO -> N/C
  • GND -> 0V

While I measured this pins the programmer (ST-Link V3) was connected

AScha.3
Chief III

from my experience this happens if

a. connection is bad (bad contact or long wires)

b. spikes from mains coming in ; if you supply target not from USB (where stlink is also) your connection is prone to catch inductive or capacitive coupled spikes from mains;

i had exactly this behavior here at my PC . "connection lost" every some minutes or an hour.

then plugged in mains -> target supply at the PCs (filtered) master-slave socket strip and cable routed near usb-cable to target; target has mains filter and mains earth also; now debug can run many hours without any problem.(and still 2,5m away from PC , stlinkV3 -target cable about 20cm long, at full speed 24MHz + 16Mhz SWO)

try this.

If you feel a post has answered your question, please click "Accept as Solution".

Thank you very much for your answer.
I have now done the following to solve the problem:

1. i had to change the 100nF capacitor on the NRST pin of the MCU, was not a short circuit, but had a low impedance, or always a low voltage.

2. noticed that there was no clean 5V coming from the PCB (small dips were noticeable). The PCB was connected via USB-C to a USB-C port on the PC. I have now taken a 5V USB power supply.

With these changes it now looks like it is running stable.

OK again too early, after 4x code upload I have now again the same problem...

 

  16:35:04 : STM32CubeProgrammer API v2.13.0 | Windows-64Bits 
  16:35:08 : UR connection mode is defined with the HWrst reset mode
  16:35:08 : ST-LINK SN  : 0036004F3331511934333834
  16:35:08 : ST-LINK FW  : V3J11M3B5S1
  16:35:08 : Board       : STLINK-V3SET
  16:35:08 : Voltage     : 3.30V
  16:35:08 : SWD freq    : 8000 KHz
  16:35:08 : Connect mode: Normal
  16:35:08 : Reset mode  : Hardware reset
  16:35:08 : Device ID   : 0x415
  16:35:08 : Revision ID : Rev 4
  16:35:08 : Debug in Low Power mode enabled.
  16:35:08 : UPLOADING OPTION BYTES DATA ...
  16:35:08 :   Bank          : 0x00
  16:35:08 :   Address       : 0x40022020
  16:35:08 :   Size          : 20 Bytes
  16:35:08 :   Bank          : 0x01
  16:35:08 :   Address       : 0x40022044
  16:35:08 :   Size          : 16 Bytes
  16:35:08 : UPLOADING ...
  16:35:08 :   Size          : 1024 Bytes
  16:35:08 :   Address       : 0x8000000
  16:35:08 : Read progress:
  16:35:08 : Data read successfully
  16:35:08 : Time elapsed during the read operation is: 00:00:00.003
  16:35:11 : Error: Unable to get core ID
  16:35:12 : Error: Unable to get core ID
  16:35:12 : Error: Unable to get core ID
  16:35:12 : Warning: Connection to device 0x415 is lost
  16:35:12 : Disconnected from device.

 

 And now just when I tried it again in the CubeIDE it worked. But I guess as soon as I write this it will not work again.

did you plug in the supply on same socket as the PC? + supply should have mains earth (2 pole mini warts may be not so good)

If you feel a post has answered your question, please click "Accept as Solution".

Yes it's on the same rail

 

netsbats
Associate II

I think I have it now, and it's pretty stupid.

Out of desperation I changed the programmer or used a ST-Link V2 from a Nucleo board. First only with the most necessary pins, VCC, SWCLK, SWDIO, NRST and GND.

With this configuration I could suddenly program and debug.
Next I connected the USART pins for the debug outputs and it didn't work anymore.
Then I swapped the USART pins and it suddenly worked again.

So I took the ST-Link V3 again, swapped the pins on the MCU by firmware and lo and behold, that works too.

That means, I will have to swap the RX/TX lines on my PCB

 

I have now tested this for an hour and it seems to work.