2017-07-23 08:43 PM
STM32CubeMX v4.22 fails to merge L4 v1.8.1 patch with existing L4 v1.8.0 source tree. Instead it creates two distinctive trees, one for v1.8.0 and one for v1.8.1 when they are installed one after another, i.e. when you install v1.8.1 patch on top of existing v1.8.0 tree. Solution is to delete existing v1.8.0 repository entirely and install v1.8.1 from the scratch. I don't know it applies to other patches.
2017-07-27 03:58 AM
Hi
Lee.Sungjune
,Thanks a lot for your feedback.
The issue is internally forwarded to our CubeMX team.Khouloud.
2017-08-29 11:16 AM
Not interested in 'Patch' -- If version 1.8.1 exists, where do I download it from?
2017-08-29 01:39 PM
I had CubeMX download them and merged the trees from the .ZIPs in the repository, want me to mirror that?
I've argued multiple times that ST should provide a means to directly download these, or provide a torrent. This would increase the chance people could successfully download the files, and reduce the loading on the servers from recurrent and failing downloads of >600MB files.
2017-08-30 10:09 AM
I'm good now, I just hand-merged the patch by assuming any files in it took precedence.
2017-08-30 10:17 AM
Yes, I just had WinRAR unpack and replace in the same STM32Cube_FW_L4_V1.8.0 directory both files describe.
2017-08-31 07:18 AM
Hi
Kelley.Jeff
,There is no STM32CubeL4 V1.8.1.
You have to download and then apply . Sorry for any inconvenience this may have caused.Khouloud.
2017-08-31 07:26 AM
Okay, and how is the patch applied? I could not find any document describing this procedure.
It's obviously not the standard
https://en.wikipedia.org/wiki/Patch_(Unix)
as produced by standardhttps://en.wikipedia.org/wiki/Diff_utility
(which is a pity).JW
2017-08-31 07:31 AM
The standard UNIX patch format wouldn't work for binary files (like PDFs). In this case the 'patching' is just a matter of extracting the archive over the existing files of the previous version with rewriting the old files.
2017-08-31 07:49 AM
Jive Tihs wrote:
The standard UNIX patch format wouldn't work for binary files (like PDFs). In this case the 'patching' is just a matter of extracting the archive over the existing files of the previous version with rewriting the old files.
This is exactly why Cube sources ought to be distributed in a way traditionally used for sources. Removing binaries from the zips would slim them down significantly to sane size, while retaining all relevant functionality, except perhaps the closed-source parts, which could be quite easily distributed separately.
In this case the 'patching' is just a matter of extracting the archive over the existing files of the previous version with rewriting the old files.
Thanks, but I'd like to hear official position of ST on this one.
JW