PDA

View Full Version : Teensyduino 1.42 Beta #4



Paul
05-07-2018, 01:40 PM
Here is a fourth beta test for Teensyduino 1.42.

The main new feature is a "Teensy" section in the Tools > Ports menu
which tries to show Teensy in all modes, not just Serial. New native
(no Java serial library) serial monitor code is also with these ports.


Old beta download links removed. Please use the latest version:
https://www.pjrc.com/teensy/td_download.html


Changes since Teensyduino 1.42-beta3 (https://forum.pjrc.com/threads/50254-Teensyduino-1-42-Beta-3)

Teensy 3.5 now supports use of 256K RAM
EthernetClient fix for forced connection close
Small speedup to analogWrite for DAC pins
Fix DMAChannel transferSize() on Teensy LC
Fix FTM_CONF register bitfield defs
Update ADC library (Pedro Villanueva)
Audio: Add freeverb mono & stereo
Audio: Granular pitch shift & freeze effects (Bleep Labs)
Audio: envelope status functions
Audio: Fixes to waveform object
Audio: Add variable triangle waveform
Audio: Add modulated waveform, support for freq & phase modulation
Audio: Add simple amp/switch object
Audio: Add PDM input
Update OneWire, very minor changes
PS2Keyboard: add UK & Spanish layouts
TimeAlarms: minor fixes
USBHost_t36: Joystick fixes (KurtE)
Macintosh build now uses 64 bits

manitou
05-07-2018, 02:36 PM
Here is a fourth beta test for Teensyduino 1.42.


Changes since Teensyduino 1.42-beta3 (https://forum.pjrc.com/threads/50254-Teensyduino-1-42-Beta-3)

Teensy 3.5 now supports use of 256K RAM


OK, 256KB RAM available on T3.5!! I successfully re-ran tests described at
https://forum.pjrc.com/threads/49522-Does-the-Teensy-3-5-have-256K-of-RAM

;)

PaulStoffregen
05-07-2018, 08:54 PM
@Defragster - Please let me know if you can still get multiple instances of teensy_ports.exe on Windows 10? I'm hoping this bug is gone... but if not, I'll need a little help with reproducing it and testing possible fixes.

defragster
05-08-2018, 12:08 AM
@Defragster - Please let me know if you can still get multiple instances of teensy_ports.exe on Windows 10? I'm hoping this bug is gone... but if not, I'll need a little help with reproducing it and testing possible fixes.

I have installed this Beta4 - only done minimal single Teensy code so far but no problem. So nice that recurring callback debug spew in the IDE window is gone. (though I see it filling TLoader Verbose)

I was getting some severe new grief yesterday when I was testing the faulting RAM cross boundary checking. System was hung 'app not responding', but I couldn't get feedback to show what the system was doing - and that code is old news now. Will need to rewrite that to the new core to test again. I did have twin IDE's up - one on T_3.6 and the other to a T_LC - and the JAVA system got twisted.

I just opened a second IDE to T_3.6 - ( First on T_LC ) - hitting "Tools" menu takes some ~8 seconds to display! With TLoader Verbose output in the process. Of course I set the TeensyPort to T_3.6 Com8 - then hit Compile before I opened the teensy_Sermon but then I opened T_sermon during compile waiting now for compile to complete to see what happens . . . nothing good:


Teensy did not respond to a USB-based request to enter program mode.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.
It will not get back in sync. It will program on Button or compile - but never get output to the T_sermon? Quick test with TyCommander shows it to work as expected. Closing that and open T_sermon ( also takes 8 seconds ) - then it never displays anything?
Here is what I have for Verbose - as ZIP since it is 1.44MB:
13758

To those on Win 10 - the new Release Version 1803 is out - the new 6 month update from ~May 30. I did not have to manually unblock download on install - but the system did pop up a cute page that I could just hit 'Run' on:
13757
It ran fine with no intervention from Windows Defender ( or my Malwarebytes program ).

defragster
05-08-2018, 02:54 AM
Ide's T_sermon's were busted even after closing TLoader - closed IDE's and found these lurking … I count 32 copies of teensy_ports.exe:
13759

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?

defragster
05-08-2018, 03:22 AM
Trying to do a clean and proper start:
I closed the teensy_ports down and restarted IDE's - some other residual part in memory - Tools menu still 8 second to open - but Tools / Ports does not show 'Teensy' - just "Serial ports".

TaskMan shows this:
13760

Closed Teensy.exe and did end task on the two instances of JAVA - no Windows restart.

Opened IDE #1 to T_3.6 - Teensy_Port is correct [COM8] - compile and upload!

Opened IDE #2 to T_LC - Selected Teensy_Port first [COM11] - change to T_LC - compile and upload!


So far problem seems to only occur when teensy_sermon holds the port open when TLoader attempts to program.

'Tools' Menu item now Instant - not 8 second delayed.

Problem only on initial compile? I can Close T_sermon - start compile - open T_sermon and that works … though it had switched the T_3.6 to IDE_SerMon not teensy_serialmon. And now with two IDE's only one has teensy_ports.exe associated.

Operation seems good - except that oddity:
13761

<edit>: Just noted that while still sitting open as above - both IDE's and Teensy's are online. Only these two messages have been added since the attached snapshot just above when I saved the log:

20:19:25.174 (loader): Log saved to the file 'C:\tmp\TD_142\b4\td142b4_post6.txt'.
20:21:29.841 (ports 1): got command: "list"


i.e. :: there are no recurring '(ports...:callback...' messages.

defragster
05-09-2018, 08:34 AM
Came back to just the T_LC and it was working - still in the broken state above.

Closed the T_3.6 IDE to get current code as I'm using IDE to edit just now. Re-opened 2nd IDE to get to T_3.6 and the T_LC T_sermon stopped working. The 8 second wait for 'Tools' was back and there was no 'Teensy' under Ports.

I had cleared the TLoader verbose log after prior post - but it was still open. Here is the log since then in case it shows where the crossing IDE's got lost - had to zip as it is 418KB.
13766

Closed both IDE's and there are 7 orphaned teensy_ports.exe again in TaskMan.

I cleared log and TLoader was still open - this seems to show where I closed those:

01:16:26.404 (loader): remote connection 3024 closed
01:16:28.050 (loader): remote connection 2280 closed
01:16:29.741 (loader): remote connection 3212 closed
01:16:30.838 (loader): remote connection 2792 closed
01:16:31.829 (loader): remote connection 1652 closed
01:16:32.615 (loader): remote connection 3224 closed
01:16:33.405 (loader): remote connection 1348 closed
> I saved the rest of this 7b log [can provide] - but I need to reboot as T_LC code running differently now and the recurring '...callback...' is still not showing as it did for post #4, though otherwise properly re-opened 2 IDE's and compile/upload/T_sermon working.

The sketch is trapping Memory Fault isr()'s - so USB may be going ODD and I have to Button push to upload. Simple ugly sketch if it matters/helps: 13767

brendanmatkin
05-09-2018, 08:34 PM
MacOS 10.13.3, Arduino 1.8.5, Teensy 3.6, USB Type: Serial, Teensyduino 1.42-beta4

Serial Monitor no longer skips prints but it stops responding after an apparently random number of loops (or time?). After anywhere from 30 to around 2000 loops it stops. The teensy is not crashing - but serial monitor output just stops and will not start again until power cycle or upload new code.

USB Type: Raw HID still prints to serial monitor as expected (that is, it works).




void setup() {
Serial.begin(9600);
delay(2000);
Serial.println("welcome");
pinMode(LED_BUILTIN, OUTPUT);
}
int i = 0;
bool led = false;
uint32_t counter;
void loop() {
i++;
Serial.println(i);
delay(10);
digitalWrite(LED_BUILTIN, led);
counter++;
if (counter%10==0)led = !led;
}

defragster
05-10-2018, 12:01 AM
Windows 10 can run for hours with T_sermon getting 8-9+ MB's in a 10 second interval from BOTH T_LC and T_3.6 with a 5 second pause between those 10 second runs. It seems very fast and robust and no dropped data or issues apparent.

I've moved the two Teensys from hub to port and hub to hub and I need to reselect the Tools/Port and re-open T_sermon - even though the COM# doesn't change. But no problems.

The only way I see a problem is {posted above}: Open IDE, Select Board, Start Compile … while waiting … open T_sermon before compile completes.

<edit> Just to confirm after running both units with high USB output for hours they ran fine and when both IDE's/TLoader were closed there were no sticking teensy_ports parts.

KurtE
05-10-2018, 08:24 PM
Started playing with this new release with the T3.5 with more memory.

Trying out my ili9341_t3n with frame buffer. It runs on the T3.5, but there is an issue when I try doing Async (DMA updates).

Looks like I need to do some debugging! Also I already knew there would be issues with SPI1/SPI2 on T3.5 due to only one DMA Source per each of these... May have to refer back to the work I did on SPI library to remember differences on how T3.6 worked from T3.5...

Should also mention: TyCommander does not work with the T3.5 new expanded memory.

defragster
05-10-2018, 10:52 PM
Paul Looking after an AnalogWrite question I saw the code in this post (https://forum.pjrc.com/threads/52182-analogWrite-only-works-on-PWM-slots-(Teensy-2-0)?p=178613&viewfull=1#post178613)

In case of MAX value on Teensy3 analogwrite the value is set digital HIGH … then the pinMode is set to output - it seems that won't work the first time?


Frank B gave a Pull request for swapping this in 3 places : https://github.com/PaulStoffregen/cores/pull/276

bicycleguy
05-11-2018, 09:03 PM
iMac macOS 10.13.4, Arduino 1.8.5, T3.6, TL 1.42-beta4

no more 64bit macOS nagging Ya!

No problems so far with lots of Arduino terminal stuff.

vladn
05-13-2018, 04:56 PM
Something happened to the analogRead() in the beta4 - reads zeroes (works fine under beta3). I need to investigate further.

vladn
05-13-2018, 09:03 PM
analogRead() is OK, there is some memory corruption that did not show up in the previous versions (41 42.b3), still need to investigate...
I think I narrowed it down to sprintf not accepting %.2f spec for a floating number in the beta4. If I do explicit integer conversion and then call sprintf - things work OK.

KurtE
05-13-2018, 09:36 PM
Should also mention: TyCommander does not work with the T3.5 new expanded memory.
Fixed :D, can download latest version (now about 3 hours old) from: https://bintray.com/koromix/tytools/tytools#files

Thanks Niels!

vladn
05-13-2018, 11:12 PM
sprintf not accepting %.2f spec for a floating number in the beta4.

Could someone please verify this simple sketch on 3.5 on beta4 with expanded RAM. It works just fine on my 3.6 and 3.2, but fails specifically on 3.5:


void setup() {
Serial.begin(115200);
delay (100);
}

void loop() {
float v = 4.98;
char buf[64];
sprintf (buf, "%.2f", v);
Serial.println ("---");
Serial.println (v);
Serial.println (buf);
delay (1000);
}

tonton81
05-13-2018, 11:13 PM
on Teensy 3.5 I get:


---
4.98
4.98
---
4.98
4.98
---
4.98
4.98
---
4.98
4.98


EDIT, nevermind im on 1.42 beta3....

KurtE
05-13-2018, 11:23 PM
T3.5 with current beta...

---
4.98
0.00
---
4.98
0.00
---
4.98
0.00
---

Ran same code on T3.6... Current beta..

---
4.98
4.98
---
4.98
4.98
---
4.98
4.98
---
4.98
4.98

vladn
05-13-2018, 11:30 PM
This code fails only with a combination of beta4 and T3.5. Every other combination of software version and Teensy type give the correct result. Something to do with a memory expansion ?

defragster
05-13-2018, 11:55 PM
Odder still - with IDE 1.85 and TD1.42b4. As noted - works on T_3.6 but I see the same fail on my T_3.5.

I made a simple edit looking to find a way to the issue ... it gets odder still moving the locals to global:

4.98
2.48
---
4.98
2.48

Using this code - the T_3.6 give same expected result and the T_3.5 shows the above:

float v = 4.98;
char buf[64];
void loop() {
sprintf (buf, "%.2f", v);
Serial.println ("---");
Serial.println (v);
Serial.println (buf);
delay (1000);
}

<edit>:
Making this const :: const float v = 4.98; takes it back to the Zero display result instead of '2.48' above.

Also this prints 0.00 :: sprintf (buf, "%.2f", 42.3);

These two buf mods print properly:
dtostrf(42.3, 10,4, buf);
dtostrf(v, 10,4, buf);

PaulStoffregen
05-14-2018, 02:59 PM
Confirmed, I'm also getting this on Teensy 3.5.

---
4.98
0.00

Very strange. Will investigate soon....

KurtE
05-14-2018, 03:07 PM
Could new memory size have issue of location of stack vs heap? Maybe sprint uses heap?

Frank B
05-14-2018, 03:28 PM
I get the same results with T3.5.

I wonder why - the same compiler, same libraries, same sprintf..

tonton81
05-14-2018, 03:32 PM
In beta3 it works, so you don't need to look too far back to find the problem at least
It's confirmed working here on beta3 of 1.42

Frank B
05-14-2018, 03:57 PM
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

vladn
05-14-2018, 04:31 PM
Works for me, thanks much.

Frank B
05-14-2018, 07:47 PM
No problem, it was fun to look for the bug.

KurtE
05-14-2018, 08:16 PM
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 ;)

defragster
05-14-2018, 08:19 PM
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

Frank B
05-14-2018, 08:26 PM
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?

defragster
05-14-2018, 08:52 PM
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 (https://github.com/Koromix/tytools/issues/26) - 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.

PaulStoffregen
05-14-2018, 09:08 PM
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.

Frank B
05-14-2018, 09:24 PM
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.. :)

Jantje
05-15-2018, 05:04 PM
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

tonton81
05-15-2018, 05:07 PM
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

Jantje
05-15-2018, 05:22 PM
@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

Jantje
05-15-2018, 05:25 PM
Strange, now it is working fine. It lookes like the teensyloader missed the teensy2++ at startup and did not recover.

tonton81
05-15-2018, 05:33 PM
theres only one loader open for all IDE instances
don't open more than 1 loader, the IDE shouldnt :)

Jantje
05-15-2018, 06:50 PM
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.

defragster
05-15-2018, 07:02 PM
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.

Jantje
05-15-2018, 07:26 PM
@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.

Jantje
05-15-2018, 08:46 PM
Here you can see the bootloader issue I see quite often and the failure to teensy2++.

defragster
05-15-2018, 09:02 PM
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.

Jantje
05-16-2018, 01:34 PM
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

PaulStoffregen
05-17-2018, 01:43 AM
@Defragster - I tried but failed to reproduce this problem.



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?


https://www.youtube.com/watch?v=exfb_ulKjZ8

defragster
05-17-2018, 02:43 AM
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.

PaulStoffregen
05-17-2018, 12:05 PM
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.

PaulStoffregen
05-17-2018, 12:13 PM
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?

Jantje
05-17-2018, 01:42 PM
Hopefully just "port" will do?
Sure it will :-)

PaulStoffregen
05-17-2018, 03:12 PM
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.