Firmware build for PICO fails - make: *** [lib/startup_stm32f401xx.o] Error 127 #6570
Replies: 1 comment
-
Posted at 2021-09-25 by Robin Later that day: Attempted to install a cross compiler per: (although I am unable to truly understand what this might do)
Upgraded VSCode to 1.60.2
But alas, still the same error. Posted at 2021-09-25 by Robin Trying to re-install GCC Mistake - That hosed my PATH var. Spending next hour re-editing / re-building Posted at 2021-09-25 by @MaBecker Espruino is using gcc arm 8 q4, not sure if 10 like you installed will compile smoothly. check provision.sh https://github.com/espruino/Espruino/blob/042dbffdd585a1b1654b18688be0be9c9b6a7f96/scripts/provision.sh#L225 Posted at 2021-09-25 by Robin Sat 2021.09.25 06:59am CST Thank you for taking a peek into this @MaBecker Just put on the first pot of coffee to get back at this. That link should assist in a basic understanding of what parts (apps?) should be in place, although it's a bit convoluted for my understanding at the moment. I took that user response at face value and just gave it a try as I didn't have any true idea of what is going on. A simple un-install might cure that, as it appears that only a part of the PATH var was prefixed. Something else to repair. It just dawned on me that I upgraded nRFConnect and specifically the Programmer sub-app three weeks ago. I'm wondering if anything in it's set of flashing tools might have hosed something. Off to check as I start on this first cup! . . . . Posted at 2021-09-25 by Robin Sat 2021.09.25 07:41am CST Well, this really Bites! BEWARE and take note - others on Windows10 As I set a restore point before I performed the nRFConnect upgrade three weeks ago, I went to restore to that point just before that upgrade in order to determine if VSCode would run as it did before the nRFConnect upgrade. Sadly, this new version of Windows10 ver 20H2 performs a system Automatic Restore Point AND removes all the previous restore points prior. S#!t Until around 18 months ago it was possible to restore all the way back to when Windows was first installed. A limit was put in place shortly after that kept the number of restore points to around the last five. Now I am unable to even go back before the last three days, and I performed my own restore point creation three weeks ago. This does indeed BITE! Posted at 2021-09-25 by @fanoush If you are on Windows 10 then I'd suggest to do it in WSL - Windows subsystem for Winux with some Ubuntu inside. I have Ubuntu 18.04 in WSL1 and Ubuntu 20.04 in WSL2 and both builds Espruino, WSL1 with older Ubuntu is probably easier to setup. see https://wiki.ubuntu.com/WSL If you already have WSL (previously called Bash on Windows) (because of Or are you using mingw? Then I'd recommend installing WSL instead , version 1 should be enough. Mingw is good for building linux/posix stuff as windows native binaries, you don't need that with Espruino and WSL gives you better compatibility. As for VSCode on windows side - there is WSL remoting plugin for VSCode so you can have Espruino inside WSL linux distro and VSCode can connect to it for editing and working with GIT. The ubuntu wiki page mentions it too. Posted at 2021-09-25 by Robin Sat 2021.09.25 - 09:18am CST Thank you for responding @fanoush re: 'then I don't understand why you try to install gcc toolchain on windows side' As pointed out above, two years ago with the assistance of @AkosLukacs thread, I was able to get VSCode running with a WSL terminal Window. I was successful in building the PICO build then. Total cumulative experience, <2 hrs. I have no clue why a perfectly working setup would all of a sudden stop working. other than installs corrupting as I surmise It appears, post #5 and #6 that my install of nRFConnect did something mysterious as when I first loaded VSCode and tried examples that I couldn't get past the very first instruction setting the env var. I started this thread. I installed gcc as a user on StackExchange indicated doing that task solved his issue. I knew it was a long shot, so I tried it lacking any near immediate response within this thread, and trying to get a head start on solving the configuration issue before the weekend started so that I could perform some flashing this weekend. Maybe in my haste, I've added another headache???? We'll see. I've just gone over all the Win10 environment vars, and am satisfied, so a reboot is in order. Just making a few notes and backups before I reboot and get ready for what doesn't happen after Ctrl+Alt+Del. Will be off line for fifteen minutes inspecting what may not recover ;-) Posted at 2021-09-25 by Robin reply to post #7 I'm running a WSL terminal window from inside VSCode. No virtual drive.
Using suggestions from: and
Simply run the following with the name of your board to set your computer up ready for a build:
So, is it Python that isn't running???? I just cloned the Espruino respository a day or two ago. PICO board file is there:
I noticed while reviewing the Env Vars that nRFConnect installs a more recent version of Python and changes the path. I've just edited the path back to what it was and will now reboot. Posted at 2021-09-25 by Robin Sat 2021.09.25 - 09:58am CST I'm running a WSL terminal window from inside VSCode. No virtual drive.
Just re-entered these commands and the second to last, the make clean && make now runs for an extended period which it hadn't before. So I thought success. Except when I run:
Just looked and there isn't a startup_stm32f401xx.o file just a startup_stm32f401xx.s
Does that provide a clue to anyone?? Posted at 2021-09-25 by @fanoush
Isn't You should run the provision script with board name that exists there i.e. PICO_R1_3 Posted at 2021-09-25 by Robin Sat 2021.09.25 - 11:18am CST
Okay, I'll take the bullet for that one, but which part of the environment is complaining? While I'll freely admit I have only around <2hrs of practical poking my nose around two years ago after getting VSCode to actually do something useful and haven't made a build attempt since, it's likely you have >2000+ hrs combined over the years. How is one to deduce that a file is to be created when the error states a 'Command not found' prompt? The error suggests an issue with the 'recipe' file. Still too cryptic from a casual observer view. Posted at 2021-09-25 by Robin Sat 2021.09.25 - 11:49am CST
Somewhere in the documentation I took the literal text 'PICO' as the only valid board name in the list of available boards. 'PICO_R1_3.py' is a filename. Subtle difference, but I'm following the documentation verbatim. Just can't find that location on github right now, but will post when I stumble across it. So, no this error doesn't explain what may be intuitive to you.
I guess it comes with experience:
Posted at 2021-09-25 by Robin Sat 2021.09.25 - 12:24pm CST Back online after two separate reboots. The PATH Env var is now half it's expected corrupt size, and using the clarification text now allows the installation of gcc which both @MaBecker and @fanoush expected was the culprit. Not 100% sure the actual configuration fix, but likely the fact two versions of Python were present, the unexpected 2nd as a result of updating nRFConnect as from my original hunch. This is new:
A new version GCC being installed Posted at 2021-09-25 by Robin Sat 2021.09.25 - 12:41pm CST Finally progress! Make is trying to do something. Thank you @fanoush as I now see the .o files being built within the terminal window. Even with a preceeding:
not out of the woods yet, and knowing I just recently cloned Espruino, still won't build without error;
Is there any way to get the make output to stop generating output once an error is detected? The terminal window scrolls the earliest off the top. Ctrl+C hit-n-miss Posted at 2021-09-25 by Robin Sat 2021.09.25 - 12:53pm CST Similar errors occur for WIFI also:
Posted at 2021-10-01 by Robin Thr 2021.09.30 This parallels the build issues here:
Rather than monitor two separate threads, I'm continuing resolution at the above link. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2021-09-24 by Robin
Fri 2021.09.24
I had VSCode running and building on Win10 two years ago running through instructions at:
This week I cloned the current git source to work on a related project. After several failed attempts, I decided to perform a sanity check with a basic PICO build version, from notes created two years ago.
Now, just making the attempt to set the environment var, causes this error:
Upon checking my local folder structure, I notice there is a board of the same file name with extention 's' rather than 'o' > C:\Users\robin\Documents\Espruino\Espruino\targetlibs\stm32f4\lib\startup_stm32f401xx.s
Honestly, I don't have enough experience to know what should be happening under the hood. Did I miss something in the build process instructions, or is the current new clone not building the 'o' ext that is now causing this error?
Posted early, I'm going back over the instructions to see if I missed something.
Beta Was this translation helpful? Give feedback.
All reactions