2 years, 1 month ago.

Error: L6636E on the NUCLEO-F767ZI & DISCO-F746NG

Thank you for continuing to develop Mbed.


Considering these are high end targets, I was surprised and a little disappointed to experience this:

Error: L6636E: Pre-processor step failed for '/extras/mbed-os.lib/targets/TARGET_STM/TARGET_STM32F7/TARGET_STM32F767xI/device/TOOLCHAIN_ARM_STD/stm32f767xi.sct'

Compiling Mbed-os-example-blinky, using the online compiler with all files updated. Works on the Mbed-LPC1768 and some other boards I checked.

Regarding this:


My question really is how did this pass the testing process ?

I'm using rev.5.10 17th Nov 2018 which is the latest working revision for these targets. Could we have some urgent attention to get them working on the next update please.

Question relating to:

I got a same error message using different CPU targets.
I observed on nRF52-DK, nRF52840 and Nucleo-F446RE yesterday.
I tried several times to compile it.
Sometimes successfully done and sometimes fail even I'm using same source code without no modification.
I'm using latest mbed-os5.
I guess this is not related target CPU or OS revision but online compiler timing issue.

posted by Kenji Arai 29 Apr 2019

Hi Paul,

Thanks very much for raising the issue. I tried to reproduce the failure you mentioned by compiling the mbed-os-example-blinky example (https://github.com/ARMmbed/mbed-os-example-blinky) for the NUCLEO-F767ZI board in the online compiler. I did a clean build about 3-4 times, but each time the example built successfully and I was able to download the binary. I used the latest example, so that was using Mbed OS 5.12.2.

Is there a specific program that you're compiling to get these errors? I'd like to reproduce this issue you're having.

Thanks, Brian

posted by Brian Daniels 30 Apr 2019

Brian, you've tweaked something on the compiler :)

I tried many more times than you did on various targets and I got the same error every time, even logged out of Mbed and PC re-boot, it was the same.

Both the F767 and F746 now work on blinky the same as you and the TCP-server example.


Spoke too soon it's back again, seems to happen when I do a 'Compile All', if I then follow up with a 'Compile' it compiles without error, 'Compile' again and the error is back, the issue alternates.

posted by Paul Staron 30 Apr 2019

I've tried what you said to alternate between "Compile All" and "Compile" but I haven't gotten it to fail in the manner you described. I'm wondering if its specific to certain projects. Is your code public somewhere so I can try it?

Also, you mentioned in your previous post that "the error is back", do you mean the error that you first posted about? (Error: L6636E: Pre-processor step failed for '/extras/mbed-os.lib/targets/TARGET_STM/TARGET_STM32F7/TARGET_STM32F767xI/device/TOOLCHAIN_ARM_STD/stm32f767xi.sct')

posted by Brian Daniels 01 May 2019

Yes same error.

Brian, thank you but don't spend any more time with this, I believe the problem stems from a combination of my slow ISP and the sheer volume of warnings with os5 that seem to aggravate the problem, if I use os2, little or no warnings, then no problem. I'm in a rural location and use 4G mobile data where my up-link speed is rather slow. I should have fiber soon so the problem will probably go away.

It must be the case otherwise there would be many others with the same problem. I'm also using the same blinky example and os as you are trying.

( Would be nice to reduce those warnings :) )

posted by Paul Staron 01 May 2019

Understood, yes the number of warnings does make sorting through all of the feedback pretty intense. I wouldn't expect a poor internet connection to lead to the "pre-processor step failed" error, since this occurs on the build system's server, not your machine. If you continue to see this error please private message me as I'm keen to see these errors go away if they are indeed a problem.

Thanks for your help Paul! -Brian

posted by Brian Daniels 01 May 2019

I found a way to reproduce this issue, thanks for all of the tips. It seems I needed to create a fresh clone of a project.

posted by Brian Daniels 02 May 2019

Hi everybody, I am using the NUCLEO F767ZI board and I have the same problem as Paul. The "pre-processors step failed" error appears to be completely random. Could it depends on which server has been used to compile the software? Any suggestion is welcome. Thanks Marco

posted by Marco Sulliotti 04 May 2019

Again, I don't want to see Mbed guys wasting time here, but there is definitely a problem and I may be wrong but this issue needs to go back to the ARM compiler guys not Mbed.

I'm finding it random, recompile and all seems to complete without errors.

I have found other strange behavior, very occasionally I will get the Mbed error code of death, recompile again and no problem.

I can't see what error has been detected only register print out. It must mean something to someone who knows what they are doing though.

Something I have noticed is an increase of random compile errors since December last year (2018). I think Mbed switched to ARM 6 a few months back, at least I thinks its ARM 6, I get confused which compiler edition we are linking to.

Maybe there is an anomaly there. Perhaps Brian could update us with the compiler time-line changes and exactly which edition we are using that could help drill down to the issue and when it happened.

If I use os5 and os2 revisions prior to December 2018 the problems generally go away.

I'm a little concerned the online Mbed compile hits will be increased due to this situation that may lead to reduced performance and potential memory shortages as we have experienced before. Although atm its quite reliable.

posted by Paul Staron 04 May 2019

I can confirm that this issue is still happening with a Nucleo-L037RZ. Builds fail randomly with the "pre-processor error". Sometimes its 1 in 20, sometimes is 4/5 that fail.

posted by Andrew Goodney 29 May 2019

3 Answers

1 year, 11 months ago.

We were finally able to reproduce and identify the cause of the "L6636E: Pre-processor step failed" errors in the Online Compiler. This error was being caused by a bug in the Online Compiler which would cause compiles to randomly break during linking. This mainly affected Mbed OS versions 5.12 and 5.13.

We rolled out a fix for this today and so you should no longer see this error at all.


Accepted Answer

Thank you so much! Your effort is really appreciated.

posted by Zoltan Hudak 07 Jul 2019

Many thanks! Everything works fine now!

posted by Marco Sulliotti 11 Jul 2019
1 year, 11 months ago.

Hi all, First of all; apologies to all of you who are having this problem. Rest assured that we are actively working on this to find a resolution. What we know so far is that this issue is apparently random; it shows on some accounts and not others. The frequency can vary between never and every time. Our test systems do not seem to show the problem, but the production ones do. All this makes this issue very hard to investigate. Ta, Mark

I am also having this problem with a first-time install of the STM32L476G-DISCO. 5th try worked - no changes.

posted by Andrew Wolfe 27 Jun 2019

I have tried different global locations and the problem remains. This really needs some priority now. Could I suggest to put the breaks on other development and focus on a solution here.

OS5 Windows or MAC is very bad, almost unusable.

If it helps OS2 is solid at least for me it is, but this has been shelved,

posted by Paul Staron 30 Jun 2019
1 year, 11 months ago.

Same here with NUCLEO 476RG.

This exact error is happening in my online compiler as well. I created a clone of the project that this happens with, and it doesn't happen with the exact clone! This kind of intermittent issue makes me want to avoid the online compiler completely. The fact that updates can be pushed to the online compiler which can break a functional project is an issue when using the online compiler for a time sensitive project. I see the last comment from Mbed devs came three months ago and suggests that the problem is resolved but it is not on my end.

posted by joey shelton 10 Oct 2019