Some pins not usable when using ST-Link ?

I’m experiencing a strange effect when using ST-LINK as upload tool. Some I/O pins are not usable (PB3, PB4, PA15, PA12, PA11). I test this with a simple blink sketch, using the standard digitalWrite command. All other pins work fine. Same on all my STM boards (2x Maple Mini and 2x Blue Pill).
Using the bootloader as upload tool the missing pins work, except PA12 and PA11, these are now in use for the USB so left alone.
I can’t get my head arround it, why is this ? I was thinking that the same code is flashed in both methods, only using a different transport method.
Are these pins reserved for something else or am I missing something basic info here ?

This is because those pins are JTAG pins.
When using ST-Link, it doesn’t do any call to disable SWD and JTAG.
The relevant code is located in STM32F1/system/libmaple/stm32f1/include/series/gpio.h, triggered by define in board.cpp of the variant.

/**
* @brief Debug port configuration
*
* Used to configure the behavior of JTAG and Serial Wire (SW) debug
* ports and their associated GPIO pins.
*
* @see afio_cfg_debug_ports()
*/
typedef enum afio_debug_cfg {
/** Full Serial Wire and JTAG debug */
AFIO_DEBUG_FULL_SWJ = AFIO_MAPR_SWJ_CFG_FULL_SWJ,
/** Full Serial Wire and JTAG, but no NJTRST. */
AFIO_DEBUG_FULL_SWJ_NO_NJRST = AFIO_MAPR_SWJ_CFG_FULL_SWJ_NO_NJRST,
/** Serial Wire debug only (JTAG-DP disabled, SW-DP enabled) */
AFIO_DEBUG_SW_ONLY = AFIO_MAPR_SWJ_CFG_NO_JTAG_SW,
/** No debug; all JTAG and SW pins are free for use as GPIOs. */
AFIO_DEBUG_NONE = AFIO_MAPR_SWJ_CFG_NO_JTAG_NO_SW,
} afio_debug_cfg;

/**
* @brief Enable or disable the JTAG and SW debug ports.
* @param config Desired debug port configuration
* @see afio_debug_cfg
*/
static inline void afio_cfg_debug_ports(afio_debug_cfg config) {
__io uint32 *mapr = &AFIO_BASE->MAPR;
*mapr = (*mapr & ~AFIO_MAPR_SWJ_CFG) | config;
}


Thanks ! That explains a lot. Now I used this piece of code in the setup section and the led on PA15 blinks

