2020-04-03 05:28 PM
Given that Oracle has changed their Java license to a commercial license that many developers and companies will be reluctant to accept, the dependency of STM32CubeProgrammer on it is problematic. Although the documentation suggests that it will work with OpenJDK if you install OpenJFX, I have not been able to get that combination to work, and judging from the commentary on the internet, a lot of developers are having the same issue.
Since STM32CubeProgrammer is now the only STM tool that supports newer STM32 uControllers for UART flashing, please consider releasing detailed instructions on how to make it work with OpenJDK.
Solved! Go to Solution.
2020-04-05 02:05 AM
Just to give a couterweight: It's not that long ago that chip manufactures did publish documentation rather reluctantly (sometimes only with NDA) for programming PALs, GALs, CPLDs, uCs, ..., so you were forced to buy rather expensive equipment from specialised companies. If you weren't a big company, even getting simple datasheets was difficult.
Now, ST (like most other manufacturers) publish (most) documents free of charge, without an NDA. And they even offer basic programming "equipment" free of charge. I do agree that STM32CubeProgrammer is far from being perfect (and I can't understand why it could be that difficult to deal with the openJFX problem) but on the other hand, I'm quite happy that it's not perfect. If all these manufacturer supplied tools would be perfect, there would be very little interest in alternatives, i.e. development of alternative, (open source in particular) tools would almost cease. That's not what we want, do we?
That open source tools lag behind regarding supported chips is clear, as the developers get the documents (and the hardware for testing :( ) only with some delay. But in many cases, preliminary support for new families turns out to be rather simple and can be accomplished in a few hours. That it takes
sometimes quite a long time to get this into mainline is a different topic.
So, looking back into the past, I'd say the present situation isn't exactly paradise, but quite close to.
2020-04-05 10:13 AM
OK folks, I meant the only *STM* tool that supports newer STM32 uControllers, particularly via the UART interface; I will try to use more precise wording next time; I've updated the O.P. to make the question clearer, thanks for pointing out the need for clarification. My particular need (for a host of reasons) is for a stand-alone tool for UART flashing, preferably without the entanglement with commercial Java licensing.
So my question remains: how can STM32CubeProgrammer be used with OpenJDK. The release indicates that it does work with OpenJDK but requires OpenJFX. I've spent quite a bit of time trying to get that combination to work without success; the large number of folks asking the same question in this and other forums suggests I'm not the only one. If it works, I'm asking the tool team if they would please provide more detailed setup instructions; if it doesn't work, then perhaps they can make that explicit (requires Oracle Java - commercial version, OpenJDK does not support) or modify the code to support OpenJDK. This does not seem like an unreasonable request.
I appreciate the suggestion that I could use other tools such as OpenOCD; I am aware of Open OCD and have used it on and off for many years. I've never used it for flashing a target via UART (only via SWD or JTAG) and I'm not sure whether it supports UART flashing; for those suggesting it as an alternative, do you know if it does?
@berendi mentioned that OpenOCD development has continued past 2017, just not on their old website; (@berendi, is there a new website? If so, can you provide a link?); For those looking, I found pre-compiled current windows binaries here: https://gnutoolchains.com/arm-eabi/openocd/.
STM generally does a fantastic job both with their rich range of uControllers and their tools. This particular area is becoming a problem because many of us are not fond of Eclipse, don't want our code deeply entangled with other libraries, don't want to use wizards such as Cube; we just want to be able to easily flash the target via the serial i/f. This used to be easily done via the flash loader demonstrator and then with STM32CubeProgrammer. The change to Oracle's licensing isn't STM's fault, but it sure would be nice if they would help resolve it so that there remains a good STM tool available for UART flashing of recent-ish microcontrollers.
2020-04-06 01:10 AM
hi @berendi
The main reason why STM32CubeProgrammer is not working with OpenJDK build you tried is the lack of OpenJFX library which is the Graphical Framework which STM32CubeProgrammer is based on.
Some OpenJDK builds contain JavaFX such as Zulu JRE 8.0 available for download here : https://cdn.azul.com/zulu/bin/zulu8.44.0.13-ca-fx-jre8.0.242-win_x64.zip
Instruction for install and usage with Zulu JRE 8:
1- Download Zulu JRE 8 and unzip it in your machine, in my case zulu8 is unzipped in this directory C:\zulu8.44.0.13-ca-fx-jre8.0.242-win_x64\
2- change C:\zulu8.44.0.13-ca-fx-jre8.0.242-win_x64\bin\java.exe setting to fit high resolution screens settings :
* Right click on C:\zulu8.44.0.13-ca-fx-jre8.0.242-win_x64\bin\java.exe
* Select Compatibility Tab -> Settings and tick override high DPI scaling behavior [System]
3- Install STM32CubeProgrammer with Zulu JRE 8 :
* Open a CMD with administrator Privilege.
* install STM32CubeProgrammer => C:\zulu8.44.0.13-ca-fx-jre8.0.242-win_x64\bin\java.exe -jar SetupSTM32CubeProgrammer-2.4.0.exe
4- Launch STM32CubeProgrammer with Zulu JRE 8 :
* Open a CMD (no admin needed).
* CD STM32CubeProgrammer location : cd "C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin"
* launch : C:\zulu8.44.0.13-ca-fx-jre8.0.242-win_x64\bin\java.exe -jar STM32CubeProgrammer.exe