-
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
STM32F101VG: st-flash reports " ERROR common.c: unsupported flash method, abort" #1117
Comments
@nbkolchin I fixed typo in code. Can you try https://github.com/Ant-ON/stlink/tree/f1_xl_fix_typo ? The exact size of SRAM is difficult to obtain. 96 KiB is maximum size for the F1 XL serices. |
It fails with another error after flash erase.
ST Link original utilities report :
Maybe this will help somehow. |
@nbkolchin 154 pages were written without errors ... Then, based on the contents of the registers, something damages the flash loader code in SRAM. PC register points to an address outside the flash loader (0x21000000). The fault registers are empty. Does the firmware use the DMA to write any values to the SRAM? Also you can run the commands to check this: ./st-flash --reset erase
./st-flash --reset --format ihex write nuttx.hex |
Yes. I've tried suggested commands:
|
@nbkolchin And everything goes fail again. Hmm... I have merged F1 XL fixes with minor bug fixes in the flash loader. Can you check erase - write again? |
We have progress:
I've tried running st-flash several times and always got this result. Addon: data wasn't actually written to flash. |
@nbkolchin I'm glad the problem has been resolved. Thanks for your quick testing! |
The problem wasn't resolved. Verify failed and data wasn't written to flash (board doesn't boot). Or I should open separate ticket for this issue? |
No, it's fine. You can continue here. - As you can see I noticed that there still was this missing bit, just before you replied. |
@nbkolchin Oh, I'm already inattentive by the evening. No need. Can you read data from MCU by run something
|
@Ant-ON Don't tell that we are spending too much time on this project. 🤣 |
|
@nbkolchin I'm interested in: What is written instead of the firmware? |
I've tried to run
I've double checked that source code is from |
You obviously locked your MCU and need to unlock it first before continuing with any attempts to flash it. |
No.
|
@nbkolchin I have added more fixes and improvements to the https://github.com/Ant-ON/stlink/commits/flash_loader_fix . I think it should work now. Can you check again? |
P.S. There was an error in current sources:
I've commented variable out for correct compilation. |
@nbkolchin Thank you! I fixed GUI compilation. Can you try I still can't understand why the PC goes beyond the flash loader... |
Yes, I have IWDG configured. |
@nbkolchin Can you disable IWDG and test without it? |
Yes, but this will require some time. |
@nbkolchin I hope we understood each other correctly. I meant IWDG configured by option bytes ("hardware watchdog"). |
@nbkolchin I checked the behavior of the application with the IWDG enabled by hardware. It is very similar to the observed situation (interrupting the flashing in random places and the contents of the registers). I added IWDG reset during flashing. Everything should work correctly now. |
Commandline:
Commandline-Output:
Expected/description: Correct operation.
Also, I've noticed that st-util reports incorrect RAM size:
STM32F101VG has only 80Kib.
P.S. OpenOCD also fails with "error waiting for target flash write algorithm". Original ST Windows utilities work without problems.
The text was updated successfully, but these errors were encountered: