SWD not working on STM32F303RET6

[svjatoslav]

Posted on September 22, 2015 at 23:51

Hi all,

My problem is quite unusual, and I need some new ideas.

I can't make SWD connection working on STM32F303RET6. I'm constantly getting ''Can not connect to target'' message.

• I have installed the latest version of ST-LINK, and also upgraded the debugger firmware to the latest version.

• I have tried the same debugger with STM32F303CCT6, and it works fine.

• I tried two STM32F303RET6 MCUs to make sure this is not an occasional MCU defect.

• I checked the errata sheet, and didn't found any SWD problem there.

• I have checked the electrical connections dozen times, comparing with both STM32CubeMX and MCU datasheet.

• SWD pins aren't used in my circuit

• Empty MCU (new, without any firmware) acts the same way.

• I'm still able to boot in DFU mode, and upload firmware with USB. This makes me think the MCU is powered up correctly.

What could possibly go wrong?

#swd #stm32f303ret6

[Tesla DeLorean]

Posted on September 23, 2015 at 00:42

Well isn't one of those chips a 48 pin LQFP and the other a 64 pin? So assuming the chip that works is on a different board, that works, and it STILL points to an issue on the other board related to the debug connectivity.

Perhaps you can use the USB DFU to put code on the board that DOES use the SWD pins, and confirm you can see them toggle, and that you can make them toggle at different rates and confirm you can see both, and they are on the correct pin headers.

[svjatoslav]

Posted on September 23, 2015 at 12:40

Good idea!

According to STM32CubeMX, the SWIO is PA13, anf SWCLK is PA14. So I did the following code to send two pulses on PA13 and one on PA14:

int main(){

    setup();

    while(1){

        GPIOA->BSRRL=GPIO_BSRR_BS_13; // PA13 ON

        sleep_ms(1);

        GPIOA->BRR=GPIO_BRR_BR_13; // PA13 off

        sleep_ms(1);

        GPIOA->BSRRL=GPIO_BSRR_BS_13; // PA13 ON

        sleep_ms(1);

        GPIOA->BRR=GPIO_BRR_BR_13; // PA13 off

        sleep_ms(1);

        

        GPIOA->BSRRL=GPIO_BSRR_BS_14; // PA14 ON

        sleep_ms(1);

        GPIOA->BRR=GPIO_BRR_BR_14; // PA14 off

        sleep_ms(1);

    }

}

The result: it works. I see exactly these signals on SWD connector:

http://svimik.com/swdtest1.png

[svjatoslav]

Posted on September 23, 2015 at 17:16

Now I bought another board with ST-Link debugger, and here are my testing results

Debugger -> stm32f4-discovery   nucleo-f401re   USB Bootloader (DFU)

STM32F303CCT6  

yes

 

yes

 

yes

STM32F303RET6  

no

 

no

 

yes

Looks like SWD just doesn't work in STM32F303RET6.

.ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 {border-width:0px;border-style:none;border-collapse:collapse;font-family:Tahoma;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 tr.telerik-reTableHeaderRow-1 {margin:10px;padding:10px;color:#3F4D6B;background:#D6E8FF;text-align:left;font-size:10pt;font-style:normal;font-family:Tahoma;text-transform:capitalize;font-weight:bold;border-spacing:10px;line-height:14pt;vertical-align:top;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 td.telerik-reTableHeaderFirstCol-1 {padding:0in 5.4pt 0in 5.4pt;color:#3a4663;line-height:14pt;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 td.telerik-reTableHeaderLastCol-1 {padding:0in 5.4pt 0in 5.4pt;color:#3a4663;line-height:14pt;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 td.telerik-reTableHeaderOddCol-1 {padding:0in 5.4pt 0in 5.4pt;color:#3a4663;line-height:14pt;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 td.telerik-reTableHeaderEvenCol-1 {padding:0in 5.4pt 0in 5.4pt;color:#3a4663;line-height:14pt;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 tr.telerik-reTableOddRow-1 {color:#666666;background-color:#F2F3F4;font-size:10pt;vertical-align:top;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 tr.telerik-reTableEvenRow-1 {color:#666666;background-color:#E7EBF7;font-size:10pt;vertical-align:top;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 td.telerik-reTableFirstCol-1 {padding:0in 5.4pt 0in 5.4pt;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 td.telerik-reTableLastCol-1 {padding:0in 5.4pt 0in 5.4pt;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 td.telerik-reTableOddCol-1 {padding:0in 5.4pt 0in 5.4pt;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 td.telerik-reTableEvenCol-1 {padding:0in 5.4pt 0in 5.4pt;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 tr.telerik-reTableFooterRow-1 {background-color:#D6E8FF;color:#4A5A80;font-weight:500;font-size:10pt;font-family:Tahoma;line-height:11pt;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 td.telerik-reTableFooterFirstCol-1 {padding:0in 5.4pt 0in 5.4pt;border-top:solid gray 1.0pt;text-align:left;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 td.telerik-reTableFooterLastCol-1 {padding:0in 5.4pt 0in 5.4pt;border-top:solid gray 1.0pt;text-align:left;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 td.telerik-reTableFooterOddCol-1 {padding:0in 5.4pt 0in 5.4pt;text-align:left;border-top:solid gray 1.0pt;} .ExternalClass864ED2B0A0EA474797625FC903C1B31F .telerik-reTable-1 td.telerik-reTableFooterEvenCol-1 {padding:0in 5.4pt 0in 5.4pt;text-align:left;border-top:solid gray 1.0pt;}

[Tesla DeLorean]

Posted on September 23, 2015 at 19:06

Well they sell a

http://www.digikey.com/product-detail/en/NUCLEO-F303RE/497-15105-ND/5052640

on it, so I'm not entirely convinced it's a chip level issue.

Can a J-Link or U-Link access the device? If you built your board with a F401RE on it does that work?

Does your debug interface expose NRST and SWO?

[svjatoslav]

Posted on September 23, 2015 at 19:41

>Can a J-Link or U-Link access the device?

Will try U-Link. But last time it failed even when ST-Link worked (U-Link's SWD never worked for me, maybe something wrong with the drivers or SWD mode just not compatible with Keil 4).

>If you built your board with a F401RE on it does that work?

Are you asking to solder F401RE off from Nucleo, and put onto my board? Is it pin compatible with STM32F303RET6?

>Does your debug interface expose NRST and SWO?

Nope, I use 3 wires (TCK, GND, TMS).

[Tesla DeLorean]

Posted on September 23, 2015 at 21:37

Can't say I've have issues use SWD connectivity with J-LINK or U-LINK pods, but then again I use standard 10-pin and 20-pin type debug headers, and the devices can attempt to ''connect under reset'' as they can hold the devices in reset, or get them into an initial known state.

I suspect the 64-pin configuration is very close, not looking to do the due diligence on that. And don't have an F303 Nucleo to eye-ball the solder bridge or PCB differences.

[svjatoslav]

Posted on September 24, 2015 at 00:26

Well, U-LINK actually can see the device:

http://svimik.com/ulinkopt1.png

But now I remembered why I stopped using U-LINK some time ago: it throws errors like a rain.

First it was: Cannot load flash programming algorithm

Then it was: Invalid ROM Table

After playing with reset options (there are many combinations (ok, actually four, but the right one is like a random)) it finally uploaded the firmware, and it even works(!), but the validation fails:

Contents mismatch at: 08000000H  (Flash=FFH  Required=00H) !

Contents mismatch at: 08000001H  (Flash=FFH  Required=89H) !

Contents mismatch at: 08000002H  (Flash=FFH  Required=00H) !

Contents mismatch at: 08000003H  (Flash=FFH  Required=20H) !

But that's another story (that's U-LINK problems, and I'm not sure this is the right place to complain about that). Anyway, it does upload the firmware.

  ST-Link U-LINK

STM32F303CCT6

yes

yes

 

STM32F303RET6

no

 

yes

.ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 {border-width:0px;border-style:none;border-collapse:collapse;font-family:Tahoma;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 tr.telerik-reTableHeaderRow-1 {margin:10px;padding:10px;color:#3F4D6B;background:#D6E8FF;text-align:left;font-size:10pt;font-style:normal;font-family:Tahoma;text-transform:capitalize;font-weight:bold;border-spacing:10px;line-height:14pt;vertical-align:top;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 td.telerik-reTableHeaderFirstCol-1 {padding:0in 5.4pt 0in 5.4pt;color:#3a4663;line-height:14pt;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 td.telerik-reTableHeaderLastCol-1 {padding:0in 5.4pt 0in 5.4pt;color:#3a4663;line-height:14pt;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 td.telerik-reTableHeaderOddCol-1 {padding:0in 5.4pt 0in 5.4pt;color:#3a4663;line-height:14pt;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 td.telerik-reTableHeaderEvenCol-1 {padding:0in 5.4pt 0in 5.4pt;color:#3a4663;line-height:14pt;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 tr.telerik-reTableOddRow-1 {color:#666666;background-color:#F2F3F4;font-size:10pt;vertical-align:top;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 tr.telerik-reTableEvenRow-1 {color:#666666;background-color:#E7EBF7;font-size:10pt;vertical-align:top;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 td.telerik-reTableFirstCol-1 {padding:0in 5.4pt 0in 5.4pt;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 td.telerik-reTableLastCol-1 {padding:0in 5.4pt 0in 5.4pt;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 td.telerik-reTableOddCol-1 {padding:0in 5.4pt 0in 5.4pt;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 td.telerik-reTableEvenCol-1 {padding:0in 5.4pt 0in 5.4pt;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 tr.telerik-reTableFooterRow-1 {background-color:#D6E8FF;color:#4A5A80;font-weight:500;font-size:10pt;font-family:Tahoma;line-height:11pt;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 td.telerik-reTableFooterFirstCol-1 {padding:0in 5.4pt 0in 5.4pt;border-top:solid gray 1.0pt;text-align:left;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 td.telerik-reTableFooterLastCol-1 {padding:0in 5.4pt 0in 5.4pt;border-top:solid gray 1.0pt;text-align:left;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 td.telerik-reTableFooterOddCol-1 {padding:0in 5.4pt 0in 5.4pt;text-align:left;border-top:solid gray 1.0pt;} .ExternalClass9B0958E9846B43628C4006AF34D10684 .telerik-reTable-1 td.telerik-reTableFooterEvenCol-1 {padding:0in 5.4pt 0in 5.4pt;text-align:left;border-top:solid gray 1.0pt;}

This reminds me about the first question: why ST-LINK can't work with STM32F303RET6 while it's totally fine with STM32F303CCT6?

>I use standard 10-pin and 20-pin type debug headers

Well, we make really small devices. This board was 13x36mm, while BoM count is... 79. Can you imagine 10-pin or 20-pin debug header there? :)

[Tesla DeLorean]

Posted on September 24, 2015 at 03:41

The reset options only have any value if NRST is connected. Otherwise you're likely to get weirdness because it can't use a two wire protocol very effectively to wrestle control of the part from all states.

When you can't get a header, being able to escape the signals via castellations or between the layers can help considerably in the design/debug phase. The entire JTAG complement gets you boundary scan, and between the layers a row/panel. I've seen people put SMT land patterns on the reverse side of a board.

You said you had the latest firmware on the ST-LINK, which one is that, because we're not getting droves of people here complaining that the Nucleo F303RE isn't working, and the law of large numbers says we would if there was something inherently wrong with the chip or the firmware. The Nucleo boards are up at something like V2.J24.M11