0
\$\begingroup\$

I'm having some trouble getting my STM32F103 to work as I intend. On my working board (previously flashed with Espruino firmware) I have LEDs attached to TMS TCK and TDI lines.

After flashing it with .bin generated by System Workbench STM32 I get a dim light off of these LEDs.

Here is the code I used (my actual code is much longer but suffers from the same symptom):

#include "stm32f1xx.h"

void delay(void);

void main(void)
{
  // I/O port C clock enable
  RCC->APB2ENR = RCC_APB2ENR_IOPCEN;
  // Set PC_12 to output
  GPIOC->CRH &= ~(GPIO_CRH_MODE12 | GPIO_CRH_CNF12);
  GPIOC->CRH |= GPIO_CRH_MODE12;

  while(1)
  {
    GPIOC->BSRR = (1<<12);
    delay();
    GPIOC->BRR = (1<<12);
    delay();
  }
}

void delay(void)
{
  volatile unsigned int i;
  for (i = 0; i < 20000; i++);
}

Pin C12 does what I intend for this simple test. What must I do to have it stop the TMS/TDI activity?

Side question; the .bin generated by System Workbench STM32, does it include everything that is needed? Aka the HAL?

\$\endgroup\$
7
  • \$\begingroup\$ Dim light does not necessarily mean activity, more likely pullups or outputs too weak to fully drive the LEDs. It is not clear what you are hoping for here. \$\endgroup\$ Aug 24, 2016 at 17:07
  • \$\begingroup\$ What STM32F103 board are you using? Does it have an on-board JTAG or SWD debugger? \$\endgroup\$
    – gbulmer
    Aug 24, 2016 at 17:24
  • \$\begingroup\$ Just checked with my DSO and indeed. It's stable voltage not activity. The weird thing is that it stays like it even if I configure the pins as GPIO_MODE_ANALOG. Really anything I do makes them dim (even setting them as PP and LOW). I hoped this might be a common artifact of some boot mode or something. BOOT0 and BOOT1/PB2 are both grounded. \$\endgroup\$ Aug 24, 2016 at 17:29
  • \$\begingroup\$ I am using my own board, I use JTAG and ST-LINK/V2. @gbulmer \$\endgroup\$ Aug 24, 2016 at 17:29
  • \$\begingroup\$ I avoid using the JTAG and SWD pins as I/O pins because they need to actively programmed to be I/O pins. Also, I am concerned that any load on those signals might upset an external programmer. So I would recommend you don't use TMS/SWDIO or TCK/SWCLK for GPIO. IIRC it is a faff to support both SWD and GPIO on those pins (but I'd need to find some old notes to remember why) I can't see the code programming SWD pins as GPIO, so unless the Espruino code does, I don't understand how those pins are operating as I/O. Are you saying that the code does blink those LEDs correctly in other examples? \$\endgroup\$
    – gbulmer
    Aug 24, 2016 at 17:36

1 Answer 1

0
\$\begingroup\$

I avoid using the JTAG and SWD pins as I/O pins because they need to actively programmed to be I/O pins.

I can't see the code doing that so it is likely that those pins are not operating as GPIO.

Get a copy of 'RM0008 Reference manual' manual from ST.

In section '9.3.5 JTAG/SWD alternate function remapping' it explains how to map the SWD and JTAG pins to become ordinary GPIO pins. Table '37. Debug port mapping' explains which values to set in SWJ _CFG bits in the AFIO+MAPR register to map those JTAG/SWD pins to GPIO.

For example if the SWJ_CFG bits are set to 100, all of the JTAG and SWD pins are available for GPIO.

I would encourage you to avoid this. At least don't map the SWD pins, so that it is easier to debug your board.

Also some of the SWD pins might be accessed from an external debugger (depending on the software driving it) while it is connected, and this might also be a cause of enough activity to light LEDs dimly.

\$\endgroup\$
1
  • \$\begingroup\$ I did use the CubeMX for setup on my 'real' project, but it seems I was unlucky. After I added the __HAL_AFIO_REMAP_SWJ_DISABLE(); macro it started working. (I only do that for RELEASE of course :) ) Thank you so much! \$\endgroup\$ Aug 30, 2016 at 2:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.