Not Compiled for this board

[defragster]

Setup : Win7 w/IDE_1.6.3 w/Teensy Loader 1.24-b2
> USB T3.1 - running a sketch
> USB LC - running sketch

Compile for LC

> Press T3.1 button : Opps!

Results in the : File Compatibility Error . . . not compiled for this board
> OK Dialog

> Press LC button
EXPECTED: Upload file

RESULT : LC goes offline like the T3.1. Repowered both - still not sure it was right - closed TeensyLoader and then the LC code transferred after another Verify.

It seems like the Loader gets into a Failed State and requires a special path to restart that is not the obvious path I chose. After the Dialog is OK I would expect the TLoader to reset to normal follow the button behavior. Maybe this is because the T3.1 is left stalled in program mode and TLoader stays there with it?

I should confirm this after posting - but I'm on another machine just now and this is what I saw that matches behavior I noted but did not BUG before.

 

[defragster]

Indeed - seeing now the 'state' is controlled by the Teensy in HID w/program mode - can it just be restarted after it was found to be wrongly interrupted?:
> LC running
> T3.1 running

IDE Verify T3.1
Button LC: Opps!

00:30:18: Incompatible file, showing warning dialog
00:30:18: HID/win32: HidD_GetPreparsedData ok, device still online
00:30:35: Verbose Info event

Button T3.1: IGNORED - but into Program of course

Close TeensyLoader :

>Verify
>Auto Mode Disabled - too much activity - because it hits ONE with program - then cascades to another.
[They are different devices - maybe I meant to do this - supposing I had multiple correct Teensy units online? If the device changes do you want to cancel AUTO?]

Both devices left in Program mode - so restarting TLoader makes it respond to the first it sees - it eventually works out - but not cleanly.

This isn't critical - but it isn't ideal? When you get a chance to look at it you should be able to see this and what else happens.

 

[PaulStoffregen]

Do you believe this could be explained by a lack of Teensy Loader detecting (and remembering) the appearance of new boards in bootloader mode while already talking with another one?

That's a known limitation, and one I intend to fix at some point. But this behavior might be any number of other things. There may also be some subtle timing issues in the communication between Arduino and the Teensy Loader. In fact, I'm sure there are.... I've just never managed to come up with a really reliable test case to reproduce the problem, and the severity is very low. Confusing and annoying, but it usually seems to work out, which has also put this low on my priority list. Still, I'd really like to fix it.

 

[defragster]

Do you believe this could be explained by a lack of Teensy Loader detecting (and remembering) the appearance of new boards in bootloader mode while already talking with another one?
... severity is very low. Confusing and annoying, but it usually seems to work out, which has also put this low on my priority list. Still, I'd really like to fix it.

Yes, seeing only the board at hand with no bigger picture of devices and ID's might allow fine tuning a way out of this. Without that then you are seeing a tree not the forest.

Since I'm jumping LC<>T3.1 for the timing issue I reported I can walk through this and maybe update. But it is low priority for sure - and I can see that a clean solution isn't easy as it appears.

It will either stick on the wrong one and not see the other 'button' unit - or try to put to the 'first one' - then immediately see the other one appear still in program mode.

As a quick fix if the Loader saw it couldn't put the given code on the processor at hand: It could issue a reboot to put it back in run mode. Of course there are times when this could start up a wheat thrasher and take of a kitten's tail - or some undesired side effect.