-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[regression] Unable to flash with latest revision of master - STM32F2/F4/L4 #761
Comments
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 ? |
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.
This is the hash I tested today:
My developement machine is ruinning ubuntu 18.10 |
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 |
I can confirm the same behaviour on STM32F4 Discovery. Edit: Note that my OS was actually Linux Ubuntu 16.04 LTS. But the same behaviour and resolution as noted. |
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 |
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 |
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.
|
Also to clarify, it happens every flash attempt and not intermittently. |
@kmfarley11 same experience, it has 100% failure rate when on the broken revision or later |
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)
There is no problems when using STM32Cube Programmer software for any combination. |
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): Output from working revision: |
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. Git bisect could be used for finding the regression: https://git-scm.com/docs/git-bisect Thanks all for the feedback, and sorry for the inconvenience latest master is broken. Never ever expect latest develop to work. Releases should 😃 |
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: |
@dhylands thank you very much! i don't know what this CS32 thing is but it breaks flashing of STM32F2. |
Sorry about the trouble. What should be done to support both the CS32 and the STM32F2 / F401 if they share the same |
@VictorLamoine i don't have the slightest idea. please revert the change to fix the regression, then figure it out. |
You can revert the commit locally on your machine: I'm not a maintainer so I can't revert on the repository. |
i'd like to suggest that the manufacturer be made available as a command line option if possible. |
@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) |
Hi all, I have reverted the CS32 commit. Could you verify it works again? Kind regards, |
@xor-gate works for me now on the latest master. Thank you everyone for the help! |
@michaelsobczak-qeexo thanks for verify! Sorry for the long delays and inconvenience. |
Thanks! |
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.st-flash
A as-detailed description possible of the problem with debug output when available.
Output:
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: