Teensyduino 1.60 Beta #3

Hi,

The gdb of this version unfortunately doesn't run on Ubuntu 24.10:

Code: 
folkert@snsv ~/.arduino15 $ ./packages/teensy/tools/teensy-compile/11.3.1/arm/bin/arm-none-eabi-gdb
./packages/teensy/tools/teensy-compile/11.3.1/arm/bin/arm-none-eabi-gdb: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory

That libncursesw.so.5 has been replaced by .6, .5 is no longer available for the latest ubuntu.
 
On M2 Macbook Air with Sonoma 14.6.1 and IDE 2.3.3
Tried all the shenanigans in earlier in post for win and mac but still get no security stuff:
noTeensy.png


Read security was not recommend from M2 mac but it should be possible? Oh and added: Should Teensy Loader show 1.60-beta3 vs 0.60?
 
Just reporting noticed today that issue at #27 seems to have resolved itself with no input from me except possibly upgrading to Sonoma 14.7.1
I'll be updating to Sequoia 15.1 soon and will report.
 

Attachments

  • security.png
    security.png
    761 KB · Views: 35
  • security2.png
    security2.png
    449.4 KB · Views: 33
I figured out how to rebuild newlib and libstdc++ (and nano versions), and am working on a small write-up. @Paul, do you think you’d like to test this for 1.60 or wait for 1.61? If the latter, I won't prioritize the write-up, and we can take more time. For example, I made a nano version of newlib that has C99 printf things, and a version of libstdc++ that has those "verbose termination" messages disabled with --disable-libstdcxx-verbose.
 
Let's put newlib rebuild off until at least 1.61.

After we wrap up the Black Friday Sale tomorrow, I'm going to go on a sprint to get MTP merged, and then a series of beta releases leading up to 1.60 release with MTP.

Might merge some other stuff besides MTP in the next week or two, but my main goal is to focus on MTP and only merge "small" things so we can get to a 1.60 release sooner. Everything else "large" can be considered for 1.61. But if too many other large things go in soon, we'd probably have to wait many more months before 1.60 can release.
 
Not specific to TD 1.60b3, but an updated version of my Norton 360 was automatically installed earlier this week. Running the Arduino IDE 1.8.19 + TD 1.60b3 this morning for the first time since the update, Norton decided that several of the Teensy applications were suspicious & required closer scrutiny. The good news is that all of them were deemed to be safe !!

1735148177866.png

Mark J Culross
KD5RXT
 
Is there a source repository for Teensyduino's Entropy library somewhere? Seems it doesn't function correctly when the T4.x is running at 24MHz, I'm not sure why because the hardware isn't included in the manual and I can't find anywhere to file an issue.
 
I wrote some raw TRNG (true random number generator) functions in the QNEthernet library. (They’re similar to what’s in the Entropy library.) Feel like giving those a try? You can see how they’re used in the library and in the unit tests. I’m not expecting any different behaviour, necessarily, but it could give you confidence that the issue you’re seeing is actually due to the clock frequency and not the Entropy library.

One of the reasons I wrote them is to not have to depend on the Entropy library. i.e. self-containment.

See src/security/entropy.h.
 
