-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Attempting to flash to STM32L052K8 corrupts flash memory #681
Comments
Thats a weird problem, I could not immediate tell what causes the problem. I think the L1 loader is compatible with the L0 chips as they are almost the same. |
It does seem a little strange - let me know if there are any debug flags or something that I should turn on to provide more information. |
Try flashing a flat binary with st-flash rather than an elf. Try reading back the flash to a file and comparing, or examining it with gdb, or example You should see the start of your vector table... Also given that your address seems to be in RAM, what is the state of your BOOT pin? |
I'll take a look - I've been meaning to learn how to flash .bin files instead of uploading .elf's with a debugger, anyways. The code was one of ST's examples, but I'll take another look at where the vector table is located. The BOOT0 pin is pulled to ground, so I don't think it should be booting into RAM. I'll get back on those questions within a day or two - thank you for the advice! |
Alright, I tried flashing the L0 test program (specifically, ST's LSI initialization example) to an L031K6 Nucleo-32 board, and that works fine. On the L051K8, however, I still observe the issue. The main difference is that I am using a generic USB dongle to program the L051K8 board, and the onboard ST-Link/V2-1 debugger for the L031K6 Nucleo board. I tried updating the firmware on the USB debugger, but that didn't help. I verified that the vector table is correctly placed with Flashing a .bin file to the L051K8 with Here is the output from
But looking at the Flash memory with ST's GUI utility, I do see the .bin file's hex starting at 0x08000000; it looks like the vector table at the start of the program. And the written memory looks like it ends at 0x080047E0, which seems right for the size of the program. I dunno - if this isn't something that anyone else can replicate, I suppose that it could be the chips or boards that I'm using. |
Hi, Same issue with blue-pill board (STM32F103C8X) st-util[abdullatif@Host-001 ~]$ st-util gdb[abdullatif@Host-001 build]$ arm-none-eabi-gdb Stm32blink.elf I have to flash the bootloader with 'st-flash' if I what the board to work again. |
I'm not convinced that that F103 issue is the same as what I've been seeing; it seems fairly well-supported by this tool, and the L0 issue occurs even on a blank chip. The original title of this issue was incorrect, sorry; the behavior occurs on the following two devices:
I looked at |
The following diff appears to completely resolve this issue for me (with an STM32L052K8), but I am guessing that it is not an ideal solution:
That change removes the I don't know why the |
Having Similar issues with an STM32L151CC.
|
@WRansohoff: Please verify if the problem still exists in Release v1.5.1. |
Sure, happy to check whether this still happens with STM32L0 category-2 chips. Most of my boards are in storage atm though, so I probably won't be able to do it until I finish moving in May. Sorry about that. |
@WRansohoff @jakeypoo @Mk-arc @nemtsov @mynameisdaniil |
Hi all. I did some testing. First of all my Setup: CPU: STM32L063R8Tx with following connections: First of all. I double checked that its possible to download my program using a J-Link debugger. Which works fine. Then furthermore, I tested with the ST-Link V2 in the picture above using STM32CubeProgrammer, which also works fine. Thus, I am pretty confident that the Hardware is fine. Now to st-link:
This is interesting now... It seems to not proberly detect the chip when I run the same with st-link installed from the ubuntu package repository I get different results:
Not sure how to continue with the actual flashing test. Since its failing now even earlier? |
@Mk-arc I don't see this on the F1, F4, G4 boards when using the same programmer (ST-Link v2 Clone) I have, so it can not be a general problem. However I noticed that your Programmer-Firmware is quite old. You may want to update it with the official STM32CubeProgrammer... Note also: |
Thanks for the quick response. I updated the FW: Repo-version
Fresh compiled:
There is nothing relating to st-link in /usr/local/share. Also make uninstall does not work:
|
@Mk-arc Something is not correct here. Make sure you don't have repo version and compiled variant installed at the same time - this may likely not work. I'd recommend to uninstall the package version, then delete the |
I uninstalled the package version and did what you recommend. Now its different but still not okay: First of all. for some reason I can now not access the device without root.
And its still not properly detecting the probe.
|
Packages |
Yes. I will try tomorrow late evening on another computer. Maybe something is skewed in my system. |
Check /doc/compiling.md also --> Section: "Set device access permissions and the role of udev" |
@Nightwalker-87 thanks for all the help. I now retried at another computer and there the probe gets detected properly and I can now reproduce the actual problem we are discussing in this issue:
After the last entry the program freezes and has to be terminated. Interestingly after this the ST-Link V2 clone probe was somehow in a broken state. Even after power cycle it was not being detected properly. Just after reuploading new FW with STM32CubeProgrammer it started working again.
|
--> You have checked out the |
tested with develop branch. WITHOUT applying the patch.
|
@Mk-arc Thanks, we are making progress. 👌 Could you re-run the above with the |
We're looking at
...asking ourselves under which circumstances this function would return an error: ... which is the case for (
@Ant-ON is this really a bug? What's your say on this implementation/handling? |
@Nightwalker-87 just tested current testing branch (8fad9be) and develop (d4b53b0). Release bulds on linux@amd64, libusb 1.0.23. STM32L152CCT (detected as STM32L0xxx_Cat_3) onboard stlink V2J21S5 (stm32l0538-disco board). I was unable to successfully flash this chip.
And here's full debug output: https://pastebin.com/5NP1Q6Te BTW I've noticed that you've dropped support for Mac OS, is there an objective reason? Would you mind a pull request that brings it back? Mac is my main machine for the time being and it would be nice if I can use stlink without VM. UPD:
(https://pastebin.com/suG0ybvc) UPD2: |
@mynameisdaniil same issue here. I was running into another one all day. After cleaning everyone and re cloning the current main repo I run to
I have tested on only one board so far the Nucleo-L031K6. Below is the full output
|
On my Nucleo-L031K6 I have similar problems from the latest testing commit:
This file is flashed successfully on the same hardware with st-flash 1.6.0 |
@chrisgjohnson The codebase has undergone major and very useful refactoring work with lots of improvements and fixes since then. Thus there can be no easy rollback to the previous state. Also by then there were some obscure implementations without any (proper) documentation on their functionality. This is why some users have taken action and have rewritten some parts of the code for flashing. Thus one would need to debug the latest code likely without any comparison to the previous state. |
Attempting to flash a .elf to the chip results in a series of errors indicating an STM32L1 loader is being used (quoted further down), and subsequent connections fail with the following strange error message:
That state persists until the chip is 'fixed' by connecting to it during a hardware reset via ST's ST-Link Utility on a Windows machine. Here is the output that st-util gives during the problematic flashing operation:
Expected/description:
The program should flash susccessfully. But despite reporting success, when I try to step through it in GDB, the chip jumps directly from the reset location to 0x20000010. So I gotta figure that something went wrong somewhere.
The text was updated successfully, but these errors were encountered: