I think Arduino IDE V2.3.2 causing problems may need to downgrade to Arduino 1.8.19?

What about 1.58? The reason I ask is.

1.57->1.58 changed the toolchain
Code: 
Updated toolchain to gcc 11.3.1 for Teensy LC, 3.x, 4.x
Update core library for gcc 11.3.1
Update Wire library for gcc 11.3.1
Update teensy_size for gcc 11.3.1

Then from 1.58->1.59 changed from ++14 to ++17
Code: 
C++17 used for Teensy 3.x and 4.x
Enable LTO options in Arduino Tools > Optimization menu
Fix startup for LTO optimization

So wondering which one impacted you.
With the 1.8.19 you might be able to emulate 1.58 by editing boards.txt
Code: 
teensy41.build.flags.cpp=-std=gnu++17 -fno-exceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -Wno-psabi

And see if it makes differences (17 to 14)
 
If you want to continue trying to narrow it down, obviously the next step is to try 1.58.

Then using Arduino 1.8.19, you can try all the beta version between 1.57 and 1.58, or between 1.58 to 1.59. Just look at the list of thread on the Announcements forum to find all those beta versions. None are still published for Arduino 2.x.x, but all the installers for Arduino 1.8.19 are still downloadable (they do eventually get deleted, but less frequently since PJRC upgraded a few years ago to website hosting with more storage space).

Each individual beta shows the list of changes, so when you do narrow it down to the specific beta where things broke, maybe that info will yield something more useful than just knowing it was between the huge range of 1.57 to 1.59.

But if I were to guess, 1.58-beta1 was where we updated the gcc toolchain from gcc 5.4.1 to gcc 11.3.1. C++ dialect was intentionally kept at C++14 (despite several people really wanting the jump to C++17) until the betas for 1.58, because I was wary of changing too much at once.

