Feature Request: allow custom linker scripts

[JetForMe]

Because my project is solar powered, the power to it is sometimes very "dirty." This is causing the bootloader to trigger (despite a bug I fixed). I want to just flash my code without any bootloader, but that means changing the linker script, which currently can only be done platform-wide.

It'd be great if I could include a linker script in my sketch like any other source file.

Thanks!

[facchinm]

Hi @JetForMe ,
are you using a SAMD board? In that case I'd move the issue on the proper repo (and give you a possible hint 😉 )

[JetForMe]

I am using SAMD! But I'm sorry, I don't know where the proper repo is. Seems like this would apply to any platform though, wouldn't it?

Thanks!

[facchinm]

Here we go, issue moved :)
The problem you are seeing is due to the "double tap" feature, so the reset pin gets a bounce twice in less then 500ms and this instructs the bootloader to just wait and avoid booting the sketch.
My advice, instead than compiling without bootloader support, is to flash a special bootloader with the double tap feature removed; to do so, just comment BOOT_DOUBLE_TAP_ADDRESS in the relevant header (here for example https://github.com/arduino/ArduinoCore-samd/blob/master/bootloaders/zero/board_definitions_arduino_mkrwifi1010.h#L37 ) and run build_all_bootloaders.sh , then flash the binary.
In this way you need to do it only once for each board without manually modifying the core based on the target.
Hope it helps!

[JetForMe]

Yeah, that might work. I actually found a bug in the double-tap code that improved my situation, but still didn't fix it 100% of the time. Here's the PR that is still in review: microsoft/uf2-samdx1#89

The problem is that it treats any reset as a tap on the reset button, including brown-out resets, which is what I think is happening in my case when the battery is dying or the sun is just coming up.

If I comment that out, how does one enter the bootloader then to flash a new application?

[facchinm]

If I comment that out, how does one enter the bootloader then to flash a new application?

The SerialUSB 1200bps touch (the usual thing we do while uploading through the IDE) still works in that case, so it should be a viable solution

[JetForMe]

Ah okay. I may try that. Right now the code is running without a boot loader and I think it's working. It'll take several days of testing in the sun to see for sure.

[JetForMe]

It would still be nice to be able to have custom linker scripts in the IDE.

[matthijskooijman]

It would still be nice to be able to have custom linker scripts in the IDE.

I think you can do something like this by making a derived core and adding the needed linker flags for this. I think you should be able to override compiler.c.elf.extra_flags= in boards.txt (it's not documented to be intended for that, but I expect it will work). If it doesn't, you might need a platform.txt with customized recipes to add the needed linker flags.

If that works, I think there is nothing that needs to be changed in this core? You'll need a custom board definition to trigger a linker script anyway. Or are you suggesting that the sketch can supply a linker script, rather than basing it on the board definition? I guess that could make sense, but I'm not sure where to begin implementing this (there's no way to say in platform.txt something like "If this_file exists, add -x {this_file}", for example).

[JetForMe]

Or are you suggesting that the sketch can supply a linker script, rather than basing it on the board definition? I guess that could make sense, but I'm not sure where to begin implementing this (there's no way to say in platform.txt something like "If this_file exists, add -x {this_file}", for example).

Yes, this is what I'm suggesting. The IDE already treats .ino files separately, I would imagine it could look for a .ld or <sketch>.ld file, and pass that during the link stage in lieu of whatever file the platform.txt file specifies.

[matthijskooijman]

Yeah, I guess that could work. That would require changes to the build process, though, so maybe this would then be better placed in the arduino-cli repository (which has the code that arduino-builder uses to do the actual build). It would also require changes to the platforms, I think. Also, one challenge is that a linker-script is very board-specific, so a sketch might need to supply multiple linker scripts if it is to be used with multiple boards, and a way for the builder to select the right one...