Teensyduino 1.56 Beta #1

Status
Not open for further replies.
@KurtE - Quick glance shows that edit in Teensy4 cores - will the same apply to T_3.6 with RTC and USB_Host?
Good Morning,

As you know the T3.x and T4.x USB code is very different. These fixes are for T4.x...

I personally have not played for awhile with running this on T3.x, which we need to do.

The fix was for the MTP code to be able to send an event, like a local file was created..

Hopefully the code I still have in the MTP library for T3.x events still works...

We may at some point want to move some of that functionality into the cores. Actually in both T3/T4 cases probably should move the
sendEvent code into the main stuff.

As for dates/Times, Again I have not personally tested, but should... Maybe later today I will unplug the T4.1 in the memory board to be a T3.6 and check

USBHost code... Or more particularly in this case the MSC code again will need to test.

Hope this makes sense
 
I believe what probably happened is the Arduino IDE started using the new location, but kept the new location in memory and didn't flush it to {AppData}/Arduino/preferences.txt until you quit the program. Sadly, the platform.txt recipes don't provide a macro to pass the sketckbook folder to commands (or if that capability does exist, it's not documented), so the encryption utility has to look up the AppData location from Windows, find preferences.txt, and parse it to discover where your sketchbook folder is located. If the IDE hasn't actually written your new settings to that preferences.txt file, the encryption utility will look for key.pem in whatever old location is still in preferences.txt.

I've added this to the code security documentation.

I could patch the Java code to make the IDE flush the settings to preferences.txt when you click OK on the File > Preferences dialog box. But unless this becomes a common issue, I'm not feeling eager to add more Java modifications to the patch set I maintain for every Arduino IDE release.

Good, figured it was an IDE issue from the dir change - and you'd know if there was a clean fix. Restarting IDE would be the norm - but IDE doesn't force/suggest that, and button is 'OK' and not 'Save'. I was using simple blink like things so I didn't note if it rescanned libraries as none were included - which it may do now, IIRC?

Having it in the 'PJRC usage' doc good.
 
Scary thing is if there had been a pem.key in that folder that was not the intended during the LOCK operation?

This isn't an issue for 2 reasons.

1: The "Teensy 4 Security" dialog box does have access to the Arduino IDE preferences in memory (even if not flushed to preferences.txt) because it is plugin written in Java and running directly in the IDE.

2: The LockSecureMode sketch doesn't actually have any key.pem data. Neither does the VerifySecure sketch. Only FuseWrite gets key.pem info embedded.


Edit: if the wrong key.pem file is used to build the LockSecureMode .ehex (because the encryption utility found the wrong location or for any other reason), Teensy Loader will notice the public key hash in the .ehex file doesn't match what's burned into the hardware. Because secure mode isn't locked, Teensy Loader will fall back to loading the .hex file, because it knows the .ehex can't run. When the .hex file runs, the HAB status check will return a failure code and the sketch will print "Fail: This program is not properly encrypted." and not perform the permanent the lock operation.


Only note is : anything the BUILD or Sketch can present as a reminder/confirmation of what file was used from where.

Currently, no. If this becomes a regular problem, a future version could print info about the encryption process. Maybe we'd use the platform.txt features to tell it whether "verbose output during compilation" is in effect. But I don't see going to that effort unless this becomes a somewhat frequently asked question.
 
KurtE said:
Hopefully the code I still have in the MTP library for T3.x events still works...

Just tried it on a T3.6 and not really working - did remember to update usb_desc.h. Not sure anything else at this point. But got the following error:
Code:
D:\Users\Merli\Documents\Arduino\libraries\MTP_t4\src\MTP.cpp:49:23: error: 'printStream_' was not declared in this scope
   #define printf(...) printStream_->printf(__VA_ARGS__)
but printStream_ is defined as:
Code:
Stream *MTPD::printStream_ = &Serial;

No biggie for first pass did run with dbug = 0 it does see the drives I have set up and can access them from sermonitor:
Code:
CrashReport is not available on Teensy LC & 3.x

C:\Users\Merli\AppData\Local\Temp\arduino_modified_sketch_411287\mtp-test.ino Sep 27 2021 14:13:54
Date: 27/9/2021 14:13:54
Ram Drive of size: 65536 initialized
sd_addFilesystem: 0 1fff2020 RAM 1fff2964 1fff2020
Set Storage Index drive to 0
Program Storage 0 PROGM failed or missing
sd_addFilesystem: 1 1fff2c04 sflash5 1fff2964 1fff2c04
SPIFlash Storage 0 5 sflash5 67108864 6483968
sd_addFilesystem: 2 1fff2cdc sflash6 1fff2964 1fff2cdc
SPIFlash Storage 1 6 sflash6 67108864 36864

Dump Storage list(6)
store:0 storage:10001 name:RAM fs:1fff2020
store:1 storage:20001 name:sflash5 fs:1fff2c04
store:2 storage:30001 name:sflash6 fs:1fff2cdc
store:3 storage:40001 name:WINBOND1G fs:1fff25cc
store:4 storage:50001 name:WINBOND2G fs:1fff26bc
store:5 storage:60001 name:MSC0-1 fs:1fff3280
Storage Index 5 Name: MSC0-1 Selected

 Space Used = 642908160
Filesystem Size = 61992730624
Directory
---------
T_4.1/
  workshop.pdf                        8894873
  card11a_rev3_web.pdf                377551
  card11b_rev3_web.pdf                396325
  D435 Obs-slam Links.txt             4879
  esp-psram64_.pdf                    1344699
  esp-psram64_esp-psram64h_datasheet_en.txt  61440
  NXP_i2c_UM10204.pdf                 1395785
  PRINTOUTPUTs2.txt                   630
  Routed_B.jpg                        194564
  T4.1-Cardlike0.jpg                  220021
  teensy41_card.png                   320054
  Visio-driver.pdf                    1472938
  VSLAM_and_Navigation_System_of_Unmanned_Ground_Vehicle_Based_on_RGB-D_Camera.pdf  5725283
  w25m02gw revd 012219.pdf            1673403
  W25N02aKV_Datasheet_20201022_C.pdf  1665621
datalog.txt                           252
System Volume Information/
  WPSettings.dat                      12
  IndexerVolumeGuid                   76

However Teensy does not show up in windows explorer. I do see the a MTP USB Device in Device Manager
 
I've been running the usb_serail_print_speed on Teensy 4.1 connected to my Windows 10 test machine. Fast data transfer to Windows is clearly not working so well.

For now I'm focusing on fixing the errant red LED blink issue on not-yet-locked lockable boards, and starting to look at the MTP code.

After MTP is integrated, and definitely not before that time, I do need to revisit how we're doing fast data transfer with Windows. @Defragster - I just want to prepare you now to expect the possibility that lines/sec speed will massively decrease. I'm pretty sure the speeds we're seeing today on Windows are illusory. Huge amounts of data are being dropped, as you can clearly see by just watching the line count number increment steadily and then take large sudden jumps. You can get a pretty reasonable idea of the actual lines/sec speed by placing your cursor next to the 6th digit and watching / counter how many seconds it takes to increment.
 
This isn't an issue for 2 reasons.

1: The "Teensy 4 Security" dialog box does have access to the Arduino IDE preferences in memory (even if not flushed to preferences.txt) because it is plugin written in Java and running directly in the IDE.

2: The LockSecureMode sketch doesn't actually have any key.pem data. Neither does the VerifySecure sketch. Only FuseWrite gets key.pem info embedded.


Edit: if the wrong key.pem file is used to build the LockSecureMode .ehex (because the encryption utility found the wrong location or for any other reason), Teensy Loader will notice the public key hash in the .ehex file doesn't match what's burned into the hardware. Because secure mode isn't locked, Teensy Loader will fall back to loading the .hex file, because it knows the .ehex can't run. When the .hex file runs, the HAB status check will return a failure code and the sketch will print "Fail: This program is not properly encrypted." and not perform the permanent the lock operation.




Currently, no. If this becomes a regular problem, a future version could print info about the encryption process. Maybe we'd use the platform.txt features to tell it whether "verbose output during compilation" is in effect. But I don't see going to that effort unless this becomes a somewhat frequently asked question.

Indeed - re the Edit: last night on returning to desktop to 'Lock' one T_4.1 :: I looked and confirmed that in the LOCK sketch it requires execution to be encrypted to proceed - meaning the right pem.key was used to build before it can be locked.

Just scanning the td_code_security.html again:
> The 'sketchbook' change is noted, process seems well bounded for use as directed.
> not sure the temp diff is real? it seems to track more with date of production - but I don' have a newly made T_4.0. I did a current test on T_4.0 and current was withing 1mA - not sure how much temp that could add?
-> Did a current used over 10 minutes on T_4.1 lockable but locked versus production and didn't detect much/any increase in passing electrons with crude tools.
-> can now do T_4.1 temp monitoring, but have not yet.
> The 5% decrypt overhead for Data/Code seems real - but that test was made to prove Code/Data decryption Extreme/Worst case worked at all. Ferreting out a % was some hand waving to a real number.
-> Frank B made/updated a .LD to force all code to Flash that I didn't test with that might give an easier to see 'general' effect on known Perf tests - though they may not void the cache with more localized code staying in cache.
> Find this text "A separate security reference manaul" to fix a typo ... manual
> In that or some section it might be noted overtly that : PJRC has developed this solution using that NDA security reference manual in consultation with NXP. { i.e. this is not a hack and uses informed best practices }
> Perhaps this "sensitive data full encrypted" should read "sensitive data fully encrypted"
> This " processor can not longer function" should read " processor can no longer function"

Good job Paul, it works.
 
I've been running the usb_serail_print_speed on Teensy 4.1 connected to my Windows 10 test machine. Fast data transfer to Windows is clearly not working so well.

For now I'm focusing on fixing the errant red LED blink issue on not-yet-locked lockable boards, and starting to look at the MTP code.

Let me know if my 'erroneous' use of TyComm has, or could provide any useful details for resolving the ODD blink cases, and the last posted case where a Locked board programming was interrupted and left not booting, thanks it seems to TyCommander injecting USB traffic? Not to have TyComm function like this, but in case it exposes a timing or USB issue that teensy_serial might be doing on a less frequent basis.

After MTP is integrated, and definitely not before that time, I do need to revisit how we're doing fast data transfer with Windows. @Defragster - I just want to prepare you now to expect the possibility that lines/sec speed will massively decrease. I'm pretty sure the speeds we're seeing today on Windows are illusory. Huge amounts of data are being dropped, as you can clearly see by just watching the line count number increment steadily and then take large sudden jumps. You can get a pretty reasonable idea of the actual lines/sec speed by placing your cursor next to the 6th digit and watching / counter how many seconds it takes to increment.

A drop in lines/sec is reasonable and expected, in fact Encouraged. It is better to have output slowed toward reliable/usable/trusted speed than the current pell mell throughput Windows poorly manages.

> Code like thisCode4Code/MakeCode.ino#L61 :: should not have to strategically place " delayMicroseconds( # ); " to get usable 3MB of output to feed a compiler where close does not count.
Code:
  for ( ii = 0; ii < 2; ii++ ) {
    SerialUSB1.print( szAlpha[ii] );
    for ( jj = 0; jj < 364; jj++ ) {
      SerialUSB1.print( (char)(base + (jj % 26)) );
      if ( 77 == (jj % 88) )
        SerialUSB1.print( "\"\n\t\"" );
    }
    SerialUSB1.println( "123\";" );
    [B]delayMicroseconds( 200 );[/B]
    base = 'a';
  }

That file has seven delayMicroseconds() varying from 10 to 200 us. With those in place the SerMon output has always compiled - before that some of those tight loops would result in missing output.
 
The serial problem is only a problem of Java. Or maybe how the serial mon or Java uses USB.
There are Windows terminal programs that can log e.g. to a file without errors (and without the garbage print) and at high speed.
 
The serial problem is only a problem of Java. Or maybe how the serial mon or Java uses USB.
There are Windows terminal programs that can log e.g. to a file without errors (and without the garbage print) and at high speed.

Have not found that terminal program for Windows that can keep up with T_4.x's portion of the 480 Mbps it can provide.

Those tried falter and fail long before TyCommander or PJRC's version in teensy_serial.

TyCommander is c/cpp not JAVA and it is roughly equal to PJRC's improved Teensy_serial implementation in 'reported' speed - and BOTH miss data and also get and show garbage buffers when T_4.x output is unconstrained.

They also both LAG with pending buffers of data behind what the GUI can show and when Teensy stops the data continues for some time after.

Also recently noted there was a minimal "C" code exe that pulled USB data without sending it all to display and it saw similar view of the data as delivered by Windows. That is the speed was no better and attempts to quickly validate the unseen data saw corruption of expected data in some fashion ... that was some time back so results not current and are approximated from personal memory.
 
Probably you're using the wrong software. I remember a thread about a "bug" in serial comm which turned out to be too slow software on PC and missing flow control. If Java is too slow flow control is needed. But I understand its not wanted for a benchmark. Slowing down is not wanted, too. A fast, good written program in better language is needed. Obviously, there is software that can do it (without garbage).
 
Probably you're using the wrong software. I remember a thread about a "bug" in serial comm which turned out to be too slow software on PC and missing flow control. If Java is too slow flow control is needed. But I understand its not wanted for a benchmark. Slowing down is not wanted, too. A fast, good written program in better language is needed. Obviously, there is software that can do it (without garbage).

Links welcome. All indications as noted are that Windows just mismanages the buffers supplied as it cannot process the data provided. At least 3 other SerMon replacement terminal programs tried are significantly slower than those noted.
 

Frank_B note of HTerm recently led me to : der-hammer.info/pages/terminal.html

It has great added features for counting input and output bytes and sending repeat char sets!

But when connected to a T_4.1 running the lines/sec demo ... it never counts or shows a single output byte ... Just the Hour Glass ... then spontaneously closed sometime in about a minute.

Started again a second time and hour glass and NO data display repeated ... it was unresponsive but didn't terminate until I hit Close.

Others tried were the SerMon in VisualMicro some years ago and some other Paid Terminal program I got a free license for : Both tried with T_3.6 (or older) and they couldn't keep up with that.
 
Yes I tried that too. The output to screen is slow. But the logged file shows no garbage. Tried to transfer 10MB - indeed, then, a few lines are missing. Not sure what the reason is. But: no garbage in the log file.
It seems to do some things better than the serial mon. Speed is indeed > 23MB/s, even with taking the few missing lines (less than 1%) into account.
 
Yes I tried that too. The output to screen is slow. But the logged file shows no garbage. Tried to transfer 10MB - indeed, then, a few lines are missing. Not sure what the reason is. But: no garbage in the log file.
It seems to do some things better than the serial mon. Speed is indeed > 23MB/s, even with taking the few missing lines (less than 1%) into account.

The referenced Cod4Code spits out about 3 million bytes of C source text as it crafts 4000 functions and other for an INO file.

It seemed to work ONCE - using the delays added to allow TyCommander to get file source that compiles, except it interjected literal chars at the line starts - so it cannot be used.

Taking out the delayMicroseconds() even closing and restarting no output appeared in hTerm.

I went back to the delayed output and it then showed as missing over a half million of the characters? And was again unreliable to synchronize the start and connect that TyCommander does an AWESOME job of - and t_sermon manages at times - but cannot help here as it is arriving on the T_4.1 Dual USB1 port that it cannot display.

So for general utility hTerm is really compromised here - though in some cases it has great added features.


When running Lines/Sec sketch - if the output is slow and not scrolling too fast to read then it is not working right, at least displaying the data.

TyComm saves data to a file of the size indicated, when that is reached it purges from the beginning to keep only the last 20MB as configured. That adds overhead, but is only a factor when input is streaming full speed overwhelming the system.
 
Quick T_4.1 Temp notes:
44.04 :: 9706380 ENC SM:9706380 - bare beta - USBhost plug on
38.59 :: 9706430 ENC ns:9706430 - Sitting on PJRC MemoryBoard breakout, dual QSPI
43.32 :: 7819570 nor ns:7819570 - bare production

Doesn't seem to be any suggestion in temp rise from lockable and locked betas
 
Seven RED Blinks on T_4.1 now that it is locked

@Paul got a FLASHING Red LED pattern { 9 Blink, Pause, ... repeat } on T_4.1 Not yet Locked Beta 1.07 board:

-> Using TyCommander for sermon - it has a '-delegate' option to take Serial Offline and trigger bootloader which alerts T_Loader to upload the IDE Command line builder passed sketch.
-->> This is the Normal way SublimeText editor is used with TSET, now that integrating TyComm into IDE won't work for upload

Well TyComm also logs the names of HEX files, and has an option ( that works on PRE 1.07 bootloaders ) {to upload prior HEX files}

On the 1.07 bootloader it reports in its log:

...

@Paul - update to this post #5.

Now with Beta T_4.1 LOCKED - performing these steps ( abusing TyComm while TLoader is open )

The Locked Teensy is giving SEVEN blinks and a pause then Repeat - where the pause seems longer than I recall on the 9 Blinks
-> though now Teensy.exe is still in AUTO mode while the Teensy blinks and pauses
> where before 9 blinks appeared when the same T_4.1 had been pem.key fused before being locked

Push of the button cause a normal upload and return to function.

Repro repeat:
Did build and Teensy upload of : R:\temp\arduino_build_PrimeTemp.ino\PrimeTemp.ino.hex
Gathering that path I went to TyComm and told it to upload that same file.

> The upload began - BY Teensy.exe loader when TyComm started by triggering the bootloader.
> was interrupted before completion it seems and teensy went offline to 7 blinks

clearing verbose before repeating that now shows:
Code:
21:48:54.307 (loader): encryption is optional, public key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
21:48:54.307 (loader): Device came online, code_size = 8126464
21:48:54.307 (loader): Board is: Teensy 4.1 (IMXRT1062), version 1.07
21:48:54.318 (loader): File "R:\temp\arduino_build_PrimeTemp.ino\PrimeTemp.ino.hex", 49152 bytes
21:48:54.321 (loader): File "R:\temp\arduino_build_PrimeTemp.ino\PrimeTemp.ino.ehex", 49152 bytes, and 4992 loader utility
21:48:54.327 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
21:48:54.327 (loader): File "PrimeTemp.ino.hex". 49152 bytes, 1% used
21:48:54.327 (loader): File "PrimeTemp.ino.hex" opened, but "PrimeTemp.ino.ehex" will actually be used
21:48:54.352 (loader): set background IMG_ONLINE
21:48:54.368 (loader): File "R:\temp\arduino_build_PrimeTemp.ino\PrimeTemp.ino.hex", 49152 bytes
21:48:54.368 (loader): File "R:\temp\arduino_build_PrimeTemp.ino\PrimeTemp.ino.ehex", 49152 bytes, and 4992 loader utility
21:48:54.377 (loader): ehex is valid, key hash: 85A79CC1 B7C7F866 7F5BB3ED 0F9C9BA5 B4149EE2 72846D35 86B63863 B0699942
21:48:54.382 (loader): File "PrimeTemp.ino.hex". 49152 bytes, 1% used
21:48:54.384 (loader): File "PrimeTemp.ino.hex" opened, but "PrimeTemp.ino.ehex" will actually be used
21:48:54.407 (loader): elf appears to be for Teensy 4.1 (IMXRT1062) (8126464 bytes)
21:48:54.407 (loader): elf binary data matches hex file
21:48:54.407 (loader): elf file is for Teensy 4.1 (IMXRT1062)
21:48:54.412 (loader): using encrypted ehex (optional - secure mode not yet locked)
21:48:54.438 (loader): begin operation
21:48:54.478 (loader): flash, block=0, bs=1024, auto=1
21:48:54.518 (loader): flash, block=1, bs=1024, auto=1
21:48:54.521 (loader): flash, block=2, bs=1024, auto=1
21:48:54.523 (loader): flash, block=3, bs=1024, auto=1
21:48:54.525 (loader): flash, block=4, bs=1024, auto=1
21:48:54.531 (loader): flash, block=5, bs=1024, auto=1
21:48:54.534 (loader): flash, block=6, bs=1024, auto=1
21:48:54.537 (loader): flash, block=7, bs=1024, auto=1
21:48:54.540 (loader): flash, block=8, bs=1024, auto=1
21:48:54.543 (loader): flash, block=9, bs=1024, auto=1
21:48:54.547 (loader): flash, block=10, bs=1024, auto=1
21:48:54.559 (loader): flash, block=11, bs=1024, auto=1
21:48:54.561 (loader): flash, block=12, bs=1024, auto=1
21:48:54.564 (loader): flash, block=13, bs=1024, auto=1
21:48:54.567 (loader): flash, block=14, bs=1024, auto=1
21:48:54.570 (loader): flash, block=15, bs=1024, auto=1
21:48:54.574 (loader): flash, block=16, bs=1024, auto=1
21:48:54.577 (loader): flash, block=17, bs=1024, auto=1
21:48:54.577 (loader): flash, block=18, bs=1024, auto=1
21:48:54.588 (loader): flash, block=19, bs=1024, auto=1
21:48:54.591 (loader): flash, block=20, bs=1024, auto=1
21:48:54.594 (loader): flash, block=21, bs=1024, auto=1
21:48:54.598 (loader): flash, block=22, bs=1024, auto=1
21:48:54.601 (loader): flash, block=23, bs=1024, auto=1
21:48:54.601 (loader): flash, block=24, bs=1024, auto=1
21:48:54.607 (loader): flash, block=25, bs=1024, auto=1
21:48:54.616 (loader): flash, block=26, bs=1024, auto=1
21:48:54.620 (loader): flash, block=27, bs=1024, auto=1
21:48:54.626 (loader): flash, block=28, bs=1024, auto=1
21:48:54.629 (loader): flash, block=29, bs=1024, auto=1
21:48:54.629 (loader): flash, block=30, bs=1024, auto=1
21:48:54.629 (loader): flash, block=31, bs=1024, auto=1
21:48:54.629 (loader): flash, block=32, bs=1024, auto=1
21:48:54.656 (loader): flash, block=33, bs=1024, auto=1
21:48:54.661 (loader): flash, block=34, bs=1024, auto=1
21:48:54.661 (loader): flash, block=35, bs=1024, auto=1
21:48:54.661 (loader): flash, block=36, bs=1024, auto=1
21:48:54.710 (loader): flash, block=37, bs=1024, auto=1
21:48:54.716 (loader): flash, block=38, bs=1024, auto=1
21:48:54.721 (loader): flash, block=39, bs=1024, auto=1
21:48:54.725 (loader): flash, block=40, bs=1024, auto=1
21:48:54.726 (loader): flash, block=41, bs=1024, auto=1
21:48:54.726 (loader): flash, block=42, bs=1024, auto=1
21:48:54.726 (loader): flash, block=43, bs=1024, auto=1
21:48:54.742 (loader): flash, block=44, bs=1024, auto=1
21:48:54.749 (loader): flash, block=45, bs=1024, auto=1
21:48:54.754 (loader): flash, block=46, bs=1024, auto=1
21:48:54.759 (loader): flash, block=47, bs=1024, auto=1
21:48:54.793 (loader): sending reboot
21:48:54.793 (loader): begin wait_until_offline
21:48:54.855 (loader): offline, waited 1
21:48:54.856 (loader): end operation, total time = 0.419 seconds
21:48:54.856 (loader): set background IMG_REBOOT_OK
21:48:54.856 (loader): redraw timer set, image 14 to show for 1200 ms
21:48:54.959 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
21:48:54.964 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
21:48:54.968 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
21:48:54.972 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
21:48:54.976 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
21:48:55.029 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
21:48:55.029 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/3
21:48:55.029 (loader): HID/win32:  vid:046D pid:C52B ver:1211  usb:0/140000/0/9/4/2/4
21:48:56.064 (loader): redraw, image 9

And again TyComm flagged a RED onscreen error expecting the Teensy to be ready and it logged this from both trials:
Code:
[reboot@9706430-Teensy] Failed to reboot board '9706430-Teensy
[upload@9706430-Teensy] I/O error while writing to '\\.\HID#VID_16C0&PID_0478#8&295A2D2B&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}'
[upload@9706430-Teensy] I/O error while writing to '\\.\HID#VID_16C0&PID_0478#8&295A2D2B&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}'
 
It can't be the USB drivers, otherwise no USB stick would work. It must be something else.
It is remarkable that H-Term does not log or output random characters.
The problem of missing lines also seems to occur in H-Term only after a certain amount.

In the end, however, it doesn't matter. As you can see once again, it's up to the PC. One should simply do without these tests.
After all, it leads to nothing.
 
@Mcu32 - it must a different interface because indeed USB Sticks work at much higher data rates without error.

Paul has some understanding from spending years making USB work and a week with the last update to get it as fast as it is.

H-Term may add some overhead checking that results in not getting corrupt buffers from Windows - or not displaying them. TyComm shows the same type of GUI corruption. Not sure if the disk file it saves was ever viewed to see if it saved valid data.

Testing for this was in beta for reference to see as the 1062's USB stack got refined - speed went somewhere near double the first effort after it was functional. Then used to make sure with reasonable care output had integrity, and improve SerMon to be a usable counterpart. That's when windows started spitting the garbage.
 
Ok, with this settings:
2021-09-28 08_50_55-Window.png
And this code:
Code:
void setup() {
 Serial.begin(9600);
 delay(10000);
 volatile uint32_t t = micros();
 const int n = 100000 * 10;
 for (int i=1; i< n + 1; i++)
    Serial.printf("%09d\n", i);
 t = micros() - t;
 Serial.printf("%d Bytes in %d us = %0.2f Megabits per second", n * 10, t, (double)n * 10 * 8 / t);
}

void loop() {}

The Output is this:
2021-09-28 08_58_57-Window.png

Reliably repeatable. As you see, nothing missing (the line-# would not match), and without delay. Again, no garbage.
 
And with this:
Code:
void setup() {
 Serial.begin(9600);
 delay(10000);
 volatile uint32_t t = micros();
 const int n = 100000 * 10;
 for (int i=1; i< n + 1; i++)
    while( Serial.availableForWrite() < 10 ) {}
    Serial.printf("%09d\n", i);
 t = micros() - t;
 Serial.printf("%d Bytes in %d us = %0.2f Megabits per second", n * 10, t, (double)n * 10 * 8 / t);
}

void loop() {}
TY works too. Way slower, but it works - again, without garbage.
Code:
10000000 Bytes in 14260881 us = 5.61 Megabits per second
The Logfile is complete, nothing is missing.

So, this is all the same topic as in the mentioned thread. You just can't write to serial in the hope the receiver is fast enough. It is not. (well, h-term is).
A delay() works too, but is suboptimal in any regard.

That "Benchmark" measures the PC. Not the Teensy.
 
Serial Monitor with availableForWrite():
Code:
000999999
001000000
10000000 Bytes in 5566463 us = 14.37 Megabits per second
But it has no logfile, so nobody knows if it worked correctly. The scrollback buffer is way too small.

As you see - again - the PC is the bottleneck. Not the Teensy. A Benschmark is totally pointless.
 
Final info:

I don't know what the special Teensy edition does. The normal, standard Arduino monitor works perfectly.
It has a large enough scrollback buffer and is not that much slower.
No garbage, everything is fine, nothing is missing (at a first glance.. can't copy & paste it - don't know why) , and this time even with the nice timestamps.
2021-09-28 10_38_33-Window.png

However, it looses the connection often and says the Teensy is offline - it's not. That's an other problem, and a bug in Teensyduino, I think.

Edit: Ah.. not enough memory for copy&paste 10MegaBytes:
Code:
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
	at java.lang.AbstractStringBuilder.<init>(AbstractStringBuilder.java:68)
	at java.lang.StringBuffer.<init>(StringBuffer.java:128)
	at sun.awt.datatransfer.DataTransferer.translateTransferableString(DataTransferer.java:952)
	at sun.awt.datatransfer.DataTransferer.translateTransferable(DataTransferer.java:1132)
	at sun.awt.windows.WDataTransferer.translateTransferable(WDataTransferer.java:219)
	at sun.awt.windows.WClipboard.setContentsNative(WClipboard.java:83)
	at sun.awt.datatransfer.SunClipboard.setContents(SunClipboard.java:106)
	at javax.swing.TransferHandler.exportToClipboard(TransferHandler.java:787)
	at javax.swing.TransferHandler$TransferAction.actionPerformedImpl(TransferHandler.java:1753)
	at javax.swing.TransferHandler$TransferAction.access$800(TransferHandler.java:1692)
	at javax.swing.TransferHandler$TransferAction$1.run(TransferHandler.java:1715)
	at javax.swing.TransferHandler$TransferAction$1.run(TransferHandler.java:1713)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
	at javax.swing.TransferHandler$TransferAction$2.run(TransferHandler.java:1730)
	at javax.swing.TransferHandler$TransferAction$2.run(TransferHandler.java:1728)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at javax.swing.TransferHandler$TransferAction.actionPerformed(TransferHandler.java:1727)
	at javax.swing.text.JTextComponent.invokeAction(JTextComponent.java:1462)
	at javax.swing.text.JTextComponent.copy(JTextComponent.java:1423)
	at javax.swing.text.DefaultEditorKit$CopyAction.actionPerformed(DefaultEditorKit.java:1326)
	at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1668)
	at javax.swing.JComponent.processKeyBinding(JComponent.java:2882)
	at javax.swing.JComponent.processKeyBindings(JComponent.java:2929)
	at javax.swing.JComponent.processKeyEvent(JComponent.java:2845)
	at java.awt.Component.processEvent(Component.java:6316)
	at java.awt.Container.processEvent(Container.java:2239)
	at java.awt.Component.dispatchEventImpl(Component.java:4889)
	at java.awt.Container.dispatchEventImpl(Container.java:2297)
	at java.awt.Component.dispatchEvent(Component.java:4711)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
	at java.lang.AbstractStringBuilder.<init>(AbstractStringBuilder.java:68)
	at java.lang.StringBuffer.<init>(StringBuffer.java:128)
	at sun.awt.datatransfer.DataTransferer.translateTransferableString(DataTransferer.java:952)
	at sun.awt.datatransfer.DataTransferer.translateTransferable(DataTransferer.java:1132)
	at sun.awt.windows.WDataTransferer.translateTransferable(WDataTransferer.java:219)
	at sun.awt.windows.WClipboard.setContentsNative(WClipboard.java:83)
	at sun.awt.datatransfer.SunClipboard.setContents(SunClipboard.java:106)
	at javax.swing.TransferHandler.exportToClipboard(TransferHandler.java:787)
	at javax.swing.TransferHandler$TransferAction.actionPerformedImpl(TransferHandler.java:1753)
	at javax.swing.TransferHandler$TransferAction.access$800(TransferHandler.java:1692)
	at javax.swing.TransferHandler$TransferAction$1.run(TransferHandler.java:1715)
	at javax.swing.TransferHandler$TransferAction$1.run(TransferHandler.java:1713)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
	at javax.swing.TransferHandler$TransferAction$2.run(TransferHandler.java:1730)
	at javax.swing.TransferHandler$TransferAction$2.run(TransferHandler.java:1728)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at javax.swing.TransferHandler$TransferAction.actionPerformed(TransferHandler.java:1727)
	at javax.swing.text.JTextComponent.invokeAction(JTextComponent.java:1462)
	at javax.swing.text.JTextComponent.copy(JTextComponent.java:1423)
	at javax.swing.text.DefaultEditorKit$CopyAction.actionPerformed(DefaultEditorKit.java:1326)
	at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1668)
	at javax.swing.JComponent.processKeyBinding(JComponent.java:2882)
	at javax.swing.JComponent.processKeyBindings(JComponent.java:2929)
	at javax.swing.JComponent.processKeyEvent(JComponent.java:2845)
	at java.awt.Component.processEvent(Component.java:6316)
	at java.awt.Container.processEvent(Container.java:2239)
	at java.awt.Component.dispatchEventImpl(Component.java:4889)
	at java.awt.Container.dispatchEventImpl(Container.java:2297)
	at java.awt.Component.dispatchEvent(Component.java:4711)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOfRange(Arrays.java:3664)
	at java.lang.String.<init>(String.java:207)
	at javax.swing.text.GapContent.getString(GapContent.java:168)
	at javax.swing.text.AbstractDocument.getText(AbstractDocument.java:770)
	at javax.swing.text.JTextComponent.getSelectedText(JTextComponent.java:1721)
	at javax.swing.plaf.basic.BasicTextUI$TextTransferHandler$TextTransferable.<init>(BasicTextUI.java:2567)
	at javax.swing.plaf.basic.BasicTextUI$TextTransferHandler.createTransferable(BasicTextUI.java:2404)
	at javax.swing.TransferHandler.exportToClipboard(TransferHandler.java:784)
	at javax.swing.TransferHandler$TransferAction.actionPerformedImpl(TransferHandler.java:1753)
	at javax.swing.TransferHandler$TransferAction.access$800(TransferHandler.java:1692)
	at javax.swing.TransferHandler$TransferAction$1.run(TransferHandler.java:1715)
	at javax.swing.TransferHandler$TransferAction$1.run(TransferHandler.java:1713)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
	at javax.swing.TransferHandler$TransferAction$2.run(TransferHandler.java:1730)
	at javax.swing.TransferHandler$TransferAction$2.run(TransferHandler.java:1728)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at javax.swing.TransferHandler$TransferAction.actionPerformed(TransferHandler.java:1727)
	at javax.swing.text.JTextComponent.invokeAction(JTextComponent.java:1462)
	at javax.swing.text.JTextComponent.copy(JTextComponent.java:1423)
	at javax.swing.text.DefaultEditorKit$CopyAction.actionPerformed(DefaultEditorKit.java:1326)
	at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1668)
	at javax.swing.JComponent.processKeyBinding(JComponent.java:2882)
	at javax.swing.JComponent.processKeyBindings(JComponent.java:2929)
	at javax.swing.JComponent.processKeyEvent(JComponent.java:2845)
	at java.awt.Component.processEvent(Component.java:6316)
	at java.awt.Container.processEvent(Container.java:2239)
	at java.awt.Component.dispatchEventImpl(Component.java:4889)
	at java.awt.Container.dispatchEventImpl(Container.java:2297)
	at java.awt.Component.dispatchEvent(Component.java:4711)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOfRange(Arrays.java:3664)
	at java.lang.String.<init>(String.java:207)
	at javax.swing.text.GapContent.getString(GapContent.java:168)
	at javax.swing.text.AbstractDocument.getText(AbstractDocument.java:770)
	at javax.swing.text.JTextComponent.getSelectedText(JTextComponent.java:1721)
	at javax.swing.plaf.basic.BasicTextUI$TextTransferHandler$TextTransferable.<init>(BasicTextUI.java:2567)
	at javax.swing.plaf.basic.BasicTextUI$TextTransferHandler.createTransferable(BasicTextUI.java:2404)
	at javax.swing.TransferHandler.exportToClipboard(TransferHandler.java:784)
	at javax.swing.TransferHandler$TransferAction.actionPerformedImpl(TransferHandler.java:1753)
	at javax.swing.TransferHandler$TransferAction.access$800(TransferHandler.java:1692)
	at javax.swing.TransferHandler$TransferAction$1.run(TransferHandler.java:1715)
	at javax.swing.TransferHandler$TransferAction$1.run(TransferHandler.java:1713)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
	at javax.swing.TransferHandler$TransferAction$2.run(TransferHandler.java:1730)
	at javax.swing.TransferHandler$TransferAction$2.run(TransferHandler.java:1728)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
	at javax.swing.TransferHandler$TransferAction.actionPerformed(TransferHandler.java:1727)
	at javax.swing.text.JTextComponent.invokeAction(JTextComponent.java:1462)
	at javax.swing.text.JTextComponent.copy(JTextComponent.java:1423)
	at javax.swing.text.DefaultEditorKit$CopyAction.actionPerformed(DefaultEditorKit.java:1326)
	at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1668)
	at javax.swing.JComponent.processKeyBinding(JComponent.java:2882)
	at javax.swing.JComponent.processKeyBindings(JComponent.java:2929)
	at javax.swing.JComponent.processKeyEvent(JComponent.java:2845)
	at java.awt.Component.processEvent(Component.java:6316)
	at java.awt.Container.processEvent(Container.java:2239)
	at java.awt.Component.dispatchEventImpl(Component.java:4889)
	at java.awt.Container.dispatchEventImpl(Container.java:2297)
	at java.awt.Component.dispatchEvent(Component.java:4711)
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space