Even when you do manage to narrow the search to the specific beta release which broke your program, and especially if it's 1.58-beta1, odds of learning exactly why are still pretty slim without showing code to reproduce the problem. But if you're not able to show the code (or if it's huge) at least just trying the various versions is relatively simple and might yield at least a little info.
 
I should also mention, the toolchain change broke some people's programs which depended on the old constexpr behavior for Wire, SPI, and HardwareSerial. If you used any of those within a C++ construtor, there was a good chance your program would crash if your constructor happened to run before the constructor for the SPI, Wire or Serial{N} port you constructor tried to use. Such programs always worked with gcc 5.4.1 because a constexpr constructor cause the instance to be fully static initialized (which apparently isn't technically guaranteed with anything in C++14 or C++17 specs... but that's how the old toolchain worked and how Wire, SPI, HardwareSerial were written for gcc 5.4.1).

That's a possible but unlikely explanation, because in the 1.59 betas quite a bit of work went into those libraries to restore the old const init. If your program crashes still with 1.59 and 1.60-beta1 that's an unliiely explanation. But it could be possible something (2 or more C++ classes) within your program has the same issue, depending on the old gcc 5.4.1 constexpr behavior. I think that might be what @jmarsh was trying to ask with the question in msg #21.

But this is all just guesswork. Without seeing the code, and more importantly without a way to reproduce the problem, we're probably not going to do much better than guessing here. But who knows, sometimes we do manage to figure out problems on this forum by blind gueses.
 
Right, I don't think this has anything at all to do with the OTA updating part - I suspect any build made with the newer GCC is broken no matter how it gets installed onto the Teensy (due to a static initialization order problem). The source code and all the libraries involved are too big for me to comb through.
 
paynterf said:
Arduino 1.8.19 with Teensyduino 1.57 - works OK
Arduino 1.8.19 with Teensyduino 1.59 - Hangs
Arduino 1.8.19 with Teensyduino 1.60b1 - Hangs.
Arduino 1.8.19 after reverting back to Teensyduino 1.57 - works OK
Click to expand...
Since it is hanging and not doing the 8 second CrashReport Restart that won't help point out where it is dying.
Are the HANGS before setup() {pinmode and blink a pin/LED on entry with a delay} Or does it hang somewhere into setup() or beyond?
Can middle or late startup HOOK manage and {pinmode and blink a pin/LED on entry with a delay}

Most likely it seems that it is early and that won't help but confirm the C/c++ init stuff is the issue ... unless it passes that.

Maybe already asked/answered/posted: No build verbose warnings? What does the build TAIL look like with regard to 'Libraries Used' showing the source locations and also the code memory info.

And for sure add 1.58 to the matrix given the tools evolution.
 
Since I don't use FlasherX for anything (yet) I would suggest you break down problem into a couple manageable tasks.
1. Using OTA try flashing a simple program like Blink or other simple sketch. Like Printing hello world to Serial monitor.
2. If that is working try running an example sketch from the I2Cdev lib for the MPU you are using? Its been a while since I tried using that lib.

Just a suggestion.
 
jmarsh said:
Right, I don't think this has anything at all to do with the OTA updating part - I suspect any build made with the newer GCC is broken no matter how it gets installed onto the Teensy (due to a static initialization order problem). The source code and all the libraries involved are too big for me to comb through.
Click to expand...
As I mentioned in my original post on this subject, uploads via USB are fine:

"However, I have found that when I do an OTA update from my new PC to my Teensy 3.5, the program hangs on a call to the MPU6050 6DOF IMH library code. If I do an OTA update of the same firmware from my old PC everything works fine Moreover, If I do a USB upload of the same code to my Teensy 3.5 robot using either PC, everything works fine, including all the calls to the MPU6050 library code."
 
Hey guys, as I noted in the reply above, I only see this problem when the firmware is uploaded to my robot via OTA - Everything works fine when I upload/run using a physical USB connection.

The only difference between the two methods is that the direct USB connection method doesn't run any of the OTA code, while the OTA method obviously does. So, I'm wondering if it wouldn't be worthwhile to taking a look at my implementation of Joe's OTA code? I uploaded my entire .INO file earlier, but here it is again.
 

Attachments

  • WallE3_Git.zip
    66.5 KB · Views: 56
As @defragster mentioned, in other posts it would help to see things like the build summary to know which libraries including
version and the like that was used.

as @mjs513 mentioned, if it were me, I would try starting with simple program, make sure that it works.
Then try a simple example using the MPU6050 library you are using including which actual sub-class you are using and
see if some simple call fails...

Are they called during construction of the objects or later either in setup or main?
I would the instrument the code some. For example, if it is calling with some method, I would of do lots of prints
of the internals, print out the wireObj pointer and check for NULL...
I would probably hex dump the pointer, to get an idea if the first words like like pointer to VTABLE, etc.
After each group of Serial.print... I would call Serial.flush(). As I have chased several things in the past to find out, the code went a lot
farther, but the prints were not output...

Sometimes if the death in the code is really early in the process, I would enable the core debug code:
core\teensy4\debug\printf.h and uncomment the line //#define PRINT_DEBUG_STUFF

This will early on initialize Serial4 object to output at 115200. I use some USB to Serial adapter. to Serial4
And then you can use printf (or printf_debug ) to output stuff to Serial4...

This has helped in past if for example order of constructors is the issue. I found for example cases where
the constructors of dependent objects was not done yet, including ones that
had things like: my_constructor : _hardware(my_hardware), _spi(my_spi) {...}
where neither _hardware nor _spi were initialized (null in the case)... And code assumed they were set...

Good luck
 
paynterf said:
Hey guys, as I noted in the reply above, I only see this problem when the firmware is uploaded to my robot via OTA - Everything works fine when I upload/run using a physical USB connection.
Click to expand...
The point of the my comment was:
1. Determine if the issue with OTA updates with a simple sketch to try and isolate the issue with 1.57 and 1.59 to the Teensy 3.5
and
2. If OTA is working then have to see if the issue might be with I2C dev/MPU6050 library with the new compiler. If a test sketch works with uploaded via Serial to both 1.57 and 1.59.

If both work then there is an issue with OTA (not via serial) with 1.59 - some conflict when using the new compiler.
 
mjs513 said:
Determine if the issue with OTA updates
Click to expand...
I didn't read enough to see the problem came from OTA usage.
If normal PRJC bootloader over USB works with the same code then something as @mjs513 ponders is going astray with the OTA usage.
@KurtE makes a good point with PRINT_DEBUG_STUFF maybe showing early feedback on startup/resetHandler code progress.

OTA seems cool and good to see it can work - but not tried it. Many common T_4.x's on the desk here are LOCKED and wasn't sure if that worked on them? Not seen notes on OTA failing for others that have been using it and 1.58 & 1.59 have been around for some time now. So perhaps there is something unique in the @paynterf code WRT OTA ... so a simple blink like p#35 item #1 would confirm basic function.
 
paynterf said:
As I mentioned in my original post on this subject, uploads via USB are fine:

"However, I have found that when I do an OTA update from my new PC to my Teensy 3.5, the program hangs on a call to the MPU6050 6DOF IMH library code. If I do an OTA update of the same firmware from my old PC everything works fine Moreover, If I do a USB upload of the same code to my Teensy 3.5 robot using either PC, everything works fine, including all the calls to the MPU6050 library code."
Click to expand...
The reason I'm discounting this is because the OTA process should have nothing at all to do with the build tools/copy of Teensyduino installed on the host PC that is doing the sending.
If the exact same firmware works when sent from one machine but not the other then the firmware isn't bugged - something in the sending process must be different. Which Teensyduino has nothing to do with, unless you've neglected to mention a very important detail that another Teensy is somehow being used to send the firmware from the host PC.

So instead, I am assuming the bold statement in your quote is inaccurate and the same firmware is not being uploaded by both PCs, but rather the same source code is being compiled and sent by both PCs. The actual resulting HEX files (the firmware) being uploaded would be very different due to the different compilers installed.
 
jmarsh said:
So instead, I am assuming the bold statement in your quote is inaccurate and the same firmware is not being uploaded by both PCs, but rather the same source code is being compiled and sent by both PCs. The actual resulting HEX files (the firmware) being uploaded would be very different due to the different compilers installed.
Click to expand...
Have you verified that you are using the same source files on both machines? That is for example you are using the same version of each of
the libraries and that there were no local changes made to any of these libraries.

Example: Assuming you are using the MPU6050 library. This library (at least on my machine) has the files I2Cdev.h and .cpp.
the .h file controls what code you are using to do I2C...
Code: 
// -----------------------------------------------------------------------------
// I2C interface implementation setting
// -----------------------------------------------------------------------------
#ifndef I2CDEV_IMPLEMENTATION
#define I2CDEV_IMPLEMENTATION       I2CDEV_ARDUINO_WIRE
//#define I2CDEV_IMPLEMENTATION       I2CDEV_TEENSY_3X_WIRE
//#define I2CDEV_IMPLEMENTATION       I2CDEV_BUILTIN_SBWIRE
//#define I2CDEV_IMPLEMENTATION       I2CDEV_BUILTIN_FASTWIRE
#endif // I2CDEV_IMPLEMENTATION
Is yours configured to use the Wire library? Or maybe it was changed to use the i2c_t3.h ?

paynterf said:
"However, I have found that when I do an OTA update from my new PC to my Teensy 3.5, the program hangs on a call to the MPU6050 6DOF
Click to expand...
Is there a specific call to it that hangs? Or any?
Does it hang only after the OTA update? Or does it also hang if you then power cycle it after the OTA update?

Are you building with the options to show all warnings? Are there any warnings? Does the list of libraries used as shown in
the summary at the end of a build match between the two machines...

Beyond that, hard to say, without going through some of the debug steps mentioned earlier. There are still lots of possibilities
of what might be going wrong.

a) C++ objects constructor order issues mentioned earlier.
b) Overflowing an array or the like.
c) Using uninitialized memory. Maybe when it loads from USB some variable is zero but when loaded from OTA it has garbage.
d) Maybe Stack overflow? That is maybe there is a code path where the stack grows down into other variables.
...

Addition to my earlier possible enable the core debug. I have had a couple of times where a hang ore set happens where Crashreport does
not report it... I was able to get some information, by adding some code into the unused_interrupt_vector (startup.c), that use the
debug prints to print out some of the same information that CrashReport captures. For example if you have code that does something like
memset(x, 0, -1); the -1 is taken as a very large number and it tried to zero out everything...
 
The source code and all the libraries on both PC's is identical, as I copied it all from my older PC to my newer one.

I believe the 'bad' (OTA) code hangs in the same place after a power cycle.

Early on in this thread I posted hex files from 'good' and 'bad' configurations. Obviously they are different, as otherwise we wouldn't be having this conversation.
PaulStoffregen said:
If you want to continue trying to narrow it down, obviously the next step is to try 1.58.

Then using Arduino 1.8.19, you can try all the beta version between 1.57 and 1.58, or between 1.58 to 1.59. Just look at the list of thread on the Announcements forum to find all those beta versions. None are still published for Arduino 2.x.x, but all the installers for Arduino 1.8.19 are still downloadable (they do eventually get deleted, but less frequently since PJRC upgraded a few years ago to website hosting with more storage space).

Each individual beta shows the list of changes, so when you do narrow it down to the specific beta where things broke, maybe that info will yield something more useful than just knowing it was between the huge range of 1.57 to 1.59.

But if I were to guess, 1.58-beta1 was where we updated the gcc toolchain from gcc 5.4.1 to gcc 11.3.1. C++ dialect was intentionally kept at C++14 (despite several people really wanting the jump to C++17) until the betas for 1.58, because I was wary of changing too much at once.

Even when you do manage to narrow the search to the specific beta release which broke your program, and especially if it's 1.58-beta1, odds of learning exactly why are still pretty slim without showing code to reproduce the problem. But if you're not able to show the code (or if it's huge) at least just trying the various versions is relatively simple and might yield at least a little info.
Click to expand...
Paul,

I managed to overwrite my copy of V1.57 for Arduino 1.8.19 with 1.58b1, and now I'm having trouble finding 1.57. The https://www.pjrc.com/teensy/td_download.html link seems to point to 1.59. and your announcements thread points to https://www.pjrc.com/teensy/td_download.html. Can you provide a current link?

FWIW, it appears 1.58b1 works OK (subject to confirmation when I can get back to 1.57). I have also attached the verbose compile output for the 1.58b1 configuration (I use VS2022 Community Edition and Visual Micro if that makes a difference)

TIA,

Frank
 

Attachments

  • 1p58b1CompileOutput.txt
    240.9 KB · Views: 58
Your output report has lots of stuff in it :D But not some of the more interesting stuff that, But not sure if all of the stuff that Arduino builds would give you. Been awhile since I did many Teensy 3.x builds.

Code: 
Using library MPU6050 version 0.0.0 by Legacy in folder "C:\Users\Frank\Documents\Arduino\libraries\MPU6050"
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050.cpp.o
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050_6Axis_MotionApps20.cpp.o
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050_6Axis_MotionApps612.cpp.o
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050_9Axis_MotionApps41.cpp.o


Using library I2Cdev version 0.0.0 by Legacy in folder "C:\Users\Frank\Documents\Arduino\libraries\I2Cdev"
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\I2Cdev\I2Cdev.cpp.o


Using library I2C_Anything version 0.0.0 by Legacy in folder "C:\Users\Frank\Documents\Arduino\libraries\I2C_Anything"

Hard to tell what many of these libraries are. I am assuming legacy implies that no library properties exist.

The MPU6050 I downloaded some time ago has one and shows a version number:
Code: 
name=MPU6050
version=1.3.1
author=Electronic Cats
maintainer=Electronic Cats <store@electroniccats.com>
sentence=MPU6050 Arduino Library.
paragraph=MPU-6050 6-axis accelerometer/gyroscope Arduino Library.
category=Sensors
url=https://github.com/electroniccats/mpu6050
architectures=avr,samd,sam,esp8266,esp32,stm32,renesas,renesas_portenta,renesas_uno
includes=MPU6050.h
That library also has in it: I2Cdev.h/cpp - I don't see any installs in the library manager for this, so not sure if you downloaded this library or some other, and if so which version?

I2C_Anything - again no idea what this is? Is it used by your MPU6050? Or maybe something else?

Sorry probably not much help
 
KurtE said:
Your output report has lots of stuff in it :D But not some of the more interesting stuff that, But not sure if all of the stuff that Arduino builds would give you. Been awhile since I did many Teensy 3.x builds.

Code: 
Using library MPU6050 version 0.0.0 by Legacy in folder "C:\Users\Frank\Documents\Arduino\libraries\MPU6050"
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050.cpp.o
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050_6Axis_MotionApps20.cpp.o
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050_6Axis_MotionApps612.cpp.o
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050_9Axis_MotionApps41.cpp.o


Using library I2Cdev version 0.0.0 by Legacy in folder "C:\Users\Frank\Documents\Arduino\libraries\I2Cdev"
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\I2Cdev\I2Cdev.cpp.o


Using library I2C_Anything version 0.0.0 by Legacy in folder "C:\Users\Frank\Documents\Arduino\libraries\I2C_Anything"

Hard to tell what many of these libraries are. I am assuming legacy implies that no library properties exist.

The MPU6050 I downloaded some time ago has one and shows a version number:
Code: 
name=MPU6050
version=1.3.1
author=Electronic Cats
maintainer=Electronic Cats <store@electroniccats.com>
sentence=MPU6050 Arduino Library.
paragraph=MPU-6050 6-axis accelerometer/gyroscope Arduino Library.
category=Sensors
url=https://github.com/electroniccats/mpu6050
architectures=avr,samd,sam,esp8266,esp32,stm32,renesas,renesas_portenta,renesas_uno
includes=MPU6050.h
That library also has in it: I2Cdev.h/cpp - I don't see any installs in the library manager for this, so not sure if you downloaded this library or some other, and if so which version?

I2C_Anything - again no idea what this is? Is it used by your MPU6050? Or maybe something else?

Sorry probably not much help
Click to expand...
Yeah, my robot project is fairly complicated, at least for me; that's kinda why I didn't think a 'verbose' output would be much help ;)
 
paynterf said:
Yeah, my robot project is fairly complicated, at least for me; that's kinda why I didn't think a 'verbose' output would be much help ;)
Click to expand...
It is and isn't... Like seeing a complete listing of the boards.txt and platform.txt is not overly interesting, although can help some
Like I saw it was c++14...

However, some of the most related stuff, there is very little information, like I mentioned in the previous post (as well as before). Like
exact libraries are you using? Including which version of them... Are they modified in any way? Without details like this it is
very little any of us can try to help.

Looks like maybe it is setup to show all build warnings, however we are not seeing them, as it is not building them. Example:
Code: 
Using library MPU6050 version 0.0.0 by Legacy in folder "C:\Users\Frank\Documents\Arduino\libraries\MPU6050"
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050.cpp.o
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050_6Axis_MotionApps20.cpp.o
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050_6Axis_MotionApps612.cpp.o
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050_9Axis_MotionApps41.cpp.o
Try to do some form of clean build. I have not done any builds using VisualMicro for a long time, so I don't know the easiest way
to do that. (I don't remember if they have something like build clean). With Arduino IDE. Couple of different ways.
Change one of the basic build options, like speed, or optimizations or board...

Or what I often do, is wipe out their cache: (cd to %temp%\arduino) on windows, not sure on Linux or MAC and
clear out that directory. ...

And then build again. then look carefully at all warning messages. Often times there are hints in them.
 
paynterf said:
I managed to overwrite my copy of V1.57 for Arduino 1.8.19 with 1.58b1, and now I'm having trouble finding 1.57.
Click to expand...

The installers are all still on the server. Just right click to copy the download URL, then paste in your browser address bar, but before you press Enter edit the 3 digit number for the version. Likewise for the beta installers, or you could find the links in the old threads on the Announcements forum.

With installing to Arduino 1.8.19, please be aware the installer writes "on top of" the previously installed version. The non-beta installers will check the version and refuse to downgrade, because older installers aren't made with any knowledge of what future ones will install.

But for the sake of troubleshooting, since you are trying to pin down where problems began, I'd recommend re-running the Arduino 1.8.19 installer before each Teensyduino installer. The Arduino installer will fully delete the previously installed copy. Then you'll end up with a fresh copy of Arduino 1.8.19 without any Teensy stuff. For troubleshooting, starting with a clean Arduino slate is a much better way to investigate what each individual installer does.

Narrowing down which specific beta version started the problem may give some insight. But it won't be anywhere near as good as creating a small and simple version of your application which reproduce the problem. Would it really be too much to just try deleting large sections of your program and check that the problem still happens? If you can whittle it down to a fairly small size, I'm pretty sure that will be the most effective way really start all of us on the path that will ultimately find and fix the problem.
 
"creating a small and simple version of your application which reproduce the problem"

Try this one - I was able to get it down to about 1/2 the size of the original. The 'hang' condition is still the same, but the 'run' condition is a simple continuous list of MPU6050 headings. I believe all the needed files are present to compile and run this (I use VS2022 CE and Visual Micro), but if you also wish to actually do OTA transfers you will need teraterm as well. Of course you will need a MPU6050 and an RF link of some kind (I use a pair of Pololu Wixels) for actual OTA transfers

If you wish to do program uploads w/o OTA using a USB connection, you will need to remove or rename 'board.txt' (I generally just rename it to 'noboard.txt').

Even my 'small and simple' program ZIP file is too big to attach here. Instead I have provided a link to the ZIP file on my Google Drive site. Let me know if this helps.

Frank
 
To force a New Full compile, select a different Teensy and start compilation...stop compilation after a few seconds.
Revert back to the original Teensy and compile.
Changing the Teensy Device forces a clean up of previously compiled code.
Alternatively you could just clean out your temp folder using a batch file.
Below is the file that I use.
Code: 
del /F /S /Q C:\Users\%username%\AppData\Local\Temp\*.*
pause
 
KurtE said:
It is and isn't... Like seeing a complete listing of the boards.txt and platform.txt is not overly interesting, although can help some
Like I saw it was c++14...

However, some of the most related stuff, there is very little information, like I mentioned in the previous post (as well as before). Like
exact libraries are you using? Including which version of them... Are they modified in any way? Without details like this it is
very little any of us can try to help.

Looks like maybe it is setup to show all build warnings, however we are not seeing them, as it is not building them. Example:
Code: 
Using library MPU6050 version 0.0.0 by Legacy in folder "C:\Users\Frank\Documents\Arduino\libraries\MPU6050"
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050.cpp.o
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050_6Axis_MotionApps20.cpp.o
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050_6Axis_MotionApps612.cpp.o
  Using previously compiled file: C:\Users\Frank\AppData\Local\Temp\VMBuilds\WallE3_Git\teensy35\Release\MPU6050\MPU6050_9Axis_MotionApps41.cpp.o
Try to do some form of clean build. I have not done any builds using VisualMicro for a long time, so I don't know the easiest way
to do that. (I don't remember if they have something like build clean). With Arduino IDE. Couple of different ways.
Change one of the basic build options, like speed, or optimizations or board...

Or what I often do, is wipe out their cache: (cd to %temp%\arduino) on windows, not sure on Linux or MAC and
clear out that directory. ...

And then build again. then look carefully at all warning messages. Often times there are hints in them.
Click to expand...
VS2022/VM has a 'build clean' function. I generally have warnings enabled, and almost never leave any warnings open. There is an exception to that in that Joe's OTA code produces some warnings that I am unable/unwilling to address.
 
A new install of Arduino 1.8.19 and a new install of Teensyduino 1.58b4 hangs after an OTA transfer to 'Teensy_Hang_Demo.ino'

So the problematic change occurred somewhere between 1.58b1 (works) and 1.58b4 (hangs).

Frank
 
You must log in or register to reply here.
Back
Top