[regression] Unable to flash with latest revision of master - STM32F2/F4/L4 #761

michaelsobczak-qeexo · 2019-01-14T21:49:42Z

NOTICE: The issue may be closed without notice when not enough information is provided!

Thank you for giving feedback to the stlink project. Take some time to fill out
check boxes with a X in the following items so developers and other people can try to
to find out what is going on. And add/remove what is appropriate to your problem.

When submitting a feature request, try to reuse the list and add/remove what is appropriate.
Place a X between the brackets [X] to mark the list item.

Programmer/board type: stlink/v2
Programmer firmware version: Not sure
Operating system: Mac OS X
Stlink tools version and/or git commit hash: 6a9d390
Stlink commandline tool name: st-flash
Target chip (and optional board): STM32L476JG (STSW-STLKT01V1)

A as-detailed description possible of the problem with debug output when available.

Output:

Release$ st-flash write ~/data/input/st-ces/lib/qxostlib-datalog-20190104112820-ed73f5.bin 0x8000000 st-flash 1.4.0-58-g6a9d390
2019-01-14T16:35:23 INFO common.c: Loading device parameters.... 
2019-01-14T16:35:23 INFO common.c: Device connected is: L4 device, id 0x10076415
2019-01-14T16:35:23 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-01-14T16:35:23 INFO common.c: Attempting to write 109160 (0x1aa68) bytes to stm32 address: 134217728 (0x8000000) Flash page at addr: 0x0801a800 erasedEraseFlash - Page:0x35 Size:0x800
2019-01-14T16:35:24 INFO common.c: Finished erasing 54 pages of 2048 (0x800) bytes 
2019-01-14T16:35:24 INFO common.c: Starting Flash write for F2/F4/L4
2019-01-14T16:35:24 INFO flash_loader.c: Successfully loaded flash loader in sram size: 32768 2019-01-14T16:35:27 ERROR flash_loader.c: flash loader run error
2019-01-14T16:35:27 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1 stlink_fwrite_flash() == -1

Expected/description:
When we revert to ae717b945de revision the command goes back to working, for some reason it doesn't work on master

Thank you,
The stlink project maintainers

The text was updated successfully, but these errors were encountered:

xor-gate · 2019-01-17T09:11:57Z

This is the diff between those two versions: ae717b9...master. I think ae717b9...master#diff-df7217cd8a3907646570c002cf509f32R1439 this broke the flash loader which was introduced in PR #751. Ping @dhylands ?

dhylands · 2019-01-17T18:55:16Z

The latest master seems to be working for me. This is on an NUCLEO-L476RG. I was flashing Micropython which is split into 2 files due to the way the filesystem works.

