IRQ vectors not being set in PIO toolchain, causing bootloop w/2.5.x releases #6087
Comments
|
As mentioned in the original chain @platformio, the 2.5.0 and 2.5.1 toolchain are identical. If 2.5.0 worked, then there is no changes to the esp-quick-toolchain stuff in 2.5.1. This is also a GNU linker option, which we absolutely do not modify or even look at in out own patches. Also, I did just enable issues on the EQT repo. But, again, there was no change in |
|
Yes, the bug with new build chain was and is still in 2.5.0 so as in 2.5.1. It was never corrected |
|
We use the -Wl, stuff to generate .map artifacts and pass in linker control options in the main Arduino, so it being used and works fine for us: Line 105 in 98125f8 |
|
Yes. I know, and it does work fine for Arduino IDE. Platformio does it in a different way for all platforms as @ivankravets did note. He will not change |
|
As mentioned in the original issue: Line 54 in 98125f8 Would doing the same thing as PIO does with this line cause the same problem, make resulting elf different in some way? (use -Wl,-T... at the end instead of -T... in the middle). |
|
I was never able to get PIO working properly, but the output of this line in question is an ELF file and ROM, yes? It's unlikely that G++/LD arg parsing is busted in the 2.5.1 toolchain, but there may be some ordering requirements or something else in the parsing of the script that changes the output when completed. Can you build and attach 2 versions of the same Blink.ino (i.e. simplest one you've got) one with 2.5.1 tools and one with whatever toolchain you've been using? I'd like to see the ELF, MAPs, etc. to say see what's different. Right now, I don't even have that... Thx |
|
Oh, and as verbose a compile and link output as you can get, too, please. |
|
Also, are you saying that using everything the same and suimply changing the executables in xtensa-lx106-elf/... (and no other files) makes the latest Arduino core work in your app? |
|
Just did a quick test and both And replacing the -Wl,-T with -T works, too. The -Wl-T fails to run, but not because it isn't parsing the script, but because it's not including the hardware IRQ vectors. This is a scripting problem and not toolchain one. |
Can we make a fix on our side? |
|
I'm about to put in a PR for it. Basically need to force GCC not to optimize away IRQ vectors before the linker gets to it. Give me a few mins and I'll have it in. Just tested and it's working w/minimal impact on Arduino core. |
PIO uses GCC in a way that causes the compiler to optimize away the IRQ vectors (since they're not used in our code itself) in the final build stage. We can avoid this by forcing all of libmain to be included in the final object. This is a small file, and almost completely related to IRQs, so space impact is minimal. Fixes esp8266#6087 and platformio/platform-espressif8266#147
earlephilhower
changed the title
|
So I did some more digging and the symbols are there, but LD's not actually putting the vectors in the file when you delay the link file with -Wl-T as opposed to the gcc -T. First part of passing MAP. See how the linker actually stuffs in the code to call the vector: Failing (-Wl-T) doesn't seem to set the vector even if it's |
|
So, the issue is linked with GCC LD? |
|
The LD link scripts more than the exes, I'd guess at this point. There's something in the way eagle.ld is asking for the vectors that is parsed differently (or in a different order of ops) when using gcc vs spawning the ld to do it. Generated, unique section names, maybe, so the match does not fire... |
|
This is actually happening on Arduino IDE too. |
|
That's another problem, as it says. You're calling an ISR which is not in IRAM so it warns you that it will fail at some point (when the ISR is not in cache and there's a background flash operation by the SDK). Please don't dogpile on this bug as it's a very specific PIO linking thing. |
|
Sorry for dogpiling. It seemed related at first glance. The problem I'm seeing started manifesting after updating to 2.5.1. Previously, in 2.5.0, the sketch was functioning correctly, including the ISR. No codechanges between updates of the SDK. |
|
Sure, @alexsomesan, open another issue. We now allow IRQs during flash operations, so even if it used to work you may still have issues. The warning is in our code and you can either move your ISR to IRAM or we can see if it makes sense to only use that on Debug builds. |
|
OK, confirmed that adding |
|
After looking again at the check inside platformio-core... If -Wl,-T and -T differ so much, isn't it possible just to use overridable board_build.ldscript for each env instead of it being part of build_flags? That way either board default or user chosen script is used, passed as -T... argument. And Arduino Core does not need to modify anything. |
|
The problem seems to be a difference in how Simply adding I can run that by the other maintainers and see if we can merge it in. It's a no-op (and the ROM isn't changing so mods to that file should not be a problem). |
The interrupt vectors in IRAM are ommitted when there is a PROVIDE
statement in the linker control files when using the PIO method of
-Wl,-T<linkfile>.
Drop the PROVIDES (they're in RAM anyway and not ROM related), and
add the required "-u"s to the P{IO build script.
Should have no iumpact on the Arduino side.
Fixes esp8266#6087
|
Confirmed #6095 fixes this issue |
|
Reopening just to track that until the PR is committed, it's still a problem |
|
@earlephilhower You did great research! Thanks!!! Can we apply this patch #6095 to 2.5.1 and release as a part of 2.5.1? So, we will use the same toolchain which is used by Arduino IDE. |
|
@ivankravets Unfortunately, that ship has sailed. V2.5.1 came out a week ago (the impetus for this issue). We can see on the gitter channel if there's a possibility of doing a very early 2.5.2 (now that I hope we've stabilized on the new release process) in a couple weeks with this and a few other fixes that come up as people report back. |
|
@earlephilhower we ship own package of Arduino core for ESP8266 and we can do this patch from our side even in 2.5.1. Does it make sense? |
|
Sure, that's all up to you. :) The core itself will get this merged, and we'll sync-up again at the next release. |
|
Good! I think we can wait too. There is no critical requirement to use new toolchain. We will switch to it with 2.5.2. Also, I'll switch to the new toolchain in our "stage" branch and see if it works for people. |
The interrupt vectors in IRAM are omitted when there is a PROVIDE statement in the linker control files when using the PIO method of -Wl,-T<linkfile>. Drop the PROVIDES (they're in RAM anyway and not ROM related), and add the required "-u"s to the PIO build script. Should have no impact on the Arduino side. Fixes esp8266#6087
I open the issue here since here https://github.com/earlephilhower/esp-quick-toolchain it is not possible.
It seems how
-Wl,optionis done is not the usual wayIssue is discussed
platformio/platform-espressif8266#147 (comment)
The text was updated successfully, but these errors were encountered: