STM32C011J6M6 (SO8 package) - trying reconfigure Pin 8 from STLINK (SWCLK) to GPIO on-the-fly (after boot)

[wb0gaz]

I am attempting to reconfigure Pin 8 (datasheet default assignments are PB6/PA14-BOOT0/PC15-OSCX_OUT) from PA14-BOOT0 to PB6 GPIO Output Open Drain (GPIO_MODE_OUTPUT_OD) a short time after start-up.

My current attempt (code below) does not accomplish this (instead, once the port pin reconfiguration code below has run, an attached STLINK device can still connect to the MCU, or if already connected to MCU, continues to function.)

IMPORTANT: I have not yet and do not plan to change MCU option bytes (using STM32Programmer).

Intention: In the application (under development, written in C using STM32CubeIDE, using HAL), at power-up, a connected STLINK device should function normally. A short time later (under condition set in firmware), the application firmware is expected to reconfigure Pin 8 from power-on default (as Port A, GPIO bit 14, Alternate Function 0, which is STLINK SWCLK) to a different configuration (as Port B, GPIO bit 6, Open Drain output).

This change should (ideally) be able to occur in three external configurations:

(1) STLINK device is not present) on Pins 7 and 8.

(2) STLINK device is present on pins 7 and 8 but has not yet gone into connected state via STM32CubeProgrammer (in this configuration attempting STM32CubeProgrammer Connect is expected to fail.)

(3) STLINK device is present on pins 7 and 8 and has gone into connected state via STM32CubeProgrammer (in this configuration, the existing connection between MCU and STLINK is expected to fail.)

Here is the function I am using to attempt reconfiguration (this is based on the code STM32CubeMX generated to configure Port B bit 6 as GPIO Output Open Drain, but modified to reflect my current attempt to disconnected Pin 8 from Port A GPIO bit 14 and then connect in 8 to Port B GPIO bit 6.)

Current function is reflected in code below:

// Initialization of Port B bit 6 as generated by STM32CubeMX then modified in attempt
// to switch on-the-fly from STLINK (power-up) to GPIO configuration.

static void MX_GPIO_Init_B6(void)
{
  GPIO_InitTypeDef GPIO_InitStruct = {0};
  /* USER CODE BEGIN MX_GPIO_Init_1 */

  /* USER CODE END MX_GPIO_Init_1 */

  /* GPIO Ports Clock Enable */
  __HAL_RCC_GPIOB_CLK_ENABLE();

  // STM32C11J6M6
  // Pin 8 is PB6/PA14-BOOT0/PC15-OSCX_OUT
  // At power-up (no option bytes changed PA14 is AF0 (SWCLK)
  // On subsequent condition which will call MX_GPIO_Init_B6(), 
  // programmatically switch from PA14/ALTERNATE/AF0 to PB6/GPIO_OUTPUT_OD

  // Configure PA14 to ANALOG - intent here is to disconnect STLINK (attached
  // and idle or attached and connected).
  GPIO_InitStruct.Pin = GPIO_PIN_14;
  GPIO_InitStruct.Mode = GPIO_MODE_ANALOG; // MODE_INPUT should switch away from _ALTERATE
  HAL_GPIO_Init(GPIOA, &GPIO_InitStruct); // Write structure to PORT A pin 14

  // Configure PB6 to output open drain - intent here is to connect Pin 8 to GPIO B
  // bit 6 "PB6" so that it is used as GPIO and would no longer serve as SWCLK.
  HAL_GPIO_WritePin(GPIOB, GPIO_PIN_6, GPIO_PIN_RESET); // Should float high once STLINK removed
  GPIO_InitStruct.Pin = GPIO_PIN_6;
  GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
  HAL_GPIO_Init(GPIOB, &GPIO_InitStruct); // Write structure to PORT B Pin 6

  // BELOW DOES NOT APPEAR TO HAVE INTENDED RESULT (STLINK STILL RUNNING) 12/13/2025

//  HAL_SYSCFG_SetPinBinding(HAL_BIND_SO8_PIN8_PB6); // This should switch PIN8 to PB6
//  LL_SYSCFG_ConfigPinMux(pin_binding);
  /* USER CODE BEGIN MX_GPIO_Init_2 */

  /* USER CODE END MX_GPIO_Init_2 */
}

Thank you for any comments, advice, requests for further/new/clarifying information, or any other interaction

Dave

[AScha.3]

So you just want to use a "debug pin" for any i/o pin function ?

As long as you have reset (nrst) , you can start the cpu and it starts with SWD on its pins;

so you always can download a program and start it...then debug is gone, if you use the debug pins for other function.

So just set the pins you want in Cube , without debug pins as debug, just as you want.

You need genuine st-link (not a clone) , to have hardware reset , to flash the cpu. Set it to "hardware reset" , CubeProgrammer or IDE .

After new program starts - debug connection gone. As you set it.

[wb0gaz]

Hello AScha.3, thank you for quick reply - I am responding (inline) to each question/comment:

So you just want to use a "debug pin" for any i/o pin function ? (YES)

As long as you have reset (nrst) , you can start the cpu and it starts with SWD on its pins;

(I believe normal default behavior, at power-on and unless changed, only pins 7 and 8 are ready for STLINK signals SWDIO and SWCLK, and nrst pin is not necessary.)

so you can download a program and start it...then debug is gone, if you use the debug pins for other function.

So just set the pins you want in Cube , without debug pins as debug, just as you want.

(I will conduct an experiment - thank you for suggestion - if I just configure pin 8 as GPIO, then I expect that pin will change from SWCLK to GPIO, and no longer work as SWCLK until next power cycle - in particular, STLINK device should no more be able connect and go active.)

Maybe need genuine st-link (not a clone) , to have hardware reset , to flash the cpu.

I am using only power-on reset, not exposing/using NRST pin, because pin count in SO8 is small - 6 pins only - and every pin has application requirement (except temporarily pins 7 and 8 after power-on until application changes to GPIO. Requirement is that STLINK is still useful at power-on, but not all the time.)

After new program starts - debug connection gone. As you set it.

Thank you again AScha.3, I will try experiment to simply re-configure pin 8 into GPIO after power-on, and see if it is no more STLINK capable until next power cycle.

Dave

[AScha.3]

Hmmm...   so if you dont have nrst /reset available, because used for other function, you should set some time window for flash or update after power up.

So most simple way: set in Cube all pins as you want in your program, generate code and copy/save it.

Then generate code for debug pins used for swd, to flash.

Then write in this program some delay after init/startup , maybe 5 secs , then copy in the init for the swd pins as in first code and execute. 

So you get a cpu that has swd /debug access about 5 secs after power up, then it goes to using all pins and no more debug access until next power down and up.

Some doing it this way, like Arduino or STC ...

Ok, you have a narrow time window then: power up and flash...after 5 secs its over and your program running.

[wb0gaz]

Hello again Ascha.3,

I believe you correctly describe my intention. 5 seconds is nominal, other hardware and software considerations will set actual "switch over" time, but 5 seconds fixed delay would be excellent first demonstration.

The two examples (with and without HAL routine configuring of Pin 8 for GPIO use) would provide the isolated initialization required for Pin 8 as GPIO in the MX_INIT code routine.

I believe this experiment (using MX-generated code to initialize Pin 8 for GPIO use on PB6, running 5 seconds after power-up) you suggest would allow me to verify behavior within the first 5 seconds (STLINK should be able to connect and control the CPU so that the application code is stopped by STLINK within the first 5 seconds), and after the first 5 seconds (STM32CubeProgrammer should not be able to connect, because at that point SWCLK pin 8 cannot be asserted by STLINK device into the factory-supplied BOOT0 code. The programmed configuration of Pin 8 (GPIO B Pin 6) would at that point be output open drain but RESET (so, floating) at that point (there is a hardware pull-up resistor on Pin 8). I believe SWCLK is held low by the STLINK device until it begins a transaction, so there should be no hardware risk of rail-to-rail output from STLINK device conflicting with floating (open drain but in "GPIO RESET" state) pin.

Thank you for your advice, understanding and recommendations - they form the basis for my next experiment.

I will update this discussion once I have result to share.

Dave