HAL_AFIO does not handle changes to JTAG/SWD properly

[dean2399]

Posted on November 22, 2017 at 20:27

At least on the SMT32F103x parts, the SWJ_CFG bits in the AFIO_MAPR register are write only.  Reading these bits is undefined.  All of the __HAL_AFIO_REMAP macros in stm32f1xx_hal_GPIO_ex.h do read/modify/write operations to this register.  This can cause wild behavior.

For example, on the STM32F103VET6:

__HAL_AFIO_REMAP_SWJ_NOJTAG();

__HAL_AFIO_REMAP_TIM4_ENABLE();

This first sets AFIO_MAPR to 0x02000000 to disable the JTAG pins.  Then, while remapping TIM4 it sets AFIO_MAPR to 0x04001000 which both remaps TIM4 and completely disables JTAG and SWD.  This happens because the undefined read of the SWJ_CFG bits gets written back to the AFIO_MAPR.

Workaround are to cache the state AFIO_MAPR locally and write that, or use the Bit-Band memory to operate on individual bits.

#cube-hal #afio #debug

[dean2399]

Posted on November 22, 2017 at 22:27

Scratch that bit-band option.  Forgot that it still equates to a word Read-Modify-Write.

[Richard Jones]

Posted on January 24, 2018 at 19:02

I also just hit the ST library problems with re-mapped peripherals (via STM32cubeMX) , basically they contain read-modify-writes to AFIO_MAPR, a register that contains SWJ_CFG[2:0] bits that can't be read as you know.

I've re-mapped peripherals on many boards over the years, how many work by luckily reading  valid or correct  SWJ_CFG bits, I feel a little uneasy now, might they get it wrong on a power-up some day?

I though it worth a look to see when this was first raised,

95617 titled 'Issues when setting SWJ_CFG in AFIO->MAPR to SWJ_NOJTAG' in Oct-2016

84493 titled 'Lost SWD debugging Connection at __HAL_AFIO_REMAP_CAN1_2();' back in Nov-2015

I stopped looking at this point,  The issue has been known for quite a while.

Any easy solutions?

At the moment I've hacked the cubeMX init into my own file and added __HAL_AFIO_REMAP_SWJ_NOJTAG(); after each remap as I'm using 2-wire SW-CLK and SWDIO. 

[Richard Jones]

Posted on January 25, 2018 at 12:26

... when I say '

might they get it wrong on a power-up some day?',

 it had occurred to me I could end up with illegal values in the SWJ_CFG[2:0] bits, Reference RM0008 table-18 regarding Debug config states 'Other : Forbidden', that;s 50% of combinations, however 7.4.2 says 'Other combinations: no effect' so perhaps they're safe, it's not clear.

[Der Max]

Posted on January 25, 2018 at 21:03

I ran into the same type of issue: 

https://community.st.com/0D50X00009XkWmqSAF

 

My workaround is to 'manually' call the remap function again in the user-section after all Inits have completed.

Please fix this ST, this is really hard to catch since the behavior is chock-full of red-herrings (I spent ~1h searching the hardware defines for changes after being able to 'fix' it by completely disabling SWD in the configurator).

[Imen.D]

Posted on March 22, 2018 at 14:53

Hello,

We would inform you that a new patch for STM32CubeF1 Firmware Package v1.6.1 is published to fix this issue.

Kind Regards,

Imen