STM32F373 can't set GPIOB->AFRL for PB3 to USART

[Oliver Sedlacek]

I'm using USART2 on PB3 and PB4 which means setting the AFR bits for those GPIO pins to 7. The CubeMX wizard and HAL GPIO libraries agree with this, but the AFR bits for PB4 stubbornly revert to 0 and my USART wont transmit. What is going on? I've tried my own code and the behaveiour doesn't seem any different. Using a data access breakpoint I can catch the expected writes and in the debugger I can set the AFR momentarily, but then it reverts. The lock register reads zero.

Is it a hardware issue?

[TDK]

Can you set PB0-PB2 to AF mode or do all fields in AFRL behave this way? Are you sure the chip isn't resetting? Nothing unique to PB3/PB4 that I know about. If you single step through the code, it becomes 1 and then immediately reverts to 0 after another step?

[Tesla DeLorean]

PB3 is used for the SWO/TDO output in SWV/JTAG, the debugger may fiddle with this setting, or there might be a DBGMCU or related setting about if the debug interface is usable and how many pins are involved. Sorry not really used F3 in recent years.

[Oliver Sedlacek]

PB4 is the USART RX and AFR PB3 gets set to 7 no problem, so just PB4 by the look of it. As you summarise, it changes to 0 on the next instruction step.

[Oliver Sedlacek]

I noticed the JTAG option for PB3 and I think there may be something in that. I've got another STM32F373 project that also uses USART2 on PB3-4 and that works fine, so I just ran that 'working' project on this chip. The problem goes with the chip, not the project, but I'm not sure if that makes it more or less perplexing. I suspect the debugger is more or less lying to me and AFR PB3 is never set to 7.

[waclawek.jan · Accepted solution]

You can exclude impact of debugger by not using it. Make the UART transmit continuously, then try to run that program without the debugger.

JW

[Oliver Sedlacek]

Thanks, it was on my list of possible approaches and you've prompted me to try it. Lo and behold, when I'm not debugging I get UART transmissions. I wonder why this is only a problem on one of my ICs?

[waclawek.jan]

I don't know, but I'd try to read the debugger manual or fiddle in it until the problem goes away.

The setting which generates the problem may be then hint to why the problem goes with the chip, e.g. if you'll have a "use SWO on chip with serial number XXXXXXXX" then that's the clue (OK this is unlikely but I wanted to come up with an example).

JW