No binary or hex file output

[RAltm]

Hello,

I've a strange problem with CubeIDE 1.6.0, there's no binary or hex file output even if the corresponding outputs are activated under MCU post build outputs. Any ideas what might be the issue there?

Regards

[Tesla DeLorean]

The build failed in some fashion, either at the linker or make level? Review log files, check for .MAP or .ELF as evidence that the linker got closure/completion.

[Pavel A.]

Same here, after importing Atollic projects to v. 1.6.0

Has to use a post-build script for binary file. Are your projects imported?

-- pa

[RAltm]

@Community member​ 

The map and elf files are created well. Which log files do you mean?

@Pavel A.​ 

No, I didn't import the project. It was made with CubeIDE 1.5.x and F4 HAL v1.25.2. Then I updated to CubeIDE 1.6.0 and F4 HAL 1.26.0 a few days ago.

I'm not sure if I activated the binary file output when the project was created, so I can't say for sure that it's related to the CubeIDE or the F4 HAL update.

Regards

[Pavel A.]

While they are pondering on yet another problem , here is a postbuild script to plug the hole.

For Linux _and_ Windows. Not tested on OSX.

-- pa

#!/bin/sh
# Add this command as postbuild action: 
# sh postbuild.sh ${BuildArtifactFileBaseName}
EXENAME=$1
[ "$HOMEDRIVE" = "" ] || BUSYBOX="busybox "
 
# Print memory sizes:
arm-none-eabi-size $EXENAME.elf || exit 1
# Convert to bin
arm-none-eabi-objcopy -O binary $EXENAME.elf $EXENAME.bin
# and print size of the .bin 
$BUSYBOX stat -L -c "%N size=%s" $EXENAME.bin
 
# Produce .list :
arm-none-eabi-objdump -h -S $EXENAME.elf > $EXENAME.list
 
echo "POSTBUILD DONE"

[DShan.1]

It appears that the MCU Post build outputs step is run only when Builder Type (on Builder tab in Properties->C/C++ Build) is External builder. When I set Builder Type to Internal builder, the MCU Post build outputs step is not run.

This appears to be a bug in STCubeIDE 1.6.0

[RAltm]

Hello @DShan.1​ ,

thank you for reporting it. I hope ST will take notice of this issue.

Regards

[Cartu38 OpenDev]

Fact is STM32CubeIDE default is external builder not internal one.

I confirm if internal builder usage post build step leading to have following UI settings not active

 

But still possible if internal builder to rely by yourself on post build steps

 

Why are you moving to internal builder ???

[DShan.1]

This issue does not appear to have been resolved in the just released update to STM32CubeIDE, version 1.61.

[RAltm]

It seems that ST didn't take notice of it... at least they didn't respond here.

[Peter BENSCH]

I just compiled a small project with CubeIDE 1.6.1... no problem creating bin and/or hex files.

Any way to recreate this issue?

Regards

/Peter

[DavidAlfa]

Working ok here.

[mattias norlander]

External builder is the recommended way in CubeIDE as in many other Eclipse/CDT based tools. We chose External rather than Internal because it was more actively support by the Eclipse community and it makes sense to move with the OSS community. So, please consider Internal Builder untested by us, so things like hex/bin/srec generation may not be supported at all.

Thanks @Cartu38 OpenDev​ for creative work-arounds! ;)

[DShan.1]

Does there exist somewhere a list of features of CubeIDE that are untested and/or unsupported?

This is a feature that worked properly on STM's previous IDE (Atollic). It's reasonable for customers moving projects from Atollic to CubeIDE to expect features that worked before to continue to work.

[Cartu38 OpenDev]

Sounds like you're asking something not realistic I guess.

Eclipse offer is so wide .... Pro and cons. of open source. I cannot imagine myself STM is validating back all Eclipse ecosystem ... Best case they can contribute to to improve it and validate their own addons but more ???

[DShan.1]

Nobody suggested that they "validate back all Eclipse ecosystem." But validating the software they provide to their customers seems like a good idea. Maybe I'm old fashioned.