2025-03-19 2:39 AM - last edited on 2025-03-20 4:23 AM by Andrew Neil
Code generated by CubeMX use Windows line-endings, which generate huge problems under other operating systems (repository, editors, etc.). You have to strip CR-LFs after every code generation.
Somebody should use standard method of platform-independent text file generation (StringBuffer and System.lineSeparator()).
2025-03-20 3:01 PM - edited 2025-03-20 3:38 PM
With more positive attitude and if you won't mind calling this bug 'feature request' this may get traction ))
@STTwo-32 ??
IIRC readline() can be configured to ignore CR with ~/.inputrc or some rl_... function.
2025-03-25 3:52 AM
Is it this moment when you realized it is a feature not a bug?
I still need it to be fixed.
2025-09-10 6:49 AM
This is indeed VERY annoying. We have people using this on multiple machines and after every CubeMX generation we get 100 files changing just because of the line endings... Please not call this a feature :)
2025-09-10 7:03 AM
Hello,
The behavior has been escalated internally for analysis with an internal ticket number 217250 not accessible by the community users.
2025-11-20 7:48 AM
Hi @mƎALLEm!
Please let me share one more data point for this that would be great if it was added to the internal ticket.
When generating code for CMake build setup with STM32CubeMX 6.16.0, it turns out that NonSecure/mx-generated.cmake and Secure/mx-generated.cmake uses all 3 kind of line endings: \n, \r and \r\n. This makes it a bit hard to handle conversion of these files to the format you want and causes clutter in many diff tools. It would be better if it used 1 kind of line endings even if it is not the platform specific one.
As a side note it also seem to mix indenting with spaces and tabs.
Reproduced on Windows 11 and Debian bookworm.
I have attached the .ioc and the generated cmake-file.
Best regards, Jesper
2025-12-14 11:49 PM
Hi, any news here? I have no the problem on windows that it generates only LF with the latest version.
2026-01-30 11:18 PM
me too!
2026-02-01 1:43 AM
It would be nice to configure (have option to generate this or that) but IMHO the era of non-Unix line endings is over. All decent software tools are comfortable with LFs only (and UTF-8 instead of anything else).
In your git repo you can just disable the "translation" with this .gitattributes file:
* -text
2026-02-05 12:26 AM - edited 2026-02-05 12:36 AM
Joining the club. CubeMX v6.16.1 on Windows for N6 creates CMSIS, HAL and Middleware files with \n only. Core directory files are with \r\n line ending. SCM tools show not-real changes in Git repo and it's obviously quite annoying to manually check/revert them.
I don't know if it was supposed to be a solution or it was an accident, because release notes don't mention line ending changes, but now no OS user is happy. Maybe that's fairness? :)
Jokes aside, how hard it is to make an option into CubeMX to pick the line ending and let one option be "OS-specific" so cross-platform teams can use same IOC file?
2026-02-05 12:52 AM
We can only convert the library file yourself once first, which will be much better. It's a temporary solution; I used Python to do the conversion.
import os
def lf_to_crlf(folder_path):
"""
LF 2 CRLF in c,h,txt files
"""
for root, dirs, files in os.walk(folder_path):
for file in files:
if file.endswith(('.c', '.h', '.txt')):
file_path = os.path.join(root, file)
try:
with open(file_path, 'rb') as f:
content = f.read()
new_content = content.replace(b'\n', b'\r\n')
with open(file_path, 'wb') as f:
f.write(new_content)
print(f"Converted: {file_path}")
except Exception as e:
print(f"Error: {file_path}: {e}")
if __name__ == "__main__":
folder_to_convert = r"C:\Users\<your dir>\STM32Cube\Repository\STM32Cube_FW_F4_V1.28.3/"
lf_to_crlf(folder_to_convert)