Is there a way to increase it?
 
Very last Info:
Restartet Arduino.
Switched the timestamps off, and... tadaaa.. It was possible to copy&paste it.
Surprise.
It's pretty fast, faster than the teensy edition. No Garbage (with the while..)
Code:
000999997
000999998
000999999
001000000
10000000 Bytes in 3855678 us = 20.75 Megabits per second

I would do without the TD edition, and instead fix the bugs in the default monitor (connection loss, heap space problem).
 
@Mcu32 - indeed hTerm worked once same as yours, TyComm dropped lines in saved file.

That is a SHORT test - not running continuously for an hour of three, so TyComm never showed 'buffer garbage'

Then I added this over the posted for loop and it never worked again: for (int jj=1; jj< 10; jj++)

Went back to code as written with single for() and added code to have Teensy wait for output buffer and TyComm got everything .
From TyComm output file copied into editor and all 1 Million lines were present - much slower than 25.9 MB/sec:
Code:
000999998
000999999
001000000
10000000 Bytes in 9557541 us = 8.37 Megabits per second

Same test code below against teensy_serial is faster - no garbage - and can only assume everything was well printed:
Code:
000999998
000999999
001000000
10000000 Bytes in 5569885 us = 14.36 Megabits per second

Uncommenting the for ( jj ) to run it 10 times with teensy_sermon:
Code:
10000000 Bytes in 52366048 us = 1.53 Megabits per second
and with TyComm even worse - with disk log disabled:
Code:
10000000 Bytes in 99762272 us = 0.80 Megabits per second

The code:
Code:
void setup() {
 Serial.begin(9600);
 delay(10000);
 volatile uint32_t t = micros();
 const int n = 100000 * 10;
 //for (int jj=1; jj< 10; jj++)
 for (int i=1; i< n + 1; i++) {
    Serial.printf("%09d\n", i);
[B]    if ( !( i%50)) {
      while( Serial.availableForWrite()<500 );
    }[/B]
 }
 t = micros() - t;
 Serial.printf("%d Bytes in %d us = %0.2f Megabits per second", n * 10, t, (double)n * 10 * 8 / t);
}

void loop() {}
 
Status
Not open for further replies.
Back
Top