Cannot flash STM32F103 if PLL enabled

[kiv]

Posted on February 26, 2016 at 02:55

I'm trying to deal with the setting clocking of STM32F103 MCU without the use of third-party libraries.

I wrote several functions for this: http://pastebin.com/kLQS9UmwIf I setup clocking by stm32_rccUseHSE, then everything works fine.However, if I setup PLL using stm32_rccUsePLLFromHSE function, then there are problems.The program is fully working correctly, the frequency changes to right, nothing is buggy and firmware does not hang. I can connect via SWD debugger and debug the program.However, if I try to flash a microcontroller, the flashing utility hangs.If I hold the reset button, then start the firmware flashing, and then quickly release the button, the flashing succeed. If I reboot into bootloader (BOOT0 = HIGH), then I can also fine to flash the controller (via UART or SWD).This problem does not occur if I use libraries such as ChibiOS or libopencm3. I tried to find differences between them clocking setup code and my, but could not.What could be the problem?

[Tesla DeLorean]

Posted on February 26, 2016 at 04:13

However, if I try to flash a microcontroller, the flashing utility hangs. If I hold the reset button, then start the firmware flashing, and then quickly release the button, the flashing succeed.

What flashing utility? Are you talking about something running in the STM32 or externally? Internally you'd want to ensure the error/status bits are cleared. I would perhaps look at the settings and status of the Flash Controller.

[kiv]

Posted on March 04, 2016 at 18:18

I use Linux. I use the tool from here https://github.com/texane/stlink.

Of course, this may be an issue of this utility, but another PLL setup code works (from libopencm3 and ChibiOS), and my no.

[Tesla DeLorean]

Posted on March 04, 2016 at 18:52

Perhaps your code executes more efficiently, the JTAG/SWD method has to stop your code running to take control of the processor, and the deeper that gets the more issues there can be.

[kiv]

Posted on March 04, 2016 at 19:42

I do not quite understand you, but tried to add a 1 second delay before initializing the PLL. If I started flashing before the delay is over, that all is well, but if the PLL has been initialized, then utility will hang. The problem appears even if the PLL has been initialized for a long time and the process of initializing didn't was interruped by flashing.

I try to launch st-flash with more verbose logging (--debug command line option) and I got:

$ st-flash --debug --reset write build/stm32test.elf 08000000  

2016-03-04T21:23:46 DEBUG src/stlink-common.c: stlink current mode: dfu2016-03-04T21:23:46 INFO src/stlink-usb.c: -- exit_dfu_mode2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_exit_dfu_mode ***2016-03-04T21:23:46 DEBUG src/stlink-common.c: stlink current mode: mass2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_enter_swd_mode ***2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_reset ***2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** looking up stlink version2016-03-04T21:23:46 DEBUG src/stlink-common.c: st vid         = 0x0483 (expect 0x0483)2016-03-04T21:23:46 DEBUG src/stlink-common.c: stlink pid     = 0x37482016-03-04T21:23:46 DEBUG src/stlink-common.c: stlink version = 0x22016-03-04T21:23:46 DEBUG src/stlink-common.c: jtag version   = 0x112016-03-04T21:23:46 DEBUG src/stlink-common.c: swim version   = 0x42016-03-04T21:23:46 INFO src/stlink-common.c: Loading device parameters....2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_core_id ***2016-03-04T21:23:46 DEBUG src/stlink-common.c: core_id = 0x1ba014772016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 10036414 is 0xe00420002016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 ffff0200 is 0x1ffff7e02016-03-04T21:23:46 INFO src/stlink-common.c: Device connected is: F1 High-density device, id 0x100364142016-03-04T21:23:46 INFO src/stlink-common.c: SRAM size: 0x10000 bytes (64 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 2048 bytes2016-03-04T21:23:46 DEBUG src/stlink-common.c: stlink current mode: debug (jtag or swd)2016-03-04T21:23:46 DEBUG src/stlink-common.c: stlink current mode: debug (jtag or swd)2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_jtag_reset ***2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_reset ***2016-03-04T21:23:46 INFO src/stlink-common.c: Attempting to write 368784 (0x5a090) bytes to stm32 address: 134217728 (0x8000000)2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_core_id ***2016-03-04T21:23:46 DEBUG src/stlink-common.c: core_id = 0x1ba014772016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 0 is 0x4002200c2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 80 is 0x400220102016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_write_debug32 45670123 to 0x400220042016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_write_debug32 cdef89ab to 0x400220042016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 0 is 0x400220102016-03-04T21:23:46 DEBUG src/stlink-common.c: Successfully unlocked flash2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_write_debug32 2 to 0x400220102016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_write_debug32 8000000 to 0x400220142016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 2 is 0x400220102016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_write_debug32 42 to 0x400220102016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 3 is 0x4002200c2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 3 is 0x4002200c2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 3 is 0x4002200c2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 3 is 0x4002200c... many same lines ...