2024-01-06 04:11 PM - edited 2024-01-06 04:15 PM
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.
Solved! Go to Solution.
2024-01-09 06:49 AM
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.
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-01-06 04:31 PM - edited 2024-01-06 04:32 PM
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.
2024-01-06 05:01 PM
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.
2024-01-06 05:17 PM
Certainly, you can diff the code and see what is changed.
2024-01-06 05:27 PM
>>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.
2024-01-06 10:54 PM - edited 2024-01-06 10:56 PM
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 ;)
2024-01-07 06:53 AM
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.
2024-01-07 07:02 AM
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
2024-01-07 07:28 AM
I can spend a day comparing the code of working and not working. The point is that latest CubeMX (6.10.0) is generating the not working code and ST has to fix it.
I do not know if it is only STM32F103CBT6 or whole STM32F1 family or more.
2024-01-07 09:20 AM
>>ST has to fix it
Sure, and I've flagged the post for review, but if you identify the code that's compiled and running that's disabling the pin function, or the settings within the tools that's causing them to build this way it will get fixed quicker. But it's unlikely to done in a few days, and definitely not at the weekend.
A Find-in-File should take less than a minute. "_SWJ_"
The code flow from Reset_Handler(), SystemInit(), HAL_Init() shouldn't be that difficult to pin down.