-
-
Notifications
You must be signed in to change notification settings - Fork 403
Caching of core build may get out of sync when doing multiple windows causing build to fail. #2144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Just to add on to what @KurtE said there were a couple of things that I noticed with my testing (used 2 different sketches than what Kurt used though.
and and
To resolve the issue I have to clean out the cores in temp or erase all the temp files |
@per1234 and all - I am actually wondering if this is a more generic issue/question? That is what actually controls when the core gets rebuilt or not? This could be a pretty important issue. On it maybe being a more generic issue: I built a simple hello world sketch and ran an upload on it with the default settings 120mhz speed. I then changed the CPU speed to 150mhz and tried a new build:
And it uploaded and the like, but as you can see it said: Using precompiled core: Note: I am currently using 0403 build, have not updated to today's nightly build as I don't see anything new in the log EDIT: @mjs513 has also verified today, that this issue does not reproduce (at least the teensy version) on the 2.0.4 release. |
Hi, |
Confirmed the problem occurs with arduino-ide_nightly-20230403_Linux_64bit. This is a simple test program to easily reproduce the error, using Teensy 4.0 or Teensy 4.1. elapsedMillis timeout;
void setup() {
pinMode(13, OUTPUT);
Serial.begin(9600);
Serial.print("begin loop speed test, F_CPU = ");
Serial.println(F_CPU);
timeout = 0;
}
void loop() {
static unsigned int loopcount = 0;
loopcount++;
digitalToggleFast(13); // measure pin 13 frequency
if (timeout >= 1000) {
timeout = 0;
Serial.print("loop/sec = ");
Serial.println(loopcount);
loopcount = 0;
}
} To observe the problem, first upload with default settings and open the serial monitor to see F_CPU and the measured speed of loop(). Then click Tools > CPU Speed to switch from 600 MHz to only 150 MHz. Upload again and click the serial monitor tab. You will see the sketch prints the new F_CPU number, but the core library is still compiled with the prior F_CPU setting so the hardware really is running at 600 MHz. The actual measured speed does not change. By comparison, if this same test is performed with IDE 2.0.4, you can see the F_CPU setting really does take effect and the loop speed is reduced by 4X. The speed change can also be observed by an oscilloscope or frequency counter connected to pin 13, or a current meter measuring the power consumption. These tests were done with Teensy package 0.59.2 installed. The problem is reproducible with 1.58.0 or other versions, though the actual numbers printed will differ because code for yield() changed between different versions. |
I think it is link to the cli 0.32.x. Our CI failed with this version because cache is not updated when fqbn with options change. Using |
@KurtE @PaulStoffregen @fpistm @mjs513 I'm going to make a patch release of the CLI |
Describe the problem
Over the last few weeks, I have had several occasions when a build will fail, typically in the link phase. Where at least in the cases I have reproduced a few times today and yesterday, they have been caused by the build system failing to realize that it needs to rebuild the core library and instead uses the previous build, which as built with different options. Most specially the USB Type is different between the previous build and the new build.
I have been able to resolve the problem, by clearing out the temp directory. And I know there have been several other people who have posted up on Arduino (and Teensy) forums about running into issues like this. Mostly Teensy users, although I sort of thought there were some other users ESP32? that I thought were asking for a cleanup command or the like, to resolve when they had some issue...
On my current failure, the previous build I did on another sketch in a different window was to build that sketch for USB type of: Serial + MTP. After that completed, I went back over to the window which I wanted to build using USB type: Tripple Serial. which was what I last compiled with in that window.
I reselected the triple serial, and then issued the upload command:
During the compile phase, I verbose output shows:
Nothing in core is rebuilt, so then during link:
It fails, as the core build does not include any of the code needed to support triple serial.
Note: the choice of which two USB types is not that important, other than the sketches have something in them that references the USB type functionality. Earlier I had failures with MIDI...
Not sure if this happened iwth current reelases like 2.0.4 or not, but I don't remember hitting anything like that since IDE 2 was still in beta.
Note: another user @mjs513 was also able to reproduce this with the steps I am mentioning below.
To reproduce
Have two (or more sketch windows open), where the two sketches want different USB types.
In my current case: I have an MTP sketch, in this case I am using a sketch I have up at:
https://github.com/KurtE/mtp_tft_picture_view
Which displays images off of an SD card onto a TFT like display. Can be configured for several different display types. Currently it is setup for RA8876
The second sketch I am using. Again I don't think anything specific.
USBtoSerialMulti-230403a.zip
But included to be complete. This sketch is based off of the Teensy USB Serial example that turns a teensy into a USB to Serial adapter. This one is extended that if you choose USB Type of DualSerial it will forward Two UARTS to two logical USB ports and if you choose triple Serial 3...
In each of these windows choose the same USB port of your Teensy. I am currently building for Teensy 4.1 And select the correct USB type and upload the to the Teensy. Then go to the other window make sure it has the correct USB type for the sketch and try the upload. Sometimes it will fail here. Other times go back to the first window, make sure it has the correct usb type selected and try upload again.
Expected behavior
Expect it to rebuild the core when it detects that one or more FQBN like setting change. Probably if any setting changes.
It is almost like it is caching what the core is built for in each window and not what the last actual build was for it.
Arduino IDE version
nightly-20230403
Operating system
Windows
Operating system version
11
Additional context
I have posted about this in the Arduino Thread:
https://forum.arduino.cc/t/teensy-compile-sketch-fails-clear-out-temp-build-completes/1110104
Also up on the Teensy thread: https://forum.pjrc.com/threads/72523-Teensyduino-1-59-Beta-1?p=323529&viewfull=1#post323529
And there have been other reports of strange things happening where clearing out temp fixes it.
Guessing probably arduino-cli issue, but my reproduce steps are IDE, so opened here.
Edit: and I also doun't know if it would reproduce as maybe when you run the CLI each time, it would complete the process and probably update everythings state, where maybe as IDE, the process may contain information per window and that data becomes out of sync.
Issue checklist
The text was updated successfully, but these errors were encountered: