ChibiOS Free Embedded RTOS

Hi all,

I am encoutering some strange issues with GCC5 (5.2.1, 5.3.1, and 5.4.1) when running code on a STM32F405(RGT6). Compiling the same project with GCC 4.9.3 works fine, though.

What I do:
My system starts with a custom bootloader, which again loads the OS (ChibiOS/RT 3.1.4, ChibiOS/HAL 4.0.6 (branch stable_16.1.x)). The first line of my main() is the usual halInit() function, which already fails with GCC5. More specifically, I tracked the problematic code down to be one or multiple of the rccReset-functions in in the hal_lld.c file (lines 118-121), which are called within hal_lld_init(). Actually this is the very first code to be executed, except for the function calls. I even extracted these lines and put them at the beginning of my main() to avoid any memory access by function calls, but the issue persisted.

What happens:
Executing these lines causes the system to halt (or at least nothing is executed).

Since the problematic function calls just set some RCC registers to ¬0 and back to 0, my best guess is that GCC5 does not handle the volatile qualifier correctly. Has anyone similar issues or can reproduce this behavior? Or do you have any further ideas what I might be doing wrong?

I tested my system by lighting up a LED from the bootloader code (GPIO output is driven low) but configured my board.h to set the GPIO output to high on startup. However, even setting the RCC_AHB1RSTR register resets the GPIO configuration so it will not pull down anymore and the LED should turn off. This is not the case with GCC5, which I interpret that the RCC_AHB1RSTR register is not set/reset correctly.

Best regards,
Thomas

Hi,

Is it a self-built GCC or some distribution?

Giovanni

Hi,

I am using the GNU ARM Embedded Toolchain packages.

• GCC 4.9.3 = 4.9-2015-q3-update
• GCC 5.2.1 = 5-2015-q4-major
• GCC 5.3.1 = 5-2016-q1-update
• GCC 5.4.1 = 5-2016-q2-update

BTW, the whole toolchain works fine when using an STM32F103, even with GCC 5.x.

Thomas

Do standard demos do the same thing? I need something to debug.

Giovanni

I can't tell right now, because I am using a custom board and I don't have a Discovery at hand. I will try to get one in the next few days and test the F407 demos. I hope that these will reproduce the error, since there is no demo for the F405 (yet ) and with a F103 everything works fine.

Thank you for looking into this!

I will write again as soon as I could test the demos.

F405 is almost exactly the same processor as the F407. IIRC, the only difference is the ethernet controller that the F407 has and the F405 doesn't. So I've always run F407 demos on 405 boards without any difficulties.

Also, the CDC demos work just fine on my board. Just go in and change the pin of the LED to where you have a status led or something. This means you'll have some sort of feedback when the board runs.....

Finally I had some time to further investigate the issue.

Turns out that it is related to the FPU configuration. So far I have compiled my code with the setting "USE_FPU = hard" in my Makefile, but when I set it to "USE_FPU = no" the issues disappear.
I will further check the related code within ChibiOS/RT and see if there is some error, but since the "hard" setting worked well with GCC 4.8, I guess GCC 4.9 featured a yet unresolved (maybe even undiscovered) bug.

Btw, any other setting than "USE_FPU = no" results in that strange, non-deterministic behavior, which is a bit irritating as well. As I understand it, the setting "no" will remove "-mfloat-abi=name" from the GCC argument list, so that the compiler will use the default value. I would guess that the default is one of {"soft", "softfp", "hard"}, but since none of them works (but the default does) there seems to be some compiler magic here.

If you want to help to investigate, maybe you cs try to reproduce the issue with another project (some multi-threaded float processing) using the same compiler tool-chain, or/and check if everything works well when using another tool-chain.

Best regards,
Thomas

Hi,

OK, post here in case you find something, thanks.

Giovanni

Finally I found the reason for my problem!

It seems to be a hardware issue, since I replaced the MCUs on some boards with new ones and with these the issue is gone. Furthermore, when I reduce the clock speed from 168MHz to 156MHz, the old ones become stable as well. Seems as if some part of the FPU does not fulfill the timing constraints for some reason and older versions of GCC did not utilize it. I had a brief look at the ASM generated by 4.8, 4.9, and 5.2 and this could actually be true. With 4.8 only few of the "advanced" commands were used, while in the 4.9 and 5.2 files there are plenty of such.

Thanks for your help and the awesome quick replies!!!

Thomas

-- ISSUE RESOLVED

Update:
I found that there is already a flag in the kernel, which does fix the issue for me.
In file os/hal/ports/STM32/STM32F4xx/hal_lld.c in function stm32_clock_init() the preprocessor define "STM32_USE_REVISION_A_FIX" is checked.

IMO this flag should either be much more pronounced in the documentation and examples, or enabled by default. It did cost me quite some time to find the cause of my issue and this flag actually solves it. On the other hand, having it enabled by default increased image size and performance drop are negligible.

best regards,
Thomas