Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 50 of 50

Thread: Teensyduino 1.42 Beta #4

  1. #26
    Works for me, thanks much.

  2. #27
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,466
    No problem, it was fun to look for the bug.

  3. #28
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,638
    Quote Originally Posted by Frank B View Post
    Fix: https://github.com/PaulStoffregen/cores/pull/278
    Ram-length / end needs to be 8-byte aligned.

    Edit:
    Remember to edit boards.txt:

    teensy35.upload.maximum_data_size=262136
    FYI - This change will break TyCommander again

  4. #29
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,777
    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

  5. #30
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,466
    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?

  6. #31
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,777
    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 by defragster; 05-14-2018 at 09:03 PM.

  7. #32
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,171
    Quote Originally Posted by defragster View Post
    TyCommander finds and uses various 'known values' like that parsed from the HEX file to prevent uploading a given HEX to the wrong processor.
    Teensy Loader does this too.

  8. #33
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,466
    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..

  9. #34
    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

  10. #35
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,712
    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

  11. #36
    @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
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	teensyuploadfail.PNG 
Views:	17 
Size:	238.5 KB 
ID:	13804  

  12. #37
    Strange, now it is working fine. It lookes like the teensyloader missed the teensy2++ at startup and did not recover.

  13. #38
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,712
    theres only one loader open for all IDE instances
    don't open more than 1 loader, the IDE shouldnt

  14. #39
    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.

  15. #40
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,777
    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.

  16. #41
    @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.

  17. #42
    Here you can see the bootloader issue I see quite often and the failure to teensy2++.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	teensy2pp_fails.jpg 
Views:	21 
Size:	160.8 KB 
ID:	13807   Click image for larger version. 

Name:	TeensyGettingTrying to upload3.1to2pp.jpg 
Views:	15 
Size:	112.5 KB 
ID:	13808  


  18. #43
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,777
    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.

  19. #44
    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
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	if you only have serial the teensy type is there.jpg 
Views:	17 
Size:	111.4 KB 
ID:	13814   Click image for larger version. 

Name:	teensy multi board upload problem 1.jpg 
Views:	21 
Size:	101.6 KB 
ID:	13815  

    Click image for larger version. 

Name:	upload to wrong port.jpg 
Views:	21 
Size:	120.9 KB 
ID:	13816  

  20. #45
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,171
    @Defragster - I tried but failed to reproduce this problem.

    Quote Originally Posted by defragster View Post
    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?
    Here's a quick video to show the steps I tried. Maybe I misunderstood or click the wrong place or missed a step?


  21. #46
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,777
    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.

  22. #47
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,171
    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.

  23. #48
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,171
    Quote Originally Posted by Jantje View Post
    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"
    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?

  24. #49
    Hopefully just "port" will do?
    Sure it will :-)

  25. #50
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,171
    Quote Originally Posted by defragster View Post
    Not sure what changed - it was so consistent before.
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •