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

Thread: Teensy 4.1 Lockup

  1. #26
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    Even TyComm overwhelms the machine at times and dumps 'system data' from somewhere instead of USB incoming data - not news.

    Boring and dizzying watching and trying to see what the average is as it comes and goes.

    Running the following against t_Sermon still results in quick stopping:
    Code:
    ...
    count=10041128, lines/sec=0
    count=10041129, lines/sec=0
    count=1004
    Built as Dual Serial with stats to get some meaning from the spew against TyCommander:
    Code:
    ...
     Grp to 50000 sum 254354 
     Grp to 100000 sum 9186332 
     Grp to 150000 sum 1167211 
     Grp to 300000 sum 135041 
     Grp to 350000 sum 1910473 
     Grp to 400000 sum 1309225 
     Grp to 500000 sum 8205257 
     Grp to 550000 sum 4543060 
     Grp to 600000 sum 6676894 
     Grp to 650000 sum 2476576 
     Grp to 700000 sum 3559980 
     Grp to 750000 sum 575597 
    	 @count50000000
    
    ...
     Grp to 50000 sum 254354 
     Grp to 100000 sum 9186332 
     Grp to 150000 sum 1167211 
     Grp to 300000 sum 135041 
     Grp to 350000 sum 1910473 
     Grp to 400000 sum 1309225 
     Grp to 500000 sum 8872405 
     Grp to 550000 sum 4543060 
     Grp to 600000 sum 39819151 
     Grp to 650000 sum 110148705 
     Grp to 700000 sum 107430006 
     Grp to 750000 sum 41085060 
     Grp to 800000 sum 160157922 
     Grp to 850000 sum 3981055 
    	 @count500000000
    With IDE SerMon as primary it only runs to here:
    Code:
    ...
    count=16228949, lines/sec=651164
    count=16228950, lines/sec=651164
    count=16228951, lines/sec=651164
    with stats up to there:
    Code:
     Grp to 50000 sum 504584 
     Grp to 400000 sum 804025 
     Grp to 450000 sum 1329998 
     Grp to 500000 sum 1028316 
     Grp to 550000 sum 392432 
     Grp to 600000 sum 661922 
     Grp to 700000 sum 1278723 
    	 @count16000000
    Altered code for USB1:
    Code:
    // post #2626 original Paul sketch
    // https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=204681&viewfull=1#post204681
    // https://forum.pjrc.com/threads/68199-Teensy-4-1-Lockup?p=288825&viewfull=1#post288825
    
    
    // Simple test of Serial.print() speed.  How many lines/sec can your
    // Arduino board print to the serial monitor?
    
    // This combination of printing text and numbers is meant to test the
    // most common way Serial printing is used with Arduino.
    
    // On true serial boards, this test measures how much of the bandwidth
    // of a high baud rate can really be used.  Efficiency copying bytes
    // into the transmit buffer, and the serial transmit interrupt, are
    // the main factors.
    
    // On native USB boards, this test measures how well the USB stack can
    // utilize the USB bandwidth.  USB is fast but complex protocol.  This
    // test tends to measure how well optimized the USB code is.  For
    // 12 Mbit/sec (full speed) USB, 36848 is the theoretical maximum
    // lines/sec.  For 480 Mbit/sec (high speed) USB, 1521371 is the
    // theoretical maximum lines/sec speed.  Unlike ordinary serial, your
    // operating system and its drivers, the type of USB port, whether a
    // USB hub is used, and CPU load on your computer can affect the speed.
    
    uint32_t count, prior_count;
    uint32_t prior_msec;
    uint32_t count_per_second;
    
    // Uncomment this for boards where "SerialUSB" needed for native port
    //#define Serial SerialUSB
    
    void setup() {
      Serial.begin(1000000); // edit for highest baud your board can use
      while (!Serial) ;
      count = 10000000; // starting with 8 digits gives consistent chars/line
      prior_count = count;
      count_per_second = 0;
      prior_msec = millis();
    }
    
    uint32_t groups[40];
    void loop() {
      Serial.print("count=");
      Serial.print(count);
      Serial.print(", lines/sec=");
      Serial.println(count_per_second);
      count = count + 1;
      uint32_t msec = millis();
      if (msec - prior_msec > 1000) {
        // when 1 second as elapsed, update the lines/sec count
        prior_msec = prior_msec + 1000;
        count_per_second = count - prior_count;
        prior_count = count;
      }
      groups[ count_per_second / 50000 ]++;
      if ( !(count%1000000) ) {
        for ( int ii=0; ii<40; ii++ ) {
          if ( 0!=groups[ii] ) {
            SerialUSB1.printf( " Grp to %u sum %u \n", (1+ii)*50000, groups[ii] );
          }
        }
        SerialUSB1.print("\t @count");
        SerialUSB1.println(count);
      }
    }

  2. #27
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    @Paul
    Out of curiosity I ran the usb_serial_print_speed sketch.

    Code:
    ...
    ...
    count=10037586, lines/sec=0
    count=10037587, lines/sec=0
    count=10037588, lines/sec=0
    count=10037589, lines/sec=0
    cou <---- Stalls here
    Opening and closing the serial monitor restarts it.
    Code:
    count=38956797, lines/sec=847414
    count=38956798, lines/sec=847414
    count=38956799, lines/sec=847414
    count=3895680 <---- Stalls here again
    This is on a Windows10x64 with the Locked T4.

  3. #28
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    Quote Originally Posted by mjs513 View Post
    @Paul
    Out of curiosity I ran the usb_serial_print_speed sketch.

    Code:
    ...
    ...
    count=10037586, lines/sec=0
    count=10037587, lines/sec=0
    count=10037588, lines/sec=0
    count=10037589, lines/sec=0
    cou <---- Stalls here
    Opening and closing the serial monitor restarts it.
    Code:
    count=38956797, lines/sec=847414
    count=38956798, lines/sec=847414
    count=38956799, lines/sec=847414
    count=3895680 <---- Stalls here again
    This is on a Windows10x64 with the Locked T4.
    So we both did that (p#25) and got similar results!

    IDE SerMon still can't handle as before - and for Ref TyComm still works well showing it isn't the Teensy falling down ;;.

  4. #29
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    Quote Originally Posted by defragster View Post
    So we both did that (p#25) and got similar results!

    IDE SerMon still can't handle as before - and for Ref TyComm still works well showing it isn't the Teensy falling down ;;.
    Yep figured a good point to do that so have 2 data points win 10 and win11
    Last edited by defragster; 09-18-2021 at 05:05 PM. Reason: fix quote ]

  5. #30
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,217
    I rebooted that Macbook Air to Windows 10, and sure enough the serial monitor stalls, usually with 10 minutes.

  6. #31
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    Quote Originally Posted by mjs513 View Post
    Yep figured a good point to do that so have 2 data points win 10 and win11
    Indeed - very good not just tested on one machine. We got a heck of a windstorm and power was out 6 pm to 1:44 am - so running on generator and already put laptop away the other test was run on.

    My adding the Dual Serial for STATS didn't alter the primary behavior ... I should have put it under #ifdef so it ran as posted on Single USB.

    TyComm thrashes so hard keeping up the UI becomes ignorant of clicks and selects. If you run that w/Stats it is funny how it starts tending to be 'under 250K lps' then the higher buckets start hitting over time - then become the primary hits.

    Just confirmed the RamDrive I added in 6GB of the 32GB on this machine is being used for the TyComm log files. It is noted to be 1.5X SSD speed - but that doesn't keep TyComm from showing garbage at times and getting overwhelmed.

    So far Win 11 diffs are just minor UI alterations and all else seems to be unchanged as far as usual function ... except for slow Explorer rename and drag drop ... like a floppy disk instead of an SSD ?????

  7. #32
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    Quote Originally Posted by PaulStoffregen View Post
    I rebooted that Macbook Air to Windows 10, and sure enough the serial monitor stalls, usually with 10 minutes.
    Just as a data point - with me it was a second or two (didn't measure but was quick) running the USB test. With the original test sketch -yep ran about that amount of time.

  8. #33
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    718
    Quote Originally Posted by brtaylor View Post
    Yes, it's a hard freeze and the Teensy is unresponsive. COM port is greyed out and a power cycle is required. Good idea about the crash report, thanks! So far just adding back in chunks of code and hardware to see if I can isolate the cause.
    Just to bring the original hard freeze to a close - it was I2C on a cable that was causing the issues. Switching over to a protocol meant for cables (i.e. CAN bus) solved the issue.

  9. #34
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    Quote Originally Posted by brtaylor View Post
    Just to bring the original hard freeze to a close - it was I2C on a cable that was causing the issues. Switching over to a protocol meant for cables (i.e. CAN bus) solved the issue.
    Thanks for letting us know what the original hard freeze resolution was. Have to keep that one in the back of the mind.

  10. #35
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,217
    Working on this problem today. Please give this copy of teensy_serialmon.exe a try. It goes into {Arduino}/hardware/tools, replacing the copy that's already installed. The default {Arduino} location is C:\Program Files (x86)\Arduino.

    Best to quit Arduino, but just closing the serial monitor window should be enough for Windows to allow you to overwrite the original file.

    Does this new version fully solve the problem on your machine?
    Attached Files Attached Files

  11. #36
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    No longer STALLING quickly.

    See strings of 'system garbage' fly by. Goes Clear - then garbage- then clear.
    > sometimes it runs GUI updates fast scrolling - then fitful pauses - and now again 800K and steady streaming.

    Click image for larger version. 

Name:	tSM_a.png 
Views:	21 
Size:	102.1 KB 
ID:	25904

    Still running past 408M counts

    <edit>: At 700M counts ... will let it run - No 'garbage' in some time - and good updates
    Click image for larger version. 

Name:	tSM_b.png 
Views:	22 
Size:	125.5 KB 
ID:	25905

    System load not real high.

  12. #37
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    @Paul - seems you fixed something - not the Windows BUFFER bug - but t_sermon doing well and looking good just now.

    Still running - over an hour between posts and running before that:
    Click image for larger version. 

Name:	tSM_c.png 
Views:	22 
Size:	108.3 KB 
ID:	25906

    UPDATE: It gave up the ghost here: count=3,913,515,160
    Code:
    ...
    count=3913515160, lines/sec=573526
    count=3913515161, lines/sec=573526
    count=3913515
    Starting with "ifdef"Dual USB using TyComm to gather stats and see if it changes anything:
    Code:
     Grp to 50000 sum 205718 
     Grp to 100000 sum 438423 
     Grp to 150000 sum 2397453 
     Grp to 200000 sum 4444757 
     Grp to 250000 sum 2413710 
     Grp to 300000 sum 3603310 
     Grp to 350000 sum 534094 
     Grp to 400000 sum 962535 
    	 @count25000000
    
    ...
    
     Grp to 50000 sum 205718 
     Grp to 100000 sum 438423 
     Grp to 150000 sum 2397453 
     Grp to 200000 sum 4743284 
     Grp to 250000 sum 2471652 
     Grp to 300000 sum 4017885 
     Grp to 350000 sum 3827966 
     Grp to 400000 sum 2453690 
     Grp to 450000 sum 4622664 
     Grp to 500000 sum 849096 
     Grp to 550000 sum 22379562 
     Grp to 600000 sum 3911706 
     Grp to 650000 sum 6020031 
     Grp to 700000 sum 6783385 
     Grp to 800000 sum 679621 
     Grp to 850000 sum 19197864 
    	 @count95000000
    Last edited by defragster; 09-19-2021 at 05:08 AM.

  13. #38
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,217
    Quote Originally Posted by defragster View Post
    See strings of 'system garbage' fly by. Goes Clear - then garbage- then clear.
    Quote Originally Posted by defragster View Post
    seems you fixed something - not the Windows BUFFER bug
    I only attempted to fix the "lockup" bug, where the serial monitor would stall and no longer show any data Teensy transmits.


    I am aware of 3 other possible issues on Windows, all of which might be called "the Windows BUFFER bug". My hope in writing this detailed message is we can all be aware of these and talk more specifically about which problems are being seen.

    1: Buffer bloat: An excessive amount of incoming data can become buffered on the PC side. This effect can be seen by crafting a program which suddenly stops transmitting, like when a button connected to a pin is pressed. If running a benchmark like lines/sec (modified to stop on command), you can estimate the size of bloated buffers by trying to measure the time from actually stopping transmission until the GUI stops updating.

    2: Inconsistent performance: While running benchmarks like lines/sec, performance can vary quite a lot. Whether this correlates with other activity on the PC is unknown (at least to me).

    3: Corrupted data: During times of high speed data flow, occasionally garbage data is received. It appears to be the contents of memory somewhere on the Windows machine, rather than the data Teensy transmitted.

    My hope is to fix issue #1 in the future by using localhost networking rather than anonymous pipes (the way Windows implements stdin / stdout) for the connection between teensy_serialmon.exe and the IDE's serial monitor window.

    I'm pretty sure #3 is a bug within Windows or the Windows-provided USBSER.SYS driver. Only Microsoft can fix that. It seems to happen with Coolterm and all other programs cable of running at these higher speeds. I currently do not have any way of reporting this problem to Microsoft.

    Whether anything can be done about #2, I do not know.

  14. #39
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    Couldn't sleep and saw your message so figured might as well test it out.

    Set up 2 T4's, one locked and 1 unlocked. Running the original tempMon sketch on one and the usb lines per second sketch.

    As at defragster pointed out
    Quote Originally Posted by defragster
    See strings of 'system garbage' fly by. Goes Clear - then garbage- then clear.
    > sometimes it runs GUI updates fast scrolling - then fitful pauses - and now again 800K and steady streaming.
    The only thing I will add is that after the garbage cycle clears (as defined by Tim) the sketch does pick up again.

    But neither sketch is stalling the serial monitor as before!!!!!!

    In terms of item #2 Inconsistent performance, as the test is running (and still is) I was running Cura and didn't see any change (that I noticed) in lines/sec. I know that is purely anecdotal but figure its a data point.

    So far been running for awhile - lost tract of time - maybe an hour or so:
    Click image for larger version. 

Name:	Capture.PNG 
Views:	15 
Size:	47.5 KB 
ID:	25907

    Will update if and when it either serial monitor stalls.

    UPDATE: at about a count of 3.5million garbage struck again but the picked cleared and serial monitor recovered. So far garbage twice in 3.5million counts. Original sketch running no issues.

    Update 1: Serial Monitor still going strong:
    Lines/sec:
    Code:
    count=4145391380, lines/sec=504740
    count=4145391381, lines/sec=504740
    count=4145391382, lines/sec=504740
    Test Sketch in post#1
    Code:
    53.13C	5891436
    53.13C	5891446
    53.13C	5891456
    Going to let it keep running until morning and s
    Last edited by mjs513; 09-19-2021 at 06:48 AM.

  15. #40
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    If corrupted is more technical than 'garbage' - the jest about fixing windows referred to #3 - just noting as noted as seen before - it is apparently a bug in how Windows passes buffers. TyCommander and the SerMon's both get that.

    Indeed #2 is more nebulous - it certainly Surges/delays at times. There is no overt contention for resources plenty of RAM and no Core alone is above 50% - but no way of knowing where the USB load impinges on processing or gets counted in TaskMan displayed stats, if directly at all.

    Got a new 'Samsung USB C' drive for transfer to laptop - quoted at up to 400MB/s - it is getting filled from SSD folder - and filling horribly slowly, so that is sharing resources - but Copy Paused doesn't change anything.

    Moved T_4.1 from HUB to front port - died quickly at only 39M counts. Versus through USB 3 Hub - more variables

    There is clearly a #1 Buffer bloat. Data comes in faster than the GUI can scroll it out.

  16. #41
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    powered up my 11th gen i7 laptop with programmed T_4.1
    It doesn't run very long. Just the Explorer open to open then open IDE open with prior teensy_serialmon #1 update:

    Code:
    count=57222822, lines/sec=717068
    count=57222823, lines/sec=717068
    count=57222824, lines/sec=717068
    count=572
    .. wait it was long stalled after a halting start - now running again .... maybe hiding the window with browser gave it life before?
    okay ran a short time, stalled ... then blank with no scroll bar Not showing (offline) and the AutoScroll check still active

    Started another T_4.1 on Win 11 desktop before above - it seems still running

    UI very non-responsive - at 848 M counts - but right scroll shows much below ... finally redrew on resize and checked autoscroll again - but not updating.

    As I returned it had just dumped a bunch of non printable chars , then resumed.


    Looking at TaskMan I see 32 bit Java? Any chance a 64 bit version would run better?
    Last edited by defragster; 09-19-2021 at 09:20 AM.

  17. #42
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,217
    Quote Originally Posted by defragster View Post
    Looking at TaskMan I see 32 bit Java? Any chance a 64 bit version would run better?
    Difficult to say, as Arduino doesn't publish any copies of the IDE (for Windows) using a 64 bit JRE.

    If you wanted to experiment, you could try replacing C:\Program File (x86)\Arduino\java with a 64 bit JRE. Arduino uses version 8u242. This page has version 8u302. I'm not sure where to download the older 8u242 version.

    https://adoptopenjdk.net/releases.ht...ariant=hotspot

    You'll see 4 files. You want the JRE, not the full JDK. I'm assuming the ZIP and MSI are the same files. You probably want the ZIP archive so you can extract it at a location of your choosing and then copy its contents into the {Arduino}/java folder.

    I'm not entirely sure if just replacing the JRE will even work, as all the other non-Java stuff in the IDE is still 32 bits. In theory you could recompile everything, but newer versions of Arduino have stuff implemented in Google Go language...
    Last edited by PaulStoffregen; 09-19-2021 at 10:54 AM.

  18. #43
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    @Paul - @defragster

    Been running both sketches now for about 6 hours and still seems to be working on a Windows10x64 i7-8700K.

    usb lines per second
    Code:
    count=940,733,502, lines/sec=503292
    Test Sketch:
    Code:
    54.44C	24704705
    Looks like the issue of the stalled Serial Monitor is resolved - at least on my machine.

    Out of curiosity what was the issue with the stalling?

  19. #44
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,217
    Quote Originally Posted by mjs513 View Post
    Out of curiosity what was the issue with the stalling?
    It turned out to be a deadlock condition between threads caused by code which attempts to manage buffers in a way to reduce the number of WIN32 system calls.

    Or just "Paul made a mistake while trying to optimize too much" would be the simple explanation.

  20. #45
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    Quote Originally Posted by PaulStoffregen View Post
    It turned out to be a deadlock condition between threads caused by code which attempts to manage buffers in a way to reduce the number of WIN32 system calls.
    Got it thanks. By the way is there any other way you want us to test Serial monitor to make sure its working? Usb-lines/sec seem to be a good job of stressing.


  21. #46
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,217
    More serial monitor testing probably isn't worthwhile. I've already spent quite a lot of time on the 3 known issues in msg #38. They're not going to be fixed anytime soon. Unless any other problems are discovered, I'm not looking forward to rehashing those 3 known issues.

    I would like to investigate the I2S lockup issue mentioned in msg #33. Especially if it was using the Wire library, all I2C problems are supposed to cause those functions to return with error code. Lockups are never supposed to happen.

    Brian, if you're still reading, can you give us some detail on how to reproduce that I2C lockup?

  22. #47
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    7,670
    Quote Originally Posted by PaulStoffregen View Post
    More serial monitor testing probably isn't worthwhile. I've already spent quite a lot of time on the 3 known issues in msg #38. They're not going to be fixed anytime soon. Unless any other problems are discovered, I'm not looking forward to rehashing those 3 known issues.

    I would like to investigate the I2S lockup issue mentioned in msg #33. Especially if it was using the Wire library, all I2C problems are supposed to cause those functions to return with error code. Lockups are never supposed to happen.

    Brian, if you're still reading, can you give us some detail on how to reproduce that I2C lockup?
    Got it. Just to close the SerialMonitor test out got to 2,844,425,876 before stopping. And just a side note in @brtaylor test sketch he had a delay(10) between prints. Did some experimenting and it seems the minimum delay if you you are going to do something like that is
    Code:
    delayMicroseconds(50);
    At 50mirosecond delay it does stall the serial monitor. Didn't try anything between 50 and 100 though.

    Will be interesting Brian's I2C issue especially with the stuff he works with.

  23. #48
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    718
    Quote Originally Posted by PaulStoffregen View Post
    More serial monitor testing probably isn't worthwhile. I've already spent quite a lot of time on the 3 known issues in msg #38. They're not going to be fixed anytime soon. Unless any other problems are discovered, I'm not looking forward to rehashing those 3 known issues.

    I would like to investigate the I2S lockup issue mentioned in msg #33. Especially if it was using the Wire library, all I2C problems are supposed to cause those functions to return with error code. Lockups are never supposed to happen.

    Brian, if you're still reading, can you give us some detail on how to reproduce that I2C lockup?
    Hi Paul, let me see if I can replicate the I2C piece with a simple example.

  24. #49
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,217
    Thanks. There's probably nothing that can be done to make I2C actually work over such a cable, but at least the Wire library should always return an error. It should never crash, no matter what (non-destructive) hardware is used.

  25. #50
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,269
    Quote Originally Posted by PaulStoffregen View Post
    Difficult to say, as Arduino doesn't publish any copies of the IDE (for Windows) using a 64 bit JRE.

    If you wanted to experiment, you could try replacing C:\Program File (x86)\Arduino\java with a 64 bit JRE. Arduino uses version 8u242. This page has version 8u302. I'm not sure where to download the older 8u242 version.

    https://adoptopenjdk.net/releases.ht...ariant=hotspot

    You'll see 4 files. You want the JRE, not the full JDK. I'm assuming the ZIP and MSI are the same files. You probably want the ZIP archive so you can extract it at a location of your choosing and then copy its contents into the {Arduino}/java folder.

    I'm not entirely sure if just replacing the JRE will even work, as all the other non-Java stuff in the IDE is still 32 bits. In theory you could recompile everything, but newer versions of Arduino have stuff implemented in Google Go language...
    Doesn't seem like a simple replace - if these steps replaced the JRE executables?
    Downloaded the : OpenJDK8U-jre_x64_windows_hotspot_8u302b08.zip
    and replaced in : C:\T_Drive\Arduino_1.8.16_155 - Copy\java { my Arduino is from ZIP so nothing installed in \Programs }

    The "C:\T_Drive\Arduino_1.8.16_155 - Copy\arduino.exe" then shows first load image and goes away.

    No Joy. Something is expecting 32b - or some other element customized or added missing or not prepared to swap 32 for 64 bit?

Posting Permissions

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