Cannot access STM32F103CBT6 again after downloading program created by latest CubeMX 6.10.0.

[MNapi]

I created new program using latest CubeMX 6.10.0, I use Keil. I upload without any problems.

I use ST Link v3 connected to PA13 (SWDIO) , PA14 (SWCLK)

The program is running but when I try to connect again it says STM32 not found.

I cannot debug, I cannot download again.

There is no extra code, only plain code created by CubeMX, all pins are not enabled, nothing.

Still the same problem.

 

I connect pin BOOT0 to 3.3V and suddenly I can access the chip again and upload program.

 

When I use program created by older CubeMX, I do not have this problem.

Has anybody seen something like this ? There must be something with the code generated by latest CubeMX

I haven't check other chips I have noticed this only with STM32F103CBT6. Other might be affected too.

 

 

 

[TDK]

Probably the SWDIO/SWCLK pins are being re-assigned. Attach the IOC or code. Do you have "set unused pins as analog" or similar setting enabled?

> all pins are not enabled, nothing.

Set SWD pins to SWD functions to avoid them getting messed with.

[MNapi]

Nothing is messed up. Read carefully my original post.

I can set pins to anything I want or not set to anything and the problem stays on.

setting pins to analog or not setting to anything else does not have influance/change on the problem.

See original post I do not have the problem with older version of CubeMX

SWD pins are set to SWD and nothing is messed up.

[TDK]

Certainly, you can diff the code and see what is changed.

[Tesla DeLorean]

>>I haven't check other chips I have noticed this only with STM32F103CBT6. Other might be affected too.

The F1 does have it's own relatively unique method for disabling the JTAG-DP pins in several stages.

Likely a change in a default setting deep in the project meta data.

[oeliks]

Noticed this also. On clone/fake that I dont use - I though it was cheap genuine chip (when I bought it several years back) but starting wondering when it behavined funny in some situations.

 

I tried to upload some old code that certainly was working (on genuine mcu's and this clone also).

 

Is it genuine part from official reseller?

From the first look it really seems to be bricked ;)

[MNapi]

It is genuine from Mouser. But I got also a whole bunch from Aliexpress they are less than $1 compared to $10 on mouser. No difference. The problem is always there when I use latest CubeMX

We need ST tech support to look at this.

But I have just tried different chip (STM32H7A3ZIT6) on latest CubeMX (6.10.0) and I did not have this problem.

 

 

[Tesla DeLorean]

Diff the code between working and non-working forks.

Grep/Search for code streams like these

 /* Remap SPI1 pins and disable JTAG */
 LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_AFIO);
 LL_GPIO_AF_Remap_SWJ_NOJTAG();
 while((AFIO->MAPR & AFIO_MAPR_SWJ_CFG_JTAGDISABLE) != AFIO_MAPR_SWJ_CFG_JTAGDISABLE);

Basically the AFIO unit and the SWJ settings

[Semer CHERNI]

Hello

After analyzing the generated code, I found that the void HAL_MspInit(void) contains a call for a macro which set the GPIO debug pins according to the setting done in the CubeMX :

The screenshot shows the default stat which will make the CubeMX insert the following code in HAL_MspInit(void) which disable the SW debug

 /** DISABLE: JTAG-DP Disabled and SW-DP Disabled
 */
 __HAL_AFIO_REMAP_SWJ_DISABLE();

 To be able to make it debug correctly, you need to explicitly set the Debug settings in CubeMX (Case of SW with ST-Link)

 /** NOJTAG: JTAG-DP Disabled and SW-DP Enabled
 */
 __HAL_AFIO_REMAP_SWJ_NOJTAG();

 

KR,
Semer.

[MNapi]

thanks it was indeed the problem, I checked, tested and all is working now.

previous CubeMX wasn't doing it.

 

some change and it makes you to scratch head and you do not know what is happening.