STM32_USB_OTG_Driver error on v0.6.0

Troubleshooting
1

I have been building locally a lot, specifically to test po-util. On versions of the firmware greater than v0.5.3 I keep warnings about STM32_USB_OTG_Driver. These warnings prevent firmware from being successfully built.

I am able to bypass the warnings being errors by using using make -k, but I would like to know if there is a better way to get around STM32_USB_OTG_Driver.

Here is what I get when I implement make -k:

Building firmware for Production Photon, platform ID: 6, product ID: 6
src/main.c: In function 'main':
MCU/STM32F2xx/STM32_USB_OTG_Driver/src/usb_core.c:301:27: error: iteration 6 invokes undefined behavior [-Werror=aggressive-loop-optimizations]
MCU/STM32F2xx/STM32_USB_OTG_Driver/src/usb_core.c:299:3: note: containing loop
MCU/STM32F2xx/STM32_USB_OTG_Driver/src/usb_core.c:307:25: error: iteration 6 invokes undefined behavior [-Werror=aggressive-loop-optimizations]
MCU/STM32F2xx/STM32_USB_OTG_Driver/src/usb_core.c:305:3: note: containing loop
lto1: all warnings being treated as errors
lto-wrapper: arm-none-eabi-g++ returned 1 exit status
/home/ubuntu/bin/gcc-arm-embedded/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[1]: *** [../build/target/bootloader/platform-6-lto/bootloader.elf] Error 1
make[1]: Target `all' not remade because of errors.
make: *** [bootloader] Error 2
   text    data     bss     dec     hex filename
   4524       8    1460    5992    1768 /home/ubuntu/workspace/bin/firmware.elf
make: Target `all' not remade because of errors.

Firmware is still built and a firmware.bin is created.

Here is the full command for building firmware from po-util:

make all -k -s -C "$BASE_FIRMWARE/"firmware APPDIR="$FIRMWAREDIR" TARGET_DIR="$FIRMWAREDIR/../bin" PLATFORM="$1"

It is weird that firmware still gets successfully built if the make command “fails”.

Should I ignore these STM32_USB_OTG_Driver errors? I would like po-util to be a easy to use as possible and I don’t want users to think that they have a problem with their code if it is just a warning from the firmware.

UPDATE:
I just re-read the make manpage and found

       -i, --ignore-errors
            Ignore all errors in commands executed to remake files.

Would it be sensible to use this?

UPDATE:

Here is the error log when I added -i

Building firmware for Production Photon, platform ID: 6, product ID: 6
src/main.c: In function 'main':
MCU/STM32F2xx/STM32_USB_OTG_Driver/src/usb_core.c:301:27: error: iteration 6 invokes undefined behavior [-Werror=aggressive-loop-optimizations]
MCU/STM32F2xx/STM32_USB_OTG_Driver/src/usb_core.c:299:3: note: containing loop
MCU/STM32F2xx/STM32_USB_OTG_Driver/src/usb_core.c:307:25: error: iteration 6 invokes undefined behavior [-Werror=aggressive-loop-optimizations]
MCU/STM32F2xx/STM32_USB_OTG_Driver/src/usb_core.c:305:3: note: containing loop
lto1: all warnings being treated as errors
lto-wrapper: arm-none-eabi-g++ returned 1 exit status
/home/ubuntu/bin/gcc-arm-embedded/gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
arm-none-eabi-objcopy: '../build/target/bootloader/platform-6-lto/bootloader.elf': No such file
mv: cannot stat ‘../build/target/bootloader/platform-6-lto/bootloader.bin.pre_crc’: No such file or directory
arm-none-eabi-objcopy: '../build/target/bootloader/platform-6-lto/bootloader.elf': No such file
arm-none-eabi-size: '../build/target/bootloader/platform-6-lto/bootloader.elf': No such file
   text    data     bss     dec     hex filename
   4524       8    1460    5992    1768 /home/ubuntu/workspace/bin/firmware.elf

The command exits with 0, meaning it was successful. firmware.bin was generated.

UPDATE:

When I intentionally add invalid code to my main.cpp, the make command returns 0, due to the -i, but a firmware.bin is not built, as expected.

So here is my problem. I need the make command to return 0 when firmware.bin is built, but not crash if there is just a warning about STM32_USB_OTG_Driver.

The -k does not really help. firmware.bin is built, but make does not return 0. -i makes it always return 0, even if I have bogus code and firmware.bin is not built.

Is there a way to just disable the warnings from STM32_USB_OTG_Driver? Looking from the log, I can see that they are of type -Werror=aggressive-loop-optimizations. Is there a way to disable them so that I can make po-util work smoothly on versions 0.6.0 and greater?

UPDATE:
I have removed -i and -k for now.

2

@jvanier are you experiencing this?

3

No, I’ve never seen this before. I don’t know what would cause this, sorry.

1 Like
4

I’m getting this error too. I used the -i option from the command line make command to ignore errors and it worked. Maybe a compiler got a bit smarter and started warning about a new type of error? I’m compiling v0.6.0-rc.2.

1 Like
5

I solved this for Platform ID: 6 Product ID: 6:

I believe that the problem is caused by over aggressive optimization when using GCC. I solved this by modifying the file:

{path_to_particle_sources}/firmware/platform/MCU/STM32F2xx/STM32_USB_OTG_Driver/src/usb_core.c

where {path_to_particle_sources} is where you installed the particle build system files. In my case, since I installed this using the po-utils.sh utility it was at ~/github.

At line 214 in that file, type in:

#pragma GCC optimize ("O1")

and save the file.

Note that the first character in the quotes above is a capital O, not a zero, and it’s followed by the numeral 1, not a lower case ell.

That decreases the optimization level for the remainder of that file, and seems to cure the problem. I tried using “O0”, which turns optimizations off, but this resulted in a firmware image that was too large.

IMPORTANT: you will need to redo this modification if you do a “po clean” operation using the po-utils.sh script, since that overwrites the particle systems files.

I hope this helps.

1 Like
6

Thank you @schalmer. Your solution works, and I have implemented it into po-util, so that the line gets put in whenever firmware is built.

@jvanier would it be good for this to be changed in the official firmware to eliminate this problem?

UPDATE:
Firmware can no longer be built for Electron due to the following error:

section `.text' will not fit in region `APP_FLASH'

https://travis-ci.org/nrobinson2000/po-util/jobs/181063143#L1165

7

Not really a fix, but it does remove the error. I’m sticking with -i so I still get the optimization, and probably whatever other error gets baked in. Good find tho.

8

Hi Folks,

While I am glad that you guys figured it out there are a few issues to sort out here:

  • That file is not really “owned” by Particle–it comes from ST Micro, so every time the authors update it, Particle would have to remember to “fix” is again. Not optimal.

  • As you found out, there is a large difference in code size depending on optimization level, which can really hurt on these constrained memory platforms.

A better fix would be to work with the code and possibly its authors to figure out what is going wrong. Looking at that file, there is a lot of ifdef going on and my first thought would be that could be going wrong. In any event, I filed a github issue for the team to look at here:

3 Likes
9

On Github it looks like PR 1179 fixes this:

Can you guys building this locally get this PR and test it please?

Thanks @avtolstoy!

3 Likes
10

Thank you @bko!

The changes made in the commit you mentioned solve the problems for Photon and Electron.

In the meantime, I have made it so that po-util modifies the files itself so that the problem is eliminated for po-util users.