void setup() {
afio_cfg_debug_ports(AFIO_DEBUG_NONE);


Beware that with AFIO_DEBUG_NONE you won’t be able to debug using ST-Link, but with AFIO_DEBUG_SW_ONLY it is allowed.

Yes, thanks, have to dive into this debug functions later, on my “to learn” list !

Well, I also got infected by this “PB4 not toggling” virus…

I cannot find the place in the repo where the afio will configure the ports to debug/non-debug.

I am using the blue pill with “Stm32duino bootloader” upload method, and I cannot toggle PB4 unless I call
afio_cfg_debug_ports(AFIO_DEBUG_NONE);

Hm, strange, I have found in line 48 of board.cpp where the debug port should be disabled, but it will be not disabled, although the compiler will be called with the appropriate directive:
Compiling sketch...
"C:\Users\me\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -DDEBUG_LEVEL=DEBUG_NONE -MMD -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_generic_stm32f103c -DVECT_TAB_ADDR=0x8002000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10612 -DARDUINO_GENERIC_STM32F103C -DARDUINO_ARCH_STM32F1 -DSERIAL_USB -DGENERIC_BOOTLOADER -DCONFIG_MAPLE_MINI_NO_DISABLE_DEBUG=1 -DMCU_STM32F103CB -mthumb -march=armv7-m -D__STM32F1__ -DMCU_STM32F103CB -mthumb -march=armv7-m -D__STM32F1__ "-IC:\Users\me\Documents\Arduino\hardware\Arduino_STM32\STM32F1\system/libmaple" "-IC:\Users\me\Documents\Arduino\hardware\Arduino_STM32\STM32F1\system/libmaple/include" "-IC:\Users\me\Documents\Arduino\hardware\Arduino_STM32\STM32F1\system/libmaple/stm32f1/include" "-IC:\Users\me\Documents\Arduino\hardware\Arduino_STM32\STM32F1\system/libmaple/usb/stm32f1" "-IC:\Users\me\Documents\Arduino\hardware\Arduino_STM32\STM32F1\system/libmaple/usb/usb_lib" "-IC:\Users\me\Documents\Arduino\hardware\Arduino_STM32\STM32F1\cores\maple" "-IC:\Users\me\Documents\Arduino\hardware\Arduino_STM32\STM32F1\variants\generic_stm32f103c" "C:\Users\me\AppData\Local\Temp\arduino_build_226650\sketch\Blink.ino.cpp" -o "C:\Users\me\AppData\Local\Temp\arduino_build_226650\sketch\Blink.ino.cpp.o"


It’s getting weird…

Compiling this code being part of board.cpp:

void boardInit(void) {
#warning "Initializing board..."
#ifndef CONFIG_MAPLE_MINI_NO_DISABLE_DEBUG
#warning "Disabling debug port..."
disableDebugPorts();
#endif
}


It is ” #ifndef “, not ” #ifdef “.

Yepp, that was it.
And also that in boards.txt I should’t have had that define (don’t know where is this coming from).
I removed that define and everything is ok now.

That is pretty normal to have this flag in the stlink upload method, since otherwise, you can only upload one time and then the SWD becomes disabled.

Yes for Stlink, but i had it for stm32duino bootloader upload method, which i think is not wanted.

You’re right ! Roger did that change on December 26th, I don’t know why other than allowing SWD debugging whatever upload method is used.

https://github.com/rogerclarkmelbourne/ … a4b3925ffb

Well, i think we need to find another solution for the original idea to enable debugging, because i lost 2 days to find this issue, and maybe there will be more users who will complain about this.

I’m confused now

People wanted the SWD pins enabled all the time, so I changed it.

Is this not what was wanted by the majority of users?

Idea: enable SWD always, and disable it from pinMode if somebody wants one of its pins.

I’m just wondering how many of us are debugging when uploading with DFU, having no debugger connected.
I admit, this may be not the right place to post my issue, because this happens without using Stlink. And obviously i missed that majority vote.
This issue i see citical since the affected pin cannot be corrected with pinMode alone, one really have to use the afio cfg function, too.
But i don’t want to push my opinion, i obey the majority, i just hope that others will find this post and will know that they should use an Arduino non-compatible function “afio_cfg_debug_ports(AFIO_DEBUG_NONE);” in order to get their pin toggle in any simple sketch.
Me, I will just remove the respective define from “boards.txt” for my local and github version.

I think that daniel’s idea is a good one :
maybe the disableDebug() should within the pinMode when those specific pins are specified.

I don’t know whether my opinion counts, but I would suggest an IDE menu entry, this way is left to the user to enable/disable debugging according to his needs. Yes, you could say that we already have a lot of menu entries. Indeed. But still, this would be essential in my opinion. And this could be done across multiple platforms/boards.
The more because the parallel TFT libraries do set pin modes without calling pinMode() for each pin, but rather use direct register writes for multiple pin mode setting in one shot (btw, this was the way I meet this issue).

This should be linked (but can be done also independently) with information (on wiki?) pointing out the involved GPIO pins.

We anyway need some nice wiki pages regarding debugging.

stevestrong wrote:…But i don’t want to push my opinion, i obey the majority, i just hope that others will find this post and will know that they should use an Arduino non-compatible function “afio_cfg_debug_ports(AFIO_DEBUG_NONE);” in order to get their pin toggle in any simple sketch.

Rick, I did not overlooked that post, I just wanted to repeat the solution for people who browse this thread, looking for the solution.

Rick Kimball wrote:There is no majority way to use these boards. There are many different people using many different boards all in different ways.

Which board are you using?

I really don’t see why the used board would be here relevant.
But anyway, I am using alternatively Maple Mini clone or Blue Pill. I am using the pill alternatively with DFU (if I need 5V and USB serial) or STlink if I want to debug, very rarely.

stevestrong wrote:I don’t see why the used board would be here relevant.
But anyway, I am using alternatively Maple Mini clone or Blue Pill. I am using the pill alternatively with DFU (if I need 5V and USB serial) or STlink if I want to debug, very rarely.

Yes, I am using PB2 (BOOT1) together with PB0..7 as data pins for 8 bit parallel display interface, the problematic case was PB4 which didn’t toggle because of enabled debug interface.
And I wouldn’t wonder if someone would use PA0/PA8..15 as data pins instead. I mean, why not, if it is available on the board? Even if it would cancel the serial 1 and serial USB functionality, on which one could again discuss infinitely…
Sorry, Rick, but I still don’t see what do you want to say, why the used board would be here relevant.

stevestrong wrote:Sorry, Rick, but I still don’t see what do you want to say, why the used board would be here relevant.

OK, so please let know what is the “majority way” to use a board, where is specified.
Especially, where is the user warned that he cannot to use PB4 because of the enabled JTAG (debug) interface, which seems to have priority over DFU/serial USB.
And I wouldn’t mind to (maybe) enable JTAG pins (where PB4 is involved), if the pill would have a JTAG interface connector…
But the pill only has mounted SWD interface connector, which would only involve PA13/14, but not PB3/PB4 at all.

stevestrong wrote:OK, so please let know what is the “majority way”, where is specified.

stevestrong wrote:But the pill only has mounted SWD interface connector, which would only involve PA13/14, but not PB3/PB4 at all.

Yes, I am aware of this.
Still, when using DFU upload method, the full JTAG debug pins are assigned for debugging even if only SWD connector is on board, and I don’t really see why would be this useful for “majority users”, someone can please explain.

stevestrong wrote:Yes, I am aware of this.
Still, when using DFU upload method, the full JTAG debug pins are assigned for debugging even if only SWD connector is on board, and I don’t really see why would be this useful for “majority users”, someone can please explain.

RogerClark wrote:Perhaps I should change this back to the way it was.

stevestrong wrote:RogerClark wrote:Perhaps I should change this back to the way it was.

@stevstrong

Ok. I will take a look at the code.

I have never actually changed the C code that makes the SWD pins available as GPIO. I only changed the Boards.txt settings.

I presume that the C code was either written by Leaflabs when they originally wrote the core.

Roger, just a gently remainder in order to do something in this direction, if you still consider it makes sense:

RogerClark wrote:stevestrong wrote:Yes, I am aware of this.
Still, when using DFU upload method, the full JTAG debug pins are assigned for debugging even if only SWD connector is on board, and I don’t really see why would be this useful for “majority users”, someone can please explain.

Thanks for the reminder. I may be able just to revert the commit which changed this, or just pull the previous commit and copy the boards.txt into the master / head, as I dont think anything else has changed in that file.

stevestrong wrote:Roger, just a gently remainder in order to do something in this direction, if you still consider it makes sense:

RogerClark wrote:stevestrong wrote:Yes, I am aware of this.
Still, when using DFU upload method, the full JTAG debug pins are assigned for debugging even if only SWD connector is on board, and I don’t really see why would be this useful for “majority users”, someone can please explain.

Hi, my reasons for canceled DFU are :
– In windows 8.1 x64 DFU is not work very well, is a pain;
– I want solder the 7 segments LCD directly and ugly to the BluePill pcb, see the nice foto on my desk, ;

russian photo hosting site
– running RTC from board and LCD what a easy platform for many applications!…

So please, please… I need the PA11 and PA12 in GPIO mode in a simple way like JTAG disable…
afio_cfg_debug_ports(AFIO_DEBUG_SW_ONLY);