STM32F051 debugger and pin remapping

[benjamin239955]

Posted on March 05, 2014 at 15:31

Hi All,

I am facing the weird problem. I use STM32F0 discovery kit. I have my setup fully working with debugger integrated in eclipse. 

At some point, I decided to remap PA11 to AF_1 so that I can use the UART1 with flow control. When the pin is remapped, I cannot connect the STLINK to the MCU anymore. 

I did some Logic analyzer traces of the SWD interface. I am not yet able to decode successfully the frame when it works and when it does not, but they are not the same at all. 

I had a thorough look at the debug documentation in the RM0091 and I do not see any debug features link to PA11.

Did I miss something obvious. I have to tell that outside the debugger, my firmware is running fine, with or without the pin remap. 

[Tesla DeLorean]

Posted on March 05, 2014 at 16:09

Did I miss something obvious.

Hard to say, what you've described doesn't sound like it should cause a problem, can you supply code that demonstrates the failure mode?

[frankmeyer9]

Posted on March 05, 2014 at 16:17

Did I miss something obvious.

 

Perhaps.

As I realized a few days ago, the STM32F0 discovery is no longer equipped with a F051 MCU, but a F072 instead.

It should be easily readable on the print, directly below the gyro chip.

[benjamin239955]

Posted on March 05, 2014 at 16:27

Thanks for your prompt answers.

I think it's a STM32F051. The discovery board version is MB1034B. Anyway, I will cross check, but I doubt it as I had no trouble with remmaping of the others pin. 

I will make a sample code I will provide tonight, and send analyzer capture of the activity on the SWD pins. 

As far as I understand the SWCLK and SWDIO pins are managed by the STLINK. Is there anything else which I would miss?

Thanks,

Ben

[frankmeyer9]

Posted on March 05, 2014 at 16:41

As far as I understand the SWCLK and SWDIO pins are managed by the STLINK. Is there anything else which I would miss?

 

One side is managed by the STLink (F103), the other by the target, i.e. the F051.

If you remap (and reuse) this pins on the target side, you surely lose the SWD connection.

Better check the datasheet...

[benjamin239955]

Posted on March 05, 2014 at 16:54

Actually the debugger pins are PA13 and PA14. I do not touch those pins. 

The procedure is the following:

- connect the stlink to the target

- load the code to remap the PA11

- break

- Visually check the remap confi is correct in the GPIO AFH function. 

- Disconnect

- Try to reconnect

The reconnection fails. 

If I load the same code wihtout the call the to PinRemap function, the reconnection will work fine. When I load the code and remap, I can still execute debugger commands  after the remap, as long as I do not disconnect.

[Tesla DeLorean]

Posted on March 05, 2014 at 18:40

  GPIO_PinAFConfig(GPIOA, GPIO_PinSource11, GPIO_AF_1); // Fudge Pin, check SWD

Causes no discernible debugging issues with Keil, with USART1 using PA9/PA10

[frankmeyer9]

Posted on March 05, 2014 at 19:33

Maybe this issue is related to your environment.

The GDB server output (usually in one of those Eclipse consoles) can give you a hint.

[benjamin239955]

Posted on March 06, 2014 at 10:31

Hi,

Thanks for your help. I still don't understand the issue but it's kind of fixed. 

I rewrote a piece of code to post it here an the issue disappeared. So it's not really the pin remapping. It's the pin remapping + something in my environment. 

Thank you very much for you suggestions

Ben