jmarsh said:
Is there a source repository for Teensyduino's Entropy library somewhere?
Click to expand...
On system here there is a .cpp and a .h here (for IDE 1.8.19 - IDE 2 would be in the new location:
arduino-1.8.19\hardware\teensy\avr\libraries\Entropy\Entropy.cpp

Quick scan didn't show any 'speed limit' for this ported code.
 
defragster said:
On system here there is a .cpp and a .h here (for IDE 1.8.19 - IDE 2 would be in the new location:
arduino-1.8.19\hardware\teensy\avr\libraries\Entropy\Entropy.cpp

Quick scan didn't show any 'speed limit' for this ported code.
Click to expand...
I know the source code is there, I'm asking for a repository so I can file an issue (because whoever wrote it must have access to the documentation for this hardware).
 
jmarsh said:
I know the source code is there, I'm asking for a repository so I can file an issue (because whoever wrote it must have access to the documentation for this hardware).
Click to expand...
Think you may be out of luck except to send the issue to Paul on the core?

According to the .h file and this it came from google code repo which doesn;t exist anymore but this shows that Paul updated it. But anyway here is the link: https://code.google.com/archive/p/avr-hardware-random-number-generation/downloads
 
mjs513 said:
Think you may be out of luck except to send the issue to Paul on the core?

According to the .h file and this it came from google code repo which doesn;t exist anymore but this shows that Paul updated it. But anyway here is the link: https://code.google.com/archive/p/avr-hardware-random-number-generation/downloads
Click to expand...

Whats the link that’s supposed to be under the word “this”? It shows “http://know%20the%20source%20code%20is%20there,%20I%27m%20asking%20for%20a%20repository%20so%20I%20can%20file%20an%20issue%20(because%20whoever%20wrote%20it%20must%20have%20access%20to%20the%20documentation%20for%20this%20hardware).”
 
Why is Blink.cc included in the core files? It doesn't contain any interface-related code and can permanently break compilation of a project when using the Arduino IDE (fixable only by clearing out the temporary/cached files).
 
jmarsh said:
Why is Blink.cc included in the core files? It doesn't contain any interface-related code and can permanently break compilation of a project when using the Arduino IDE (fixable only by clearing out the temporary/cached files).
Click to expand...
I’m curious, what about its presence will break the build when using the Arduino IDE?
 
shawn said:
I’m curious, what about its presence will break the build when using the Arduino IDE?,
Click to expand...
If you accidentally compile without a setup() and/or loop() function present (or the function signature is different, e.g. c++ instead of c binding) Blink.cc will end up being included in the compiled cores.a archive. Then if you fix the problem, cores.a won't get recompiled (because nothing changed in those files) and you get stuck forever with a duplicate symbol error.
 
Issues with DMAChannel and DMASettings on Teensy 4
Example code:
Code: 
#include <DMAChannel.h>

static const char string1[32] = "Example string";
static char string2[32];

void setup() {
  Serial.begin(0);
  while (!Serial);

  Serial.println("--- DMA TEST BEGIN ---");

  DMAChannel channel;
  DMASetting setting;
  memset(setting.TCD, 0, sizeof(*setting.TCD));

  setting.TCD->SADDR = string1;
  setting.TCD->SOFF = 1;
  setting.TCD->ATTR_SRC = setting.TCD->ATTR_DST = 0; // 8-bit
  setting.TCD->NBYTES = 32;
  setting.TCD->DADDR = string2;
  setting.TCD->DOFF = 1;
  setting.TCD->CITER = setting.TCD->BITER = 1;
  setting.TCD->CSR = 1;  // autostart

  arm_dcache_flush((void*)string1, sizeof(string1));
  arm_dcache_delete(string2, sizeof(string2));

  channel = setting;
  do {
    if (channel.error()) {
      Serial.printf("DMA Channel reported error, status: %08X\n", DMA_ES);
      return;
    }
  } while (!channel.complete());

  if (!strcmp(string1, string2)) {
    Serial.println("Strings are identical, DMA success");
  } else {
    Serial.println("Strings are different, DMA failure");
  }
}

void loop() {
}

Running this program with cores from git produces the following output:
Code: 
--- DMA TEST BEGIN ---
DMA Channel reported error, status: 80000008
Checking the generated assembly code reveals why:
Code: 
.text.itcm:0000018A                 STRD.W  R5, R4, [R3]    ; store TCD words 0,1
.text.itcm:0000018E                 STRD.W  R0, R1, [R3,#8] ; store TCD words 2,3
.text.itcm:00000192                 LDRD.W  R4, R0, [R2,#0x14]
.text.itcm:00000196                 LDR     R1, [R2,#0x1C]
.text.itcm:00000198                 LDR     R2, [R2,#0x10]
.text.itcm:0000019A                 STRD.W  R0, R1, [R3,#0x18] ; store TCD words 6,7 (includes CSR)
.text.itcm:0000019E                 STRD.W  R2, R4, [R3,#0x10] ; store TCD words 4,5
The TCD contents are being written to the DMA Channel registers out of order, resulting in CSR being written (which starts the DMA operation) before CITER, causing the error because BITER is not equal to CITER.

Modifying DMABaseClass::copy_tcd to use a volatile destination pointer prevents the compiler from reordering the writes:
Code: 
.text.itcm:00000186                 STR     R5, [R3]        ; store TCD word 0
.text.itcm:00000188                 STR     R4, [R3,#4]     ; store TCD word 1
.text.itcm:0000018A                 LDRD.W  R0, R1, [R2,#8]
.text.itcm:0000018E                 STR     R0, [R3,#8]     ; store TCD word 2
.text.itcm:00000190                 STR     R1, [R3,#0xC]   ; store TCD word 3
.text.itcm:00000192                 LDRD.W  R4, R0, [R2,#0x10]
.text.itcm:00000196                 LDRD.W  R1, R2, [R2,#0x18]
.text.itcm:0000019A                 STR     R4, [R3,#0x10]  ; store TCD word 4
.text.itcm:0000019C                 STR     R0, [R3,#0x14]  ; store TCD word 5
.text.itcm:0000019E                 STR     R1, [R3,#0x18]  ; store TCD word 6 (CITER/DLASTSGA)
.text.itcm:000001A0                 LDRB.W  R1, [SP,#0x78+var_74]
.text.itcm:000001A4                 STR     R2, [R3,#0x1C]  ; store TCD word 7 (CSR/BITER)
and produces the correct output from the sample code:
Code: 
--- DMA TEST BEGIN ---
Strings are identical, DMA success

Pull Request submitted: https://github.com/PaulStoffregen/cores/pull/774
 
You must log in or register to reply here.
Back
Top