Teensyduino 1.42 Beta #4

Status
Not open for further replies.
KurtE :: Yes, it breaks TyCommander - I updated your ISSUE there.

Good work "Frank B" With TeensyLoader this works for me to get valid print. I should have tested with my MemFault sketch trapping _fault_isr's :(
The changes are to Boards.txt ::
teensy35.upload.maximum_data_size=262136
and to \hardware\teensy\avr\cores\teensy3\mk64fx512.ld ::
RAM (rwx) : ORIGIN = 0x1FFF0000, LENGTH = 262136
Click to expand...
 
The upload.maximum.data_size is questionable anyway, as it leaves no room for stack if really 100% are used.. what is it for? The size-tool?
I guess, tycommander relies on the stack position?
 
TyCommander finds and uses various 'known values' like that parsed from the HEX file to prevent uploading a given HEX to the wrong processor. Those 'known values' have to match the Teensy ID presented for programming to continue - only to known Teensy ID's. Also scanning for those values to be present is part of the HEX file validity test so corrupted HEX files <less likely to> pass.

<edit>: Koromix re-opened the Issue - made a code change - posted working TyComm update - and closed the Issue.
>> Upload works with working sketches on T_3.5.
Final build release depends on PJRC release.
 
Last edited:
An alternative way would be to just add a 1 Byte const to the code..perhaps after the 0x400 data. For example 32 for T3.2 or 36 for T36... it would be independend from other values, more clean.. and documented.. :)
 
I may be completely out of touch here so correct me if I'm wrong
For some reason I thought this version supported multiple teensy's connected to the same pc. So I tried that and came to some "unexpected behaviour".
I wanted to do the following setup in windows 10:
Run teensyduino 2 times. one for my teensy 3.1 and for for my teensy2++
Compile both then run upload in on and then upload in the second. This simply didn't work. The Teensy loader nearly always want to upload to the wrong board. It did succeed once but then it turned of automode due to to fast answer.
This may all be me just doing the wrong things, but if so a pointer to the right way would be appreciated.
When testing I noticed some strange behaviour that may be as designed but is not compliant with the Arduino way. (Edit: I stand corrected it is the Arduino IDE way :-s )
When I change the board from teensy2++ to teensy 3.1 (or the other way around) in one window all window instances are changed to this board. Arduino IDE has a boardsetup per window.
This probably did not help me in doing the right actions for uploading :-s
Best regards
Jantje
 
Each Teensy must have a separate IDE instance open, must not be of the same instance!
If you have 2 or more teensies with the same hardware version (3.5 and 3.5 for example), it's preferred to do COMPILE only in the IDE, and when compile is done, push the program button on the one you want programmed.

if all instances change at same time, you have only a single instance, not multiple, thats where the problem is.
On your taskbar, try clicking the Arduino icon
You should have 2 separate IDE windows open in taskbar, (NOT COMBINED), then it should work
 
@tontton81
Indeed that was part of the issue.
When starting 2 teensyduino's I could upload to the 3.1 but the upload to teensy2++ fails because it tries to upload to 3.1
I had to unplug the 3.1 (I also closed teensy loader) to get the upload to work
 

Attachments

  • teensyuploadfail.PNG
    teensyuploadfail.PNG
    238.5 KB · Views: 182
Strange, now it is working fine. It lookes like the teensyloader missed the teensy2++ at startup and did not recover.
 
I only have one loader open.
It seems to work but it is unstable. Sometimes I have to unplug the teensy that works so the teensy that didn't work starts working.
 
The correct 'Tools / Port' has to be selected in each IDE - and both should be one under the 'Teensy' section. That ideally lets the TLoader know where to send the code.
 
@defragster
That is what I do.
My test may seem simple but I'm kind of on the extreme with 12 arduino's connected at my system at the same time as I'm doing upload tests.
I see windows making a mess of the com ports (assigning the same com port to 2 different devices) and sometimes I see a teensy in bootloader mode in the teensyduino list.
My current understanding is that is works but it is unreliable in windows 10. unplugging the "working" teensy makes it work again.
 
Here you can see the bootloader issue I see quite often and the failure to teensy2++.
 

Attachments

  • teensy2pp_fails.jpg
    teensy2pp_fails.jpg
    160.8 KB · Views: 236
  • TeensyGettingTrying to upload3.1to2pp.jpg
    TeensyGettingTrying to upload3.1to2pp.jpg
    112.5 KB · Views: 191
Just checking - I usually use TyCommander for multi Teensy - but working to test this Beta TeensyPorts - so far it seems to work okay with 2 IDE's directed to a Selected Teensy.

<edit>
Going to TeensyLoader - "Help / Verbose Info" will show a log you can save to a text file to upload for Paul's review.
 
I think I was right when I stated :"I may be completely out of touch here so correct me if I'm wrong".
From the discussion here I learned that there is now a requirement to have the com port set correctly. IMHO not explicitly needed in this test case (2 different teensy types) but very needed when uploading to multiple teensies of the same type.
If you are working with teensyduino and do not mess with the com ports; teensyduino sets things right. Even if you upload a different sketch with a different usb type resulting in a different com port.
But...I messed with the com ports after the upload. And then things start going wrong. See image with strange port name.

I also added a image where you can not see the teensytype in the port list which added to my confusion.

@paul
May I suggest to change following in the error dialogue: "you must configure the correct board type" to "you must configure the correct board type and com port" and "to change the board configuration in the arduino IDE use tools->boards menu" to "Changing the board configuration in the arduino IDE using tools->boards menu will do so"
I also see the teensy loader now has a list functionality. is there some documentation on this?

Best regards
Jantje
 

Attachments

  • if you only have serial the teensy type is there.jpg
    if you only have serial the teensy type is there.jpg
    111.4 KB · Views: 209
  • teensy multi board upload problem 1.jpg
    teensy multi board upload problem 1.jpg
    101.6 KB · Views: 197
  • upload to wrong port.jpg
    upload to wrong port.jpg
    120.9 KB · Views: 260
@Defragster - I tried but failed to reproduce this problem.

defragster said:
My repro steps if not clear above - this is same as I stumbled into on B#3 as a secondary issue :
IDE #1 on T_LC - T_sermon open.

Open IDE #2 : Change to T_3.6, start compile on same sketch, during compile open T_sermon to T_3.6, compile completes and this is where I am.

T_Loader should tell T_sermon to drop the port again before programming?
Click to expand...

Here's a quick video to show the steps I tried. Maybe I misunderstood or click the wrong place or missed a step?

 
Just watched - good honest effort - I followed the steps and the TeensyPorts stayed Single too ???

Like yours [ I saw before too ] second JAVA instance for IDE is not in TaskMan. Hit Performance tab - then back to Processes and it is there.

T_LC was on USB3 Hub and T_3.6 was on front USB3 - before I had them both on same USB2 Hub - went back to that - closed and re-opened Teensy Ports - then opened T_sermon during compile and no Repro.

Though just one JAVA IDE App process again until tab change/return.

Not sure what changed - it was so consistent before. Back on old trusty USB2 hub ...

Closed IDE's and redid it and and all functional - and the Tools menu is fast and responsive - no 8 second delay.

Machine has been up 7.58 days - and I've done more than a few uploads - using TyComm just before this with one or more Teensy's.
 
Ok, I'm going to take this off my list for beta5. I'm sure there's still some work needed to deal with this, but without a way to reproduce it there's not much I can do right now. Will look at the teensy_ports Windows code next week, after Maker Faire.
 
Jantje said:
May I suggest to change following in the error dialogue: "you must configure the correct board type" to "you must configure the correct board type and com port" and "to change the board configuration in the arduino IDE use tools->boards menu" to "Changing the board configuration in the arduino IDE using tools->boards menu will do so"
Click to expand...

Sounds good. I'm putting this into beta5, except for "com" which is Windows specific. This message is the same for all 3 systems. Hopefully just "port" will do?
 
defragster said:
Not sure what changed - it was so consistent before.
Click to expand...

I'm adding some extra verbose printing in the Windows version of teensy_ports for beta5. If you see multiple instances again, open a command prompt and run "teensy_ports -v". It will print extra info as it does the multiple instance check.

My guess is perhaps GetTcpTable() is failing. Then there's no way to know whether any program is listening on the 3 possible localhost ports. The only way to check is attempting to connect. Windows is incredibly slow about returning an error when you try to connect to a localhost port where no program is listening. It takes about 1 second, even though it's all just local stuff on your PC which doesn't involve any real network communication! But I still can't understand why you'd experience an 8 second delay. I have a list of 3 ports to try. But if another instance is running, it should connect quickly... so I'm really at a loss to guess how you're getting multiple instances and a long delay on the ports menu.

If it happens again, maybe this extra stuff by running "teensy_ports -v" in a command prompt might help shine some light on the situation.
 
Status
Not open for further replies.
Back
Top