Hi, I’m not being able to upload binaries to the NUCLEO-L152RE board via the stlink protocol, it fails with the following message:
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Flash page at addr: 0x08009000 erased016-07-06T00:58:07 INFO src/stlink-common.c: Loading device parameters....
2016-07-06T00:58:07 INFO src/stlink-common.c: Device connected is: L152RE, id 0x10006437
2016-07-06T00:58:07 INFO src/stlink-common.c: SRAM size: 0x14000 bytes (80 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 256 bytes
2016-07-06T00:58:07 INFO src/stlink-common.c: Ignoring 4 bytes of 0x00 at end of file
2016-07-06T00:58:07 INFO src/stlink-common.c: Attempting to write 36944 (0x9050) bytes to stm32 address: 134217728 (0x8000000)
2016-07-06T00:58:11 INFO src/stlink-common.c: Finished erasing 145 pages of 256 (0x100) bytes
2016-07-06T00:58:11 INFO src/stlink-common.c: Starting Half page flash write for STM32L core id
Error: Data length doesn't have a 32 bit alignment: +2 byte.
scons: *** [upload] Error 3
I found a closed issue about this bug here so I’m guessing the fixing patches aren’t yet available to PlatformIO, does it make sense?
Hi @BrunoPires!
Thanks for the info. I’ve reproduced the same issue and looks like the latest stable stlink has broken support for L0/L1 targets. As a workaround, you can try to use the previous version from here just replace old one in PlatformIO home directory: /home/user/.platformio/packages/tool-stlink (Unix) C:\Users\user\.platformio\packages\tool-stlink (Windows)
Hi @BrunoPires, i’m co-maintainer of the utility and there are currently no windows binaries for texane/stlink. There is still a pull request pending to remove autotools/automake and only support CMake and build on AppVeyor and produce windows binaries.
@valeros, I have just updated to PlatformIO v3.0, and this problem has reappeared. This is because stlink automatically gets upgraded every time that I perform a build, thus overwriting my manual downgrade as per these instructions.
I see that semantic versioning is one of the cool new features in v3, and the manual mentions it in regards to libraries and platforms. Semantic versioning in the package manager is not explicitly mentioned, but it seems clear that it has some support. When I try to upload my code, it tells me that it is downloading stlink@1.10200.0. It moves the existing version of stlink to .platformio\packages\tool-stlink@1.1.0.
I tried setting upload_protocol=stlink@1.1.0, but it always uses the most recent version, downloading it if I try deleting it. Is this semantic versioning expected to work, or a feature that is eventually planned?
The ugly workaround I have found is to fool PlatformIO, by placing the old files in .platformio\packages\tool-stlink, but keeping the most recent version of package.json.
You use specified version of development platform, for example, platform = ststm32@x.y.z. Platform contains packages and build scripts. If you need to use custom package, you should fork/clone existing platform, modify packages list, rename paltform (ststm32-my) and maintain it.
If you modify original development platform, your packages will be destroyed on next platform update. However, only in that case when we update tool-stlink.
Also, you can manually replace all files from original package but keep package.json without changes. Next time before platform updates, please backup your package and replace again.
You have a few choices here. You should decide which is better for you.
Yes, I’m using windows. I’m slightly confused, if mingw has only just been supported, where did the existing windows version come from? I’m happy to test out the stlink package before you add it to the platform.
@ivankravets, I can confirm that this version works. It seems quite reliable with my nucleo-f401re, and it works most of the time with my nucleo–l053r8 (it was never completely reliable with previous versions of stlink, so this is an unrelated issue).
