Upload to NUCLEO-L152RE failed (upload_protocol = stlink)

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?

This seems to be released as part of texane stlink 1.2.0 (here https://github.com/texane/stlink/releases/tag/1.2.0) and should be available in PIO (according to st-flash fails on 1st upload (stlink) · Issue #685 · platformio/platformio-core · GitHub). Does manual loading with standalone 1.2.0 fails in the same way?

Hi zgoda, thank you for your time.
I can’t find any prebuilt windows binaries for this release, do you know where I can find it?

Just to be sure i also tested uploading with ST’s STLink utility, which went fine.

09:25:42 : ST-LINK SN : 0672FF534951775087204248
09:25:42 : ST-LINK Firmware version : V2J27M15
09:25:42 : Connected via SWD.
09:25:42 : SWD Frequency = 1,8 MHz.
09:25:42 : Connection mode : Connect Under Reset.
09:25:42 : Debug in Low Power mode enabled.
09:25:42 : Device ID:0x437 
09:25:42 : Device flash Size : 512KBytes
09:25:42 : Device family :STM32L15xxE/L162xE
09:25:49 : [firmware.bin] opened successfully.
09:25:49 : [firmware.bin] checksum : 0xA1F0CC03 
09:26:02 : Memory programmed in 4s and 384ms.

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.

See PR/discussion here: Deprecate autotools and fix versioning, build with MinGW by xor-gate · Pull Request #434 · stlink-org/stlink · GitHub

@xor-gate stlink from the master branch works well on Windows and Linux with my Nucleo boards the problem was with my VM.

@valeros so you couldn’t reproduce the bug after all? The master branch version is the one distributed with PlatformIO?

Just confirming that I saw the same issue on L053R8. Work-around by @valeros was successful.

@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.

Thanks for the info @ivankravets. I may try this approach if the stlink tool is still broken in the next update of the stm32 platform.

@DavidPowell what is your OS? I see that they added support for MinGW

I think that we can update package in our registry.

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.

@DavidPowell I can’t build it with MinGW. See issue

@xor-gate, could you explain how to build it with MinGW64?

@DavidPowell , @BrunoPires, @zgoda,

Could you try new version tool-stlink-windows-1.10200.1.zip?

Need to follow to %USERHOME%/.platformio/packages/tool-stlink, delete all files from this folder and copy new files from archive.

P.S: @xor-gate, thanks a lot for the help with MinGW! :blush:

@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).

Thanks for the report! I’ve just updated package in the Registry.