I get a verification error, but no idea what the error is (this is the entire message):
/usr/local/bin/arduino-cli compile --fqbn arduino:samd:nano_33_iot --build-cache-path /tmp --output-dir /tmp/2585403139/build --build-path /tmp/arduino-build-D0DA412BA6AD405BD81C5752A9AD7460 /tmp/2585403139/Alexa_controller_jan20
[info] Sketch uses 102140 bytes (38%) of program storage space. Maximum is 262144 bytes.
[info] Global variables use 8272 bytes (25%) of dynamic memory, leaving 24496 bytes for local variables. Maximum is 32768 bytes.
/home/builder/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/7-2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .bss by 4 bytes
/home/builder/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/7-2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .bss by 4 bytes
/home/builder/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/7-2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .bss by 4 bytes
/home/builder/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/7-2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .bss by 4 bytes
/home/builder/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/7-2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .bss by 4 bytes
The microcontroller wants chunks of executable machine code to line up with its Flash memory address space.. shifting things so every command occupies the last byte of one 32-bit word and the first three bytes of the next would cause huge-but-simple, slow, and annoying problems for the ALU, so the chip designers just said, "don't do that."
The warning is telling you that the most recent chunk of executable code it compiled doesn't end at one of those boundaries, so it can't store the next chunk at the next available byte address. It had to throw in 4 bytes of padding to make things line up properly for the next chunk.
Strictly speaking, that can be a problem for programmers digging around in the machine code if they just have a list of 'this chunk fills this many bytes' and are trying to interpret memory addresses in the code. It also means you can't use exactly 100% of the available memory, and there's someone willing and ready to complain about any numerical difference, no matter how small. Overall, it's a condition worth mentioning as the linker goes through packing code into memory.
Functionally it's 100% harmless, and the only way to avoid it is to write code that compiles to exactly the right size for the memory.. nearly impossible, and far more effort than it's worth.
So you can safely ignore the warnings. If you aren't experiencing any problems with your project, then just carry on. If you are experiencing some problem, it is most likely completely unrelated to the warnings.
Thanks very much. I had added a few characters to a string, so I knew it wasn't a missing semicolon or some such. I'm going to experiment with my constant strings and see how the warnings change.
I removed all the added text and the code still will not verify. The warnings are identical. The sketch will not upload, so whatever is irritating the compiler, it's a real error, not just a warning. I haven't modified or uploaded this sketch since Oct 2020. Has something changed? This code is pretty simple, no interrupts, nothing but signing on to the wifi and doing some serial communications on both UARTS (serial0 does normal debug messaging and serial1 communicates with my light controller system).
I had the same warning in Jan 2020, but it didn't prevent uploading the sketch, which ran fine. Back then there was only one warning, now there are five (identical). I turned on "verbose" and got hundreds of lines of output, but did not find "error", "notfound", or "missing" in the compiler output.
I'm confident the upload failure is completely unrelated to the warnings. They are only acting as a "red herring".
Congratulations on finding the cause of the problem! I'm glad it is working now. Thank you for taking the time to post an update with your solution.
If you later decide to give the "new" Cloud Editor another try and still encounter the upload failure, I would be happy to do some further investigation to try to find the cause.