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/kLQS9Umw

If 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: dfu

2016-03-04T21:23:46 INFO src/stlink-usb.c: -- exit_dfu_mode

2016-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: mass

2016-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 version

2016-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     = 0x3748

2016-03-04T21:23:46 DEBUG src/stlink-common.c: stlink version = 0x2

2016-03-04T21:23:46 DEBUG src/stlink-common.c: jtag version   = 0x11

2016-03-04T21:23:46 DEBUG src/stlink-common.c: swim version   = 0x4

2016-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 = 0x1ba01477

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 10036414 is 0xe0042000

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 ffff0200 is 0x1ffff7e0

2016-03-04T21:23:46 INFO src/stlink-common.c: Device connected is: F1 High-density device, id 0x10036414

2016-03-04T21:23:46 INFO src/stlink-common.c: SRAM size: 0x10000 bytes (64 KiB), Flash: 0x80000 bytes (512 Ki

B) in pages of 2048 bytes

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 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: 13

4217728 (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 = 0x1ba01477

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 0 is 0x4002200c

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 80 is 0x40022010

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_write_debug32 45670123 to 0x40022004

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_write_debug32 cdef89ab to 0x40022004

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 0 is 0x40022010

2016-03-04T21:23:46 DEBUG src/stlink-common.c: Successfully unlocked flash

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_write_debug32 2 to 0x40022010

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_write_debug32 8000000 to 0x40022014

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 2 is 0x40022010

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_write_debug32 42 to 0x40022010

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 3 is 0x4002200c

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 3 is 0x4002200c

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 3 is 0x4002200c

2016-03-04T21:23:46 DEBUG src/stlink-common.c: *** stlink_read_debug32 3 is 0x4002200c

... many same lines ...