STM32 F103xx using PB3

[gino]

Posted on September 20, 2012 at 11:44

Hello,

We want to use PB3 of the microC. As found in some forums we have to disable JTAG. We do this using following line of code:

GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE);

Then we want to use PB3 as output. But the signal is low. So far this helped us a lot:

/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32F107VG PB3 - PB4 - PA15 Alternate Function Usage&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=228

Only if we switch of the power of the microC and switch it on again, the pin will output the signal. It seems that the debugger (jLink using SWD) isnt able to reset the microC completely. We tried different options of resetting in the IAR Workbench for ARM Debugger Options Menu. In this pdf (

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/CD00171190.pdf

) it is described in chapter 9.3.5 (JTAG/SWD alternate function remapping) that PB3 is only free if no asynchronous trace. We aren't able, or do not know how to setup asynchronus trace. We don't use it with our SWD debugger. PB3 is also not connected to the debugger. We also tried to make the full remap

GPIO_PinRemapConfig(GPIO_Remap_SWJ_Disable),

because there it isn't the footnote on PB3, but also there, it is not working after flashing, But it is working after reconnect the power. By the way, we are able to work with PA15 and PB4 after calling

GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE).

Do anyone of you have any experience with that and can you give us an advice? null

[Tesla DeLorean]

Posted on September 21, 2012 at 01:52

Without seeing all the code being executed it's hard to surmise what might be going on.

You say PB3 isn't physically attached to the debug connector? SWD/JTAG pods have a very hard time resetting processors cleanly without access to a NRESET or NPOR type pin, they are also a tad more invasive into the processors ''reset'' state than might be appreciated. It takes a while to wrestle the processor to a stop, code is uploaded and run in SRAM to do flashing of the internal memory, and to configure the hardware into a state that makes the debugger comfortable. They may also defeat things like watchdogs. So what I'd probably do would be to look at the peripheral registers and confirm everything matched what I'd expect against the manual. If I had two conditions, where things worked vs didn't I would compare and contrast the core/peripheral states between to two conditions, digging as deep as necessary. I'd check that clocks are ticking for GPIOB and AFIO, I'd check the GPIO pin configurations/modes.

[gino]

Posted on September 25, 2012 at 12:11

Thanks Clive.

I've looked into the registers and they contain valid data. RCC_APB2ENR->IOPBEN = 1 RCC_APB2ENR->AFIOEN = 1 AFIO-MAPR->SWJ_CFG = 0x4 We tried it with iJet, jLink, jTrace it wasn't working (just after reapply power). Now I tried with a ST-Link debug interface and it was working immediately and we are able to debug our code! All the  debuggers should have the latest firmware. We tried different reset options. ST-Link is using the option ''normal'' but jTrace/jLink as well. iJet has different options, but none of them are working. As well I found out that with the iJet the registers contain the old values after a software-reset. With the ST-Link and as well with the jTrace, jLink the registers where set to 0 after a software reset. I have no idea why we can't use our other debuggers. If someone has one, I would like to hear it. By the way: all debuggers are just connected to the board with VCC, GND, SWD_DATA and SWD_CLK

[John F.]

Posted on September 25, 2012 at 12:24

''

By the way: all debuggers are just connected to the board with VCC, GND, SWD_DATA and SWD_CLK

'' Presumably the other debuggers want connections to other signals or require some of their inputs to be tied high or low. Check the manuals for your particular devices.

[ozgurderin]

Posted on October 17, 2012 at 23:27

 Hi,

I'm working/experimenting on the same controller too, and I have exactly the same problem. I don't find any solution yet, but according to reference manual, as long as the

TRACE_IOEN

bit is set on the

DBGMCU_CR register, the controller activates the Trace pins depending on the TRACE_MODE bits. As default, TRACE_MODE bits are cleared and it means PB3 is assigned to TraceOutput, as a result GPIO has no control over PB3 during debugging. I think that the Signum based debuggers activating  TRACE_IOEN bit by default. ( I'm using I-Jet) If I can find something about that, than I will post it here. But may be some one else already know a work around...     

[Gerardo GALLUCCI]

Posted on December 14, 2012 at 16:25

Hi all,

is there any update on this issue? current situazion: - ST-link: it work on the fly! - J-link: GPIO PB3 doesn't works after download, and it doesn't works after manual reset (NRST pin), it works only after power off/on. thanks Gerardo

[Tesla DeLorean]

Posted on December 14, 2012 at 17:07

- J-link: GPIO PB3 doesn't works after download, and it doesn't works after manual reset (NRST pin), it works only after power off/on.

May be this would be something to discuss with Segger, either directly or via their Support Forum. Generally it's pretty inadvisable to use JTAG pins as GPIOs, and can complicate boundary scan efforts.

[devilar]

Posted on January 03, 2013 at 03:43

Guy's try this magic sequence. And remember that JTAG pins should be the last in remap sequence, because it's not able to read them.

GPIO_PinRemapConfig(GPIO_Remap_SWJ_NoJTRST, ENABLE);     GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE);