Comments (19)
I'm planning to work on this issue but won't have time until the end of the upcoming week. I believe this is the same problem as Issue #88.
from stlink.
The F0 has a reduces instruvction set. OpenOCD has a seperate loader for the F0. Maybe we need a seperate F0 loader too?
from stlink.
It looks like all of the flash unlocking/erasing/writing functions already use if/else tests to adjust for the two different methods used by earlier boards. We can probably just use the Programming Manual to roll in the commands needed for this board..... but it'll take a while.
Eventually all of this should be abstracted out into a different file so that we don't need to do this each time someone wants to add support for new hardware.
from stlink.
I had a go at implementing this myself and got as far as the flash loader. Where is the OpenOCD flash loader for F0? I couldn't see it in http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=tree;f=contrib/loaders/flash;h=88b7884ee9c3608eb167b7f9006fa28020322ab9;hb=HEAD
from stlink.
There is a aptch for openocd to review at http://openocd.zylin.com/604
from stlink.
I just finished digging into the STM32F05x reference manual (RM0091) to compare register and bit addresses for the flash control module. This may end up being easier than I thought. It looks like all the registers, offsets, and bits are the same. The two differences are the size of the register (this may not matter?) and it seems this chip doesn't use the RDPTR_KEY.
Here is my diff file FYI- https://gist.github.com/2907339
from stlink.
It looks to me like OpenOCD uses loader code for Cortex-M0 chips through the stm32f1x.S file ( view it here ). Can anyone tell me if this is already implemented in stlink and if not, is there anyone who can translate it for use with the write_loader_to_sram() function?
from stlink.
I didn't notice that anybody implemented it. You write the code into the loader_code_stm32[xx] array and perhaps adapt for different parameters in th usersof that code.
from stlink.
I've figured that much out. But I don't know what I'm doing when it comes to the loader code. So far I can get it to unlock and erase the flash, but it bombs out in that 1000 cycle loop when trying to launch the loader code (I was trying to use the STM32VL values there).
Not sure where to go from here.
from stlink.
I'm at a dead end on this one. I can't get the flash loader from OpenOCD to work. If someone would like to lend a hand I've committed a VERY messy branch here:
https://github.com/szczys/stlink/tree/f0-flash-loader-testing
from stlink.
Go away for some time. Come back to the code later. I then normally clap at my head, fix an obvious error and things start to work. I am away for the next week, and F0 is not high on my agenda, so no help from my side that soon.
from stlink.
Maybe I'm missing something altogether, but to me it looks like that the assembly code does not read the buffer in SRAM and store it to the flash, but it assumes that someone else is writing to an FIFO-area pointed by r2.
Hence, to me it looks like that the assembly code in the patch simply cannot work, as it doesn't assume the flashed binary to be in the SRAM as the calling code assumes.
But I'm quite new to this, so I need to have a much better look to understand what's going on.
from stlink.
"Pekka" == Pekka Nikander [email protected] writes:
Pekka> Maybe I'm missing something altogether, but to me it looks like
Pekka> that the assembly code does not read the buffer in SRAM and store
Pekka> it to the flash, but it assumes that someone else is writing to
Pekka> an FIFO-area pointed by r2. Hence, to me it looks like that the
Pekka> assembly code in the patch simply cannot work, as it doesn't
Pekka> assume the flashed binary to be in the SRAM as the calling code
Pekka> assumes.
Pekka> But I'm quite new to this, so I need to have a much better look
Pekka> to understand what's going on.
I think nobody looked at the F0 so long. It probaly needs some work. The F0
is not high on mu agenda, so don't expect any contribution from me.
Bye
Uwe Bonnes [email protected]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
from stlink.
I have made now some progress with STM32F05x. Firstly, it looks like the flash controller in the STM32F05x is similar to the flash controller in STM32VL, which has the STM32F100RB MCU, a Cortex-M3 based MCU. From the outset, the registers etc look similar. So, I have basically enabled STM32VL functionality also for the STM32F05x. At the moment, the code seems to recognise the ship and correctly erase the flash.
However, I enter problems with the SRAM-based flash routine. The one for STM32VL will not work, as it uses instructions that are not available in Cortex-M0, e.g. the post-increment stores and loads. Hence, I wrote a replacement, using the STM32VL routine and the ST AN4065 code as the bases. No problem with that.
However, I have serious problems when I try to actually execute the loader code in the SRAM. Initially the code went into a loop and the MCU never halted. After that, I made a very simple loader that has just a single bkpt instruction. That also never halted. Then I made a program that had two bkpt instructions; it worked. The processor did halt, but non-surprisingly the later code in stlink_common.c:run_flash_loader
fails, as the r2
value has not been changed.
As a third attempt, I wrote a very simple "pseudo"-loader, as below:
0x00, 0x30, // nop /* add r0,#0 */ 0x00, 0x22, // mov r2, #0 0x00, 0xBE, // bkpt #0x00
This does halt, but the register r2
still does not change.
So, I'm starting to wonder if the stlink-usb.c:_stlink_usb_read_reg
would need to be modified somehow?
I also don't understand why the single-breakpoint program doesn't halt, but the two breakpoint one does? Could there be endianness problems, as I'm using a Mac?
Any ideas how to continue?
from stlink.
For some reason the STM32F0 Thumb1 SRAM-flasher code needed two NOPs in the beginning. With them it works, or at least seems to work. And apparently also sometimes without them, sometimes. I don't understand what's going, though, so I'll leave the NOPs there into the code, with a proper comment.
Anyway, I seem to have the STM32F05x support, for STM32F0-discovery, now working. I have now committed it to our fork. However, I won't make pull request just quite not yet, as I want to test this first a little so that there aren't any remaining bugs.
If you want to have a look before that, here it is: https://github.com/Senseg/stlink/commits/master
from stlink.
Pekka: I got your branch working, but it needs lots of reset button presses. I'm only testing with a single page blinky right now anyway, but it is at least working somewhat! Just needs tidying up!
from stlink.
Thanks, Karl. I have been busy with other stuff this week, but should have time to continue with the stlink from Monday or Tuesday. If you have any suggestions what to do, please let me know. Or feel free to tidy up yourself and make the pull request from your fork.
from stlink.
I have now tested our code quite a lot. It has two deficiencies. Firstly, I have to first "st-link erase" before doing "st-link flash", otherwise the discovery boards goes to some weird state. Secondly, it doesn't boot the newly flashed image, but the reset button has to be pressed for that. But if I first erase the flash, then flash, and then reset manually, it works well enough.
As I'm not inclined to work more on this at the moment, I'll create a pull request.
from stlink.
Should be fixed by now.
from stlink.
Related Issues (20)
- stm32f411re: Flash programming error 0x40 HOT 3
- STM32H755ZI-Q: Flash write fails on second page (0x08100000) HOT 2
- New release
- [question]: external driver requirements for stlink-1.7.0-x86_64-w64-mingw32? HOT 1
- stlink V3 mini not "usable" [Win7 64bit] HOT 1
- [feature] OTP Read/Write
- stlink-gui: failed to allocate 139988352155568 bytes HOT 1
- ST-LINK-V3MINIE: LIBUSB_ERROR_TIMEOUT only when debugger is powered without connection to target board HOT 2
- STLinkv3: UDEV rules in Debian not matching STLINK-V3MINIE HOT 1
- [STM32G0B1RE / Nucleo G0B1RE]: False chip id reading HOT 2
- [STM32F103] stlink programmers are disappearing after running probing twice. HOT 2
- [STM32U575RGT6]: Verification failed at offset 43008 HOT 9
- [feature] Show all info during full erase HOT 13
- Latest release stlink-1.8.0-win32 doesn't run HOT 8
- Can't build stlink 1.8.0 for Fedora HOT 8
- [feature] Caching and diffing bin/hex HOT 1
- Update on #1357 HOT 1
- [feature] Read/write operations on external SPI Serial Flash Memory HOT 1
- STM32H7A: Flash write fails on second page HOT 2
- Compiling stlink with Raspberry Pi fails for v1.8.0 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from stlink.