715 >./st-flash write firmware0.bin 0x08000000
2019-01-17T10:46:23 INFO src/stlink-common.c: Loading device parameters....
2019-01-17T10:46:23 INFO src/stlink-common.c: Device connected is: L4 device, id 0x10076415
2019-01-17T10:46:23 INFO src/stlink-common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-01-17T10:46:23 INFO src/stlink-common.c: Attempting to write 14752 (0x39a0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003800 erased
2019-01-17T10:46:23 INFO src/stlink-common.c: Finished erasing 8 pages of 2048 (0x800) bytes
2019-01-17T10:46:23 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2019-01-17T10:46:23 INFO src/stlink-common.c: Successfully loaded flash loader in sram
size: 14752
2019-01-17T10:46:24 INFO src/stlink-common.c: Starting verification of write complete
2019-01-17T10:46:24 INFO src/stlink-common.c: Flash written and verified! jolly good!

716 >./st-flash --reset write firmware1.bin 0x08004000
2019-01-17T10:46:53 INFO src/stlink-common.c: Loading device parameters....
2019-01-17T10:46:53 INFO src/stlink-common.c: Device connected is: L4 device, id 0x10076415
2019-01-17T10:46:53 INFO src/stlink-common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-01-17T10:46:53 INFO src/stlink-common.c: Attempting to write 302908 (0x49f3c) bytes to stm32 address: 134234112 (0x8004000)
Flash page at addr: 0x0804d800 erased
2019-01-17T10:47:00 INFO src/stlink-common.c: Finished erasing 148 pages of 2048 (0x800) bytes
2019-01-17T10:47:00 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2019-01-17T10:47:00 INFO src/stlink-common.c: Successfully loaded flash loader in sram
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 7996
2019-01-17T10:47:06 INFO src/stlink-common.c: Starting verification of write complete
2019-01-17T10:47:09 INFO src/stlink-common.c: Flash written and verified! jolly good!

This is the hash I tested today:

commit 6a9d390a729f381ecec45f212354bfe98e27790f (HEAD -> master, origin/master, origin/HEAD)
Author: WRansohoff <WRansohoff@users.noreply.github.com>
Date:   Sun Jan 13 00:04:21 2019 -0800

    Update STM32F3xx chip ID that covers a few different devices. (#758)

My developement machine is ruinning ubuntu 18.10

michaelsobczak-qeexo · 2019-01-17T19:00:48Z

Thanks for looking into this. I'm also using L476RG to flash, i can try with latest changes and make sure I can reproduce. Mac OS X Mojave is our development environment

kmfarley11 · 2019-01-17T20:11:17Z

I can confirm the same behaviour on STM32F4 Discovery.
A flash attempt from master resulted in the same "flash loader run error", but reverting to ae717b9 worked for me.

Edit: Note that my OS was actually Linux Ubuntu 16.04 LTS. But the same behaviour and resolution as noted.

dhylands · 2019-01-17T20:54:55Z

I tried my F4 Discovery board and I was getting intermittent failures. For my first test I was using a201d3e which happens to be the system installed version of stlink (on my machine). Once I got the error mentioned above, mostly I got an unrecognized chip id unless I used --reset on the command line to st-flash.

When it failed, I had to power cycle the board to get it to work again.

My F4 had the V2J14S0 version of stlink. I updated it to V2J28S0 and I didn't get any further failures with the latest master or with version a201d3e

dhylands · 2019-01-17T21:02:02Z

For completeness, my NUCLEO-L476RG had stlink firmware V2J27M15. Since I had the stlink updater tool running I upgraded to the latest (V2J28M16) and the L476 continued to work with master and a201d3e

kmfarley11 · 2019-01-17T21:51:38Z

Interesting. My F4 discovery was at V2J25M14. So i got the latest (V2J32M22) from ST's website.

Even after updating my board with that, I still get the flash error when on master.
I did pinpoint that 7651d21 seems to be the first commit where I get the error though. All prior work fine (i.e. 358a913 worked).
for reference, my exact error from master:

$ st-flash --format ihex write ch.hex
st-flash 1.4.0-58-g6a9d390
2019-01-17T13:45:33 INFO common.c: Loading device parameters....
2019-01-17T13:45:33 INFO common.c: Device connected is: F4 device, id 0x10076413
2019-01-17T13:45:33 INFO common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2019-01-17T13:45:33 INFO common.c: Attempting to write 40532 (0x9e54) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08008000 erasedEraseFlash - Sector:0x2 Size:0x4000 
2019-01-17T13:45:34 INFO common.c: Finished erasing 3 pages of 16384 (0x4000) bytes
2019-01-17T13:45:34 INFO common.c: Starting Flash write for F2/F4/L4
2019-01-17T13:45:34 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
2019-01-17T13:45:42 ERROR flash_loader.c: flash loader run error
2019-01-17T13:45:42 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

kmfarley11 · 2019-01-17T21:54:40Z

Also to clarify, it happens every flash attempt and not intermittently.
It either works (pre 7651d21), or doesn't.
Looking at the code for that commit, not sure why it would be causing any issues. Just reporting observations.
¯\(ツ)/¯

michaelsobczak-qeexo · 2019-01-22T15:34:57Z

@kmfarley11 same experience, it has 100% failure rate when on the broken revision or later

dmitrystu · 2019-02-01T16:00:48Z

I have made some compatibility test for the st-flash 1.5.1-12-g30de1b3 (Linux) and some STM boars. Here is a result (32F103 and 32L433 is a bluepill-based boards)

Board	ST-LINK FW-VERION	SELF	STM32F103C8	STM32L433CC
NUCLEO-F303RE	V2J28M17	OK	OK	unknown chip id! 0x5fa0004
NUCLEO-L476RG	V2J32M22	flash loader run error	OK	Invalid flash type
STM32L100C-DISCO	V2J32S0	OK	OK	Invalid flash type

There is no problems when using STM32Cube Programmer software for any combination.

ashesman · 2019-02-06T21:33:51Z

I have the same issue. Upgraded to latest revision and can no longer flash. It seems to freeze at flashing the first block. It is OK on revision 3eab7b9 (1.4.0-49-g3eab7b9). Using custom hardware on ST-Link V2. Sorry I cannot provide any more useful debug information.

Output from latest revision (note, uses a script to erase then flash several binaries):
st-flash erase
st-flash 1.5.1-12-g30de1b3
2019-02-07T10:24:51 INFO common.c: Loading device parameters....
2019-02-07T10:24:51 INFO common.c: Device connected is: L4 device, id 0x10076415
2019-02-07T10:24:51 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
Mass erasing
st-flash write build/target/bootloader/platform-12/bootloader.bin 0x08000000
st-flash 1.5.1-12-g30de1b3
2019-02-07T10:24:51 INFO common.c: Loading device parameters....
2019-02-07T10:24:51 INFO common.c: Device connected is: L4 device, id 0x10076415
2019-02-07T10:24:51 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-02-07T10:24:51 INFO common.c: Attempting to write 58348 (0xe3ec) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x0800e000 erasedEraseFlash - Page:0x1c Size:0x800
2019-02-07T10:24:51 INFO common.c: Finished erasing 29 pages of 2048 (0x800) bytes
2019-02-07T10:24:51 INFO common.c: Starting Flash write for F2/F4/L4
2019-02-07T10:24:51 INFO flash_loader.c: Successfully loaded flash loader in sram
size: 32768
2019-02-07T10:24:55 ERROR flash_loader.c: flash loader run error
2019-02-07T10:24:55 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1
Makefile:23: recipe for target 'install' failed
make: *** [install] Error 255

Output from working revision:
st-flash erase
st-flash 1.4.0-49-g3eab7b9
2019-02-07T10:25:47 INFO common.c: Loading device parameters....
2019-02-07T10:25:47 INFO common.c: Device connected is: L4 device, id 0x10076415
2019-02-07T10:25:47 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
Mass erasing
st-flash write build/target/bootloader/platform-12/bootloader.bin 0x08000000
st-flash 1.4.0-49-g3eab7b9
2019-02-07T10:25:47 INFO common.c: Loading device parameters....
2019-02-07T10:25:47 INFO common.c: Device connected is: L4 device, id 0x10076415
2019-02-07T10:25:47 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-02-07T10:25:47 INFO common.c: Attempting to write 58348 (0xe3ec) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x0800e000 erasedEraseFlash - Page:0x1c Size:0x800
2019-02-07T10:25:47 INFO common.c: Finished erasing 29 pages of 2048 (0x800) bytes
2019-02-07T10:25:47 INFO common.c: Starting Flash write for F2/F4/L4
2019-02-07T10:25:47 INFO flash_loader.c: Successfully loaded flash loader in sram
size: 32768
size: 25580
2019-02-07T10:25:49 INFO common.c: Starting verification of write complete
2019-02-07T10:25:49 INFO common.c: Flash written and verified! jolly good!
st-flash write build/target/hardwaretest/platform-12/hardwaretest.bin 0x08020000
st-flash 1.4.0-49-g3eab7b9
2019-02-07T10:25:49 INFO common.c: Loading device parameters....
2019-02-07T10:25:49 INFO common.c: Device connected is: L4 device, id 0x10076415
2019-02-07T10:25:49 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-02-07T10:25:49 INFO common.c: Attempting to write 97564 (0x17d1c) bytes to stm32 address: 134348800 (0x8020000)
Flash page at addr: 0x08037800 erasedEraseFlash - Page:0x6f Size:0x800
2019-02-07T10:25:50 INFO common.c: Finished erasing 48 pages of 2048 (0x800) bytes
2019-02-07T10:25:50 INFO common.c: Starting Flash write for F2/F4/L4
2019-02-07T10:25:50 INFO flash_loader.c: Successfully loaded flash loader in sram
size: 32768
size: 32768
size: 32028
2019-02-07T10:25:53 INFO common.c: Starting verification of write complete
2019-02-07T10:25:53 INFO common.c: Flash written and verified! jolly good!
st-flash write build/target/application/default/platform-12/application_default.bin 0x08040000
st-flash 1.4.0-49-g3eab7b9
2019-02-07T10:25:54 INFO common.c: Loading device parameters....
2019-02-07T10:25:54 INFO common.c: Device connected is: L4 device, id 0x10076415
2019-02-07T10:25:54 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-02-07T10:25:54 INFO common.c: Attempting to write 201636 (0x313a4) bytes to stm32 address: 134479872 (0x8040000)
Flash page at addr: 0x08071000 erasedEraseFlash - Page:0xe2 Size:0x800
2019-02-07T10:25:56 INFO common.c: Finished erasing 99 pages of 2048 (0x800) bytes
2019-02-07T10:25:56 INFO common.c: Starting Flash write for F2/F4/L4
2019-02-07T10:25:56 INFO flash_loader.c: Successfully loaded flash loader in sram
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 5028
2019-02-07T10:26:00 INFO common.c: Starting verification of write complete
2019-02-07T10:26:02 INFO common.c: Flash written and verified! jolly good!
#st-flash write build/target/data/device_data/platform-12/data_device_data.bin 0x080?????
st-flash write build/target/data/pan1740_firmware/platform-12/bluetooth_firmware_midb.bin 0x08018000
st-flash 1.4.0-49-g3eab7b9
2019-02-07T10:26:02 INFO common.c: Loading device parameters....
2019-02-07T10:26:02 INFO common.c: Device connected is: L4 device, id 0x10076415
2019-02-07T10:26:02 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-02-07T10:26:02 INFO common.c: Attempting to write 18144 (0x46e0) bytes to stm32 address: 134316032 (0x8018000)
Flash page at addr: 0x0801c000 erasedEraseFlash - Page:0x38 Size:0x800
2019-02-07T10:26:02 INFO common.c: Finished erasing 9 pages of 2048 (0x800) bytes
2019-02-07T10:26:02 INFO common.c: Starting Flash write for F2/F4/L4
2019-02-07T10:26:02 INFO flash_loader.c: Successfully loaded flash loader in sram
size: 18144
2019-02-07T10:26:03 INFO common.c: Starting verification of write complete
2019-02-07T10:26:03 INFO common.c: Flash written and verified! jolly good!
st-flash reset
st-flash 1.4.0-49-g3eab7b9
2019-02-07T10:26:03 INFO common.c: Loading device parameters....
2019-02-07T10:26:03 INFO common.c: Device connected is: L4 device, id 0x10076415
2019-02-07T10:26:03 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes

xor-gate · 2019-02-09T10:21:25Z

Dear all, I would like you to help out and skim through multiple revisions since latest release so we can pinpoint the exact PR which causes the problem.

v1.5.1...master

Git bisect could be used for finding the regression:

https://git-scm.com/docs/git-bisect
https://git-scm.com/docs/git-bisect-lk2009.html

Thanks all for the feedback, and sorry for the inconvenience latest master is broken. Never ever expect latest develop to work. Releases should 😃

dhylands · 2019-02-09T18:41:28Z

It was commit 7651d21 which caused the problem. The issue is that the chip ID for the F401 is 0x2ba01477 which appears to be the same as the CS32_CORE_ID and this causes the incorrect flash loader to be loaded onto the F4.

While looking into this I noticed that the code which prints which flash type was detected:
https://github.com/texane/stlink/blob/b9c315d990abfde3008a917e767c63d2c1c1ddf2/src/common.c#L1944
uses different logic from the code which actually does the flashing:
https://github.com/texane/stlink/blob/b9c315d990abfde3008a917e767c63d2c1c1ddf2/src/flash_loader.c#L253
so it says it's flashing an F4 but it loads the flash loader for the VL

rojer · 2019-02-11T14:35:33Z

@dhylands thank you very much! i don't know what this CS32 thing is but it breaks flashing of STM32F2.

VictorLamoine · 2019-02-11T16:18:14Z

Sorry about the trouble. What should be done to support both the CS32 and the STM32F2 / F401 if they share the same chip id but don't require the same flashing method?

rojer · 2019-02-11T21:31:06Z

@VictorLamoine i don't have the slightest idea. please revert the change to fix the regression, then figure it out.

VictorLamoine · 2019-02-12T07:40:37Z

You can revert the commit locally on your machine: git revert 7651d2116fd74c7803ea00ab1da7cf3d00faf44c.

I'm not a maintainer so I can't revert on the repository.

ag88 · 2019-02-12T18:04:50Z

i'd like to suggest that the manufacturer be made available as a command line option if possible.
i.e. the default would be stm32 and that to flash cs32 a manufacturer option would be necessary
the reasoning is that stm32 'clones' may detour from being 'fully compatible' with stm32 as things evolves

xor-gate · 2019-02-12T20:11:24Z

@ag88 totaly agree, the texane/stlink project aims to support ST Microelectronics products and to be compatible with clones without breaking existing things. The problem with clones on the same IDs with different flash handling etcetera involves a lot of hacking. Also the current implementation is also not very clean (compared to flexible OpenOCD tcl scripts). There are a lot of conditional checks all around the flash loader code for different scenarios which could be simplified (eg look at pystlink)

xor-gate · 2019-02-12T20:12:58Z

Hi all,

I have reverted the CS32 commit. Could you verify it works again?

Kind regards,
Jerry

michaelsobczak-qeexo · 2019-02-12T20:33:54Z

@xor-gate works for me now on the latest master. Thank you everyone for the help!

xor-gate · 2019-02-12T20:41:42Z

@michaelsobczak-qeexo thanks for verify! Sorry for the long delays and inconvenience.

Nightwalker-87 · 2020-03-29T18:11:55Z

Fixed in the following commits:
1st fix: 3295ab4, 2nd fix: f5d0454 (master-branch) and b40c243 (develop-branch) .

michaelsobczak-qeexo · 2020-03-30T16:29:31Z

Thanks!

xor-gate added target/stm32l4 component/st-flash error/flash-loader labels Jan 17, 2019

This was referenced Feb 9, 2019

STM32F1/F4/L0/L4: flash loader run error #607

Closed

STM32F401 Nucleo-64 no longer programmable (Regression) #766

Closed

rojer mentioned this issue Feb 11, 2019

CKS32: Add support for CKS32 micro-controller #757

Merged

xor-gate closed this as completed in 3295ab4 Feb 12, 2019

xor-gate reopened this Feb 12, 2019

This was linked to pull requests Mar 20, 2020

CKS32: Add support for CKS32F103C8T6 #805

Merged

CKS32: Add support for CKS32 micro-controller #757

Merged

Nightwalker-87 added status/duplicate code/feature-request error/flash-loader bug/fixed bug/regression status/resolved status/resolved-verified and removed needs/investigation bug/regression priority/high labels Mar 23, 2020

Nightwalker-87 removed this from To do in Release v1.6.1 Mar 29, 2020

Nightwalker-87 modified the milestones: v1.6.1, v1.6.0 Mar 29, 2020

Nightwalker-87 changed the title ~~CKS32 / flashing: Unable to flash with latest revision of master~~ Unable to flash with latest revision of master - STM32F2/F4/L4 (Regression) Mar 29, 2020

Nightwalker-87 removed the status/duplicate label Mar 29, 2020

Nightwalker-87 closed this as completed Mar 29, 2020

This was unlinked from pull requests Mar 29, 2020

CKS32: added CKS32F103C8T6 a stm32f103c8t6 clone with coreid 0x2ba01477 #834

Closed

CKS32: Add support for CKS32F103C8T6 #805

Merged

CKS32: Add support for CKS32 micro-controller #757

Merged

Nightwalker-87 linked a pull request Mar 29, 2020 that will close this issue

CKS32: Add support for CKS32 micro-controller #757

Merged

Nightwalker-87 assigned xor-gate Mar 29, 2020

Nightwalker-87 mentioned this issue Apr 1, 2020

[code-structure] Add all STM32 Core-IDs to the codebase for MCU identification #903

Closed

stlink-org locked as resolved and limited conversation to collaborators Apr 23, 2020

Nightwalker-87 added status/duplicate and removed code/feature-request labels Jun 17, 2020

Nightwalker-87 changed the title ~~Unable to flash with latest revision of master - STM32F2/F4/L4 (Regression)~~ [regression] Unable to flash with latest revision of master - STM32F2/F4/L4 Jun 17, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[regression] Unable to flash with latest revision of master - STM32F2/F4/L4 #761

[regression] Unable to flash with latest revision of master - STM32F2/F4/L4 #761

michaelsobczak-qeexo commented Jan 14, 2019 •

edited by Nightwalker-87

xor-gate commented Jan 17, 2019

dhylands commented Jan 17, 2019

michaelsobczak-qeexo commented Jan 17, 2019

kmfarley11 commented Jan 17, 2019 •

edited

dhylands commented Jan 17, 2019 •

edited

dhylands commented Jan 17, 2019

kmfarley11 commented Jan 17, 2019

kmfarley11 commented Jan 17, 2019 •

edited

michaelsobczak-qeexo commented Jan 22, 2019

dmitrystu commented Feb 1, 2019

ashesman commented Feb 6, 2019 •

edited

xor-gate commented Feb 9, 2019

dhylands commented Feb 9, 2019

rojer commented Feb 11, 2019

VictorLamoine commented Feb 11, 2019 •

edited

rojer commented Feb 11, 2019

VictorLamoine commented Feb 12, 2019

ag88 commented Feb 12, 2019

xor-gate commented Feb 12, 2019

xor-gate commented Feb 12, 2019

michaelsobczak-qeexo commented Feb 12, 2019

xor-gate commented Feb 12, 2019

Nightwalker-87 commented Mar 29, 2020 •

edited

michaelsobczak-qeexo commented Mar 30, 2020

[regression] Unable to flash with latest revision of master - STM32F2/F4/L4 #761

[regression] Unable to flash with latest revision of master - STM32F2/F4/L4 #761

Comments

michaelsobczak-qeexo commented Jan 14, 2019 • edited by Nightwalker-87

xor-gate commented Jan 17, 2019

dhylands commented Jan 17, 2019

michaelsobczak-qeexo commented Jan 17, 2019

kmfarley11 commented Jan 17, 2019 • edited

dhylands commented Jan 17, 2019 • edited

dhylands commented Jan 17, 2019

kmfarley11 commented Jan 17, 2019

kmfarley11 commented Jan 17, 2019 • edited

michaelsobczak-qeexo commented Jan 22, 2019

dmitrystu commented Feb 1, 2019

ashesman commented Feb 6, 2019 • edited

xor-gate commented Feb 9, 2019

dhylands commented Feb 9, 2019

rojer commented Feb 11, 2019

VictorLamoine commented Feb 11, 2019 • edited

rojer commented Feb 11, 2019

VictorLamoine commented Feb 12, 2019

ag88 commented Feb 12, 2019

xor-gate commented Feb 12, 2019

xor-gate commented Feb 12, 2019

michaelsobczak-qeexo commented Feb 12, 2019

xor-gate commented Feb 12, 2019

Nightwalker-87 commented Mar 29, 2020 • edited

michaelsobczak-qeexo commented Mar 30, 2020

michaelsobczak-qeexo commented Jan 14, 2019 •

edited by Nightwalker-87

kmfarley11 commented Jan 17, 2019 •

edited

dhylands commented Jan 17, 2019 •

edited

kmfarley11 commented Jan 17, 2019 •

edited

ashesman commented Feb 6, 2019 •

edited

VictorLamoine commented Feb 11, 2019 •

edited

Nightwalker-87 commented Mar 29, 2020 •

edited