Teensyduino 1.55 Beta #1

Status
Not open for further replies.
Okay that answers that!

It HAS been uploading from the Encrypted .eHex this whoie time!

Code:
---	hab_csf
6000A000 - 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  : ........ ........
...	 6 duplicate line(s) removed.
6000A070 - 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  : ........ ........

Did a File / Open - deleted the .eHex while there and then selected the .hex

The above shows now a ZERO'd csf region! As on a 'normal' T_4.0. This has always been 'non-zero' before on the Fused T4b.
Code:
extern const uint32_t hab_csf[]; // placeholder for HAB signature
// ...
MemoryHexDump(Serial, hab_csf , 128, true, "---\thab_csf\n");

Not sure if there is another indicator of running HEX versus EHEX ... but that works.

Upload from .eHex shows:
Code:
---	hab_csf
6000A000 - D4 00 30 40 BE 00 0C 00  03 17 00 00 00 00 00 30  : ..0@.... .......0
6000A010 - CA 00 0C 00 01 C5 00 00  00 00 04 44 CA 00 14 00  : ........ ...D....
6000A020 - 00 C5 00 00 00 00 06 28  60 00 10 00 00 00 90 00  : .......( `.......
6000A030 - D7 01 13 40 E1 01 0F 21  00 00 00 00 01 00 00 03  : ...@...! ........
6000A040 - C3 04 4F DD E2 B3 7C 9D  07 DE F1 A7 75 44 26 22  : ..O...|. ....uD&"
6000A050 - B8 51 2B 03 39 E0 A0 6B  BE 0B 32 93 69 B0 90 6B  : .Q+.9..k ..2.i..k
6000A060 - D9 D0 F6 D0 F4 8D D3 DD  13 71 02 9A D8 29 4B 51  : ........ .q...)KQ
6000A070 - CA 63 35 45 C1 5A EB D5  46 2F EF AD 98 53 94 53  : .c5E.Z.. F/...S.S
 
And does it encrypt additional flash (qspi), too? I guess no,

Indeed this only encrypts code in flash memory. Only the portion of the chip containing program code is encrypted. The rest of the flash chip used for EEPROM emulation and LittleFS (and maybe other things... as I recall you wanted to do a key-value settings system) is all accessed normally, even from the same chip where encryption is used for code.

It's not used at all for other QSPI flash, like you would add to the bottom of Teensy 4.1.


because encyption needs additional code - right (or is it possible in hardware)? Do you think it is possible to add this?
Does the decryption need time - is it as fast as before?

I am planning to add encryption support to LittleFS later this year, or maybe early 2022. It will be completely different. The chip has 2 hardware encryption engines. This code security stuff is using the "BEE" hardware (which only does decryption). When LittleFS gets encryption support, it will use the "DCP" hardware (which does both encryption & decryption). While both support AES128 cipher, the way they work is completely different.

The security model and key management needed for filesystem storage is also completely different.


Does it keep littlefs files on new uploads? (i've seen no mention, so I assume, no?)

Actually yes. Bootloader version 1.07 preserves flash beyond 512K in standard mode or 1M in secure mode (after the final lock sketch has been run to forever lock the chip to only run encrypted code). Of course, if you upload a program larger than 512K to an unlocked board, the flash is erased in 64K blocks on an as-needed basis. So if you upload a 513K program, 576K of flash is erased. If you upload a tiny program, a minimum of 512K is always erased. Or 1M minimum if secure mode has been permanently locked.
 
Not sure if there is another indicator of running HEX versus EHEX ... but that works.

The Verify Sketch is meant to be the conclusive test whether or not your Teensy is running with encryption.

screenshot.png

Even if you do something like rename a .EHEX file to .HEX and upload it, this will actually check whether the encryption engine is active and if program really is running from within the configured region it actually is decrypting. It doesn't check which file you uploaded, but actually checks if the final result is correct while running.
 
The Verify Sketch is meant to be the conclusive test whether or not your Teensy is running with encryption.

...

Even if you do something like rename a .EHEX file to .HEX and upload it, this will actually check whether the encryption engine is active and if program really is running from within the configured region it actually is decrypting. It doesn't check which file you uploaded, but actually checks if the final result is correct while running.

Opps - I saved that sketch - but I didn't read it. I see it has various stepwise checks to confirm all is right.

But I had already coded the csf[] hex dump expecting to see that go non-zero.

And indeed it did - but always ... Now I see that indicated it was always uploading the .eHex file
 
Sorry guys, I have been missing in action.

But I did pick up the package this morning and so far with one chip I did create the key file.
Note: I was not sure if I clicked correctly at first as I did not get any indication that anything happened.

But found file in the right spot.

I then clicked the next button and downloaded the sketch to set the fusses...

I then ran the verify program:
Code:
Verify secure code is running properly

Pass: Bus Encryption Engine is active
Pass: Encryption region starts at proper address
Pass: Program data is entirely within encrypted region
Pass: title_function() is within encrypted region

All Tests Passed.  :-)


And if I run the verify on some random T4: Get the blinking...
Code:
Verify secure code is running properly

Fail: Bus Encryption Engine is not active
Fail: Encryption region starts at wrong address
Fail: Program data is not within encrypted region
Fail: title_function() is not in encrypted region


Will start doing other tests. But one thing I noticed with the beta chip, is it appears to be running hotter than the other T4 I plugged in. Will check that out more tomorrow
 
@Kurt ...
When grabbing the T4b here I noticed it felt warmer than expected - hadn't gotten as far as putting a measure to it.

Look in the console indicated BUILD dir for .hex and .ehex?

Or use TeensyLoader and File/Open ... it will have that folder defaulted and see if both versions of 'VerifySecure' are there?

Took a look at VerifySecure.ino and had idea for another test to verify that 'data' also in encrypted region - and it is:
Code:
PROGMEM char [B]title_text[/B][] = "Verify secure code is running properly";

FLASHMEM void title_function() {
  Serial.println( [B]title_text[/B] );
...

from ...\AppData\Local\Temp\arduino_build_129497\VerifySecure.ino.sym
Code:
60001b0c g     O .text.progmem	00000027 title_text
...
60001674 g     F .text.code	0000002c title_function()

Whole Code:
Code:
bool ok = true;

PROGMEM char title_text[] = "Verify secure code is running properly";

FLASHMEM void title_function() {
  Serial.println( title_text );
  Serial.println();
}

extern "C" uint32_t _sdata, _edata, _sdataload; /* special linker symbols */

void setup() {
  while (!Serial) ; // wait for serial monitor
  pinMode(13, OUTPUT);

  title_function();
  
  if ((IOMUXC_GPR_GPR11 & 0x100) == 0x100) {
    Serial.println("Pass: Bus Encryption Engine is active");
  } else {
    Serial.println("Fail: Bus Encryption Engine is not active");
    ok = false;
  }

  uint32_t begin_address = IOMUXC_GPR_GPR18 & ~0x3FF;
  if (begin_address == 0x60001400) {
    Serial.println("Pass: Encryption region starts at proper address");
  } else {
    Serial.println("Fail: Encryption region starts at wrong address");
    ok = false;
  }

  uint32_t end_address = IOMUXC_GPR_GPR19 & ~0x3FF;
  uint32_t data_end = (uint32_t)&_sdataload + (uint32_t)&_edata - (uint32_t)&_sdata;
  if (data_end <= end_address) {
    Serial.println("Pass: Program data is entirely within encrypted region");
  } else {
    Serial.println("Fail: Program data is not within encrypted region");
    ok = false;
  }

  uint32_t title_address = ((uint32_t)&title_function) & ~1;
  if (title_address >= begin_address && title_address < end_address) {
    Serial.println("Pass: title_function() is within encrypted region");
  } else {
    Serial.println("Fail: title_function() is not in encrypted region");
    ok = false;
  }

  if ((uint32_t)title_text >= begin_address && (uint32_t)title_text < end_address) {
    Serial.println("Pass: title_text[] is within encrypted region");
  } else {
    Serial.println("Fail: title_text[] is not in encrypted region");
    ok = false;
  }
  // TODO: check HAB version and HAB logfile status

  Serial.println();
  if (ok) Serial.println("All Tests Passed.  :-)");
  digitalWrite(13, HIGH);
}

void loop() {
  delay(125);
  if (!ok) digitalToggle(13); // LED blinking indicates failure
}

Another random test could be:
Code:
  extern const uint32_t hab_csf[768]; // placeholder for HAB signature
  uint jj=0;
  for ( uint ii=0; ii<sizeof(hab_csf)/sizeof(hab_csf[0]); ii++ ) jj+=hab_csf[ii];
  if ( jj ) Serial.print( "Code Encrypted" );
 
Have two BARE T_4.0's here
#1 : some production board
#2 : Unlocked, UNfused beta T_4.0

Both hanging off hub on desk on a 1ft USB cable a few inches apart and Fused Beta it some 8°C HOTTER:

#1 unit : runs to 50/52 °C

#2 unit : runs to 58/60 °C when uploaded with .eHex or .hex

The sketch uses : github.com/KurtE/MemoryHexDump

In addition to TEMP test in loop() ... Incorporated the extended encrypt PASS tests - so far either ALL PASS or ALL FAIL. Does HexDump and Memory info, also includes location and size of usable 'ITCM unused RAM filler' and CallReport testing::
Code:
// https://forum.pjrc.com/threads/33443-How-to-display-free-ram
#include <MemoryHexDump.h>  // https://github.com/KurtE/MemoryHexDump

uint32_t *ptrFreeITCM;  // Set to Usable ITCM free RAM
uint32_t  sizeofFreeITCM; // sizeof free RAM in uint32_t units.
extern unsigned long _stextload;
extern char _stext[], _etext[], _sbss[], _ebss[], _sdata[], _edata[],
       _estack[], _heap_start[], _heap_end[], _itcm_block_count[], *__brkval;
float myTemp;
void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
  while (!Serial);
  if ( CrashReport) Serial.print( CrashReport);
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  if ( CrashReport ) Serial.print ( CrashReport );
  myTemp = tempmonGetTemp();
  Serial.printf( "\n\tdeg  C=%f\t F_CPU=%u\n" , myTemp, F_CPU_ACTUAL );
  memInfo();
  getFreeITCM();

  extern const uint32_t hab_csf[768]; // placeholder for HAB signature
  Serial.println();
  //dumpRam(Serial, 0x60000000 + ptrFreeITCM - 1024, 1024);
  //  Serial.println((uint32_t)&_stextload + (uint32_t)&_etext, HEX);
  MemoryHexDump(Serial, hab_csf , 128, true, "---\thab_csf\n");
  MemoryHexDump(Serial, ptrFreeITCM - 1024, 128, true, "---\tITCM used\n");
  MemoryHexDump(Serial, ptrFreeITCM, sizeofFreeITCM * sizeof(uint32_t), true, "---\tITCM filler to DTCM\t test 3 \n");
  MemoryHexDump(Serial, (uint8_t *)0, 128, true, " ITCM Start: \n");

  isEncrypt();
}


void loop() {
  float testTemp = tempmonGetTemp() - myTemp;
  if (  (1.0 < testTemp || -1.0 > testTemp) ) {
    myTemp = tempmonGetTemp();
    Serial.printf( "\tdeg  C=%f\n" , myTemp );
    delay(500);
  }

}


#define printf Serial.printf

void memInfo () {
  constexpr auto RAM_BASE   = 0x2020'0000;
                              constexpr auto RAM_SIZE   = 512 << 10;
                              constexpr auto FLASH_BASE = 0x6000'0000;
#if ARDUINO_TEENSY40
  constexpr auto FLASH_SIZE = 2 << 20;
#elif ARDUINO_TEENSY41
  constexpr auto FLASH_SIZE = 8 << 20;
#endif

  // note: these values are defined by the linker, they are not valid memory
  // locations in all cases - by defining them as arrays, the C++ compiler
  // will use the address of these definitions - it's a big hack, but there's
  // really no clean way to get at linker-defined symbols from the .ld file

  auto sp = (char*) __builtin_frame_address(0);

  printf("_stext        %08x\n",      _stext);
  printf("_etext        %08x +%db\n", _etext, _etext - _stext);
  printf("_sdata        %08x\n",      _sdata);
  printf("_edata        %08x +%db\n", _edata, _edata - _sdata);
  printf("_sbss         %08x\n",      _sbss);
  printf("_ebss         %08x +%db\n", _ebss, _ebss - _sbss);
  printf("curr stack    %08x +%db\n", sp, sp - _ebss);
  printf("_estack       %08x +%db\n", _estack, _estack - sp);
  printf("_heap_start   %08x\n",      _heap_start);
  printf("__brkval      %08x +%db\n", __brkval, __brkval - _heap_start);
  printf("_heap_end     %08x +%db\n", _heap_end, _heap_end - __brkval);
#if ARDUINO_TEENSY41
  extern char _extram_start[], _extram_end[], *__brkval;
  printf("_extram_start %08x\n",      _extram_start);
  printf("_extram_end   %08x +%db\n", _extram_end,
         _extram_end - _extram_start);
#endif
  printf("\n");

  printf("<ITCM>  %08x .. %08x\n",
         _stext, _stext + ((int) _itcm_block_count << 15) - 1);
  printf("<DTCM>  %08x .. %08x\n",
         _sdata, _estack - 1);
  printf("<RAM>   %08x .. %08x\n",
         RAM_BASE, RAM_BASE + RAM_SIZE - 1);
  printf("<FLASH> %08x .. %08x\n",
         FLASH_BASE, FLASH_BASE + FLASH_SIZE - 1);
#if ARDUINO_TEENSY41
  extern uint8_t external_psram_size;
  if (external_psram_size > 0)
    printf("<PSRAM> %08x .. %08x\n",
           _extram_start, _extram_start + (external_psram_size << 20) - 1);
#endif
  printf("\n");

  auto stack = sp - _ebss;
  printf("avail STACK % 8d b % 5d kb\t<<RAM1\n", stack, stack >> 10);

  auto heap = _heap_end - __brkval;
  printf("avail HEAP  % 8d b % 5d kb\t<<RAM2\n", heap, heap >> 10);

#if ARDUINO_TEENSY41
  auto psram = _extram_start + (external_psram_size << 20) - _extram_end;
  printf("avail PSRAM % 8d b % 5d kb\n", psram, psram >> 10);
#endif
}


uint32_t  SizeLeft_etext;
FLASHMEM
void   getFreeITCM() { // end of CODE ITCM, skip full 32 bits
  Serial.println("\n\n++++++++++++++++++++++");
  SizeLeft_etext = (32 * 1024) - (((uint32_t)&_etext - (uint32_t)&_stext) % (32 * 1024));
  sizeofFreeITCM = SizeLeft_etext - 4;
  sizeofFreeITCM /= sizeof(ptrFreeITCM[0]);
  ptrFreeITCM = (uint32_t *) ( (uint32_t)&_stext + (uint32_t)&_etext + 4 );
  printf( "Size of Free ITCM in Bytes = % u\n", sizeofFreeITCM * sizeof(ptrFreeITCM[0]) );
  printf( "Start of Free ITCM = % u [ % X] \n", ptrFreeITCM, ptrFreeITCM);
  printf( "End of Free ITCM = % u [ % X] \n", ptrFreeITCM + sizeofFreeITCM, ptrFreeITCM + sizeofFreeITCM);
  for ( uint ii = 0; ii < sizeofFreeITCM; ii++) ptrFreeITCM[ii] = 1;
  uint jj = 0;
  for ( uint ii = 0; ii < sizeofFreeITCM; ii++) jj += ptrFreeITCM[ii];
  printf( "ITCM DWORD cnt = % u [#bytes=%u] \n", jj, jj * 4);
}

// https://forum.pjrc.com/threads/33443-How-to-display-free-ram?p=275013&viewfull=1#post275013
extern char *__brkval;

int freeram() {
  return _heap_end - __brkval;
}

PROGMEM char title_text[] = "Verify secure code is running properly";

FLASHMEM void title_function() {
  Serial.println( title_text );
  Serial.println();
}

//extern "C" uint32_t _sdata, _edata, _sdataload; /* special linker symbols */
extern "C" uint32_t _sdataload; /* special linker symbols */
extern const uint32_t hab_csf[768]; // placeholder for HAB signature

int isEncrypt() {
  int ok=0;
  title_function();
 
  if ((IOMUXC_GPR_GPR11 & 0x100) == 0x100) {
    Serial.println("Pass: Bus Encryption Engine is active");
  } else {
    Serial.println("Fail: Bus Encryption Engine is not active");
    ok--;
  }

  uint32_t begin_address = IOMUXC_GPR_GPR18 & ~0x3FF;
  if (begin_address == 0x60001400) {
    Serial.println("Pass: Encryption region starts at proper address");
  } else {
    Serial.println("Fail: Encryption region starts at wrong address");
    ok--;
  }

  uint32_t end_address = IOMUXC_GPR_GPR19 & ~0x3FF;
  uint32_t data_end = (uint32_t)&_sdataload + (uint32_t)&_edata - (uint32_t)&_sdata;
  if (data_end <= end_address) {
    Serial.println("Pass: Program data is entirely within encrypted region");
  } else {
    Serial.println("Fail: Program data is not within encrypted region");
    ok--;
  }

  uint32_t title_address = ((uint32_t)&title_function) & ~1;
  if (title_address >= begin_address && title_address < end_address) {
    Serial.println("Pass: title_function() is within encrypted region");
  } else {
    Serial.println("Fail: title_function() is not in encrypted region");
    ok--;
  }

  if ((uint32_t)title_text >= begin_address && (uint32_t)title_text < end_address) {
    Serial.println("Pass: title_text[] is within encrypted region");
  } else {
    Serial.println("Fail: title_text[] is not in encrypted region");
    ok--;
  }
   uint jj = 0;
  for ( uint ii = 0; ii < sizeof(hab_csf) / sizeof(hab_csf[0]); ii++ ) jj += hab_csf[ii];
  if ( jj ) {
    Serial.println("Pass: csf not Zero");
  } else {
    Serial.println("Fail: csf is Zero");
    ok--;
  }
 // TODO: check HAB version and HAB logfile status

  Serial.println();
  if (0==ok) Serial.println("All Tests Passed.  :-)");
  else printf(" %d Tests failed.  :-(", -ok);
  return ok;
}
 
RE p#57 code - the loop() used delay to minimize spew - but that pulsed the temp.
This dropped temps on BOTH T_4.0's - but still ~8 °C diff - both same .hex {room temp 71°F}:
#1 unit - production: runs to 46/48 °C >> [in fan air stream drops to 30/32]
deg C=46.792454
deg C=48.113209
deg C=46.792454
deg C=45.471699
#2 unit - lock beta : runs to 55/56 °C >> [in fan air stream drops to 39/41]
deg C=56.818180
deg C=55.404041

This version doesn't delay:
Code:
uint32_t someTime=millis();
void loop() {
  float testTemp = tempmonGetTemp() - myTemp;
  if ( (millis()-someTime > 1000 ) && (1.0 < testTemp || -1.0 > testTemp) ) {
    someTime=millis();
    myTemp = tempmonGetTemp();
    Serial.printf( "\tdeg  C=%f\n" , myTemp );
  }
}

Code storage info:
Memory Usage on Teensy 4.0:
FLASH: code:29776, data:7344, headers:8956 free for files:1985540
RAM1: variables:17088, code:26152, padding:6616 free for local variables:474432
RAM2: variables:12384 free for malloc/new:511904

Perhaps adding LFS PROG Integrity to this kitchen sink monitor is next to test Flash survival ... while monitoring ... Then maybe TSET update might work to get out of IDE

To Build and select without grief in Beta 1: - esp when switching between Beta and non beta ...
> IDE Ctrl+R/Verify
> Button press NOW for .eHex
> For .hex :: TLoader : File/Open
-> in open FILE dialog click the .eHex version and DELETE
-->> must delete or it will be used even if .hex selected
-> then click .hex and OPEN
> Button press NOW for .hex
 
Bootloader

Paul, great news!

The loader shows version 1.05 - is that OK?
Code:
08:35:38.778 (loader): Device came online, code_size = 8126464
08:35:38.778 (loader): Board is: Teensy 4.1 (IMXRT1062), version 1.05
Or, do I have to force the update somehow?
 
@Frank - the Lockable Beta units should have :: 23:29:18.817 (loader): Board is: Teensy 4.0 (IMXRT1062), version 1.07
> here I got have a black hand penned 'lock' on the backside over 4.0 silkscreen

Current production bootloader - with Fuses Factory Locked have :: 22:16:39.152 (loader): Board is: Teensy 4.0 (IMXRT1062), version 1.05

Seems like that board is not a Beta Lockable Test board? Shipping error ? ...


Dropped LFS integrity PROG.ino into 'sink' folder

Indeed (as Mike found) on Lock Beta T_4.0 PROG LFS survives reprogramming!

It does not on older production T_4

Both running same .hex and TEMP diff still looks like 8°C. 50 on production and 58 on Beta Lock.
 
No, did not know that 1.07 is for beta boards only.
I don't have such a board.

Will the other boards get the update (for files in flash), too?
 
No, did not know that 1.07 is for beta boards only.
I don't have such a board.

Will the other boards get the update (for files in flash), too?

Opps - thought maybe you got a beta package with 'great news!' ...

Word on hope for bootloader update to older units is for Paul to say what might work ...
 
No, I don't have much time to participate in the beta test at the moment anyway.
An update re: keeping flash for older boards would be great.

I know, that an update would involve some risks.
 
No, did not know that 1.07 is for beta boards only.
I don't have such a board.

Will the other boards get the update (for files in flash), too?

Frank - Tim

Think somewhere in this thread Paul mentioned that you can still use FuseWrite with Production Boards but can not do the final step, i.e., totally lock the T4. Ok found it - its in the very first post:
Standard Teensy 4.0 made after June 2021 can also run encrypted programs, but the final secure lock mode can't be set. Running encrypted programs that way is akin to locking your door but leaving the window open. Still, might be worth trying. Anyone can open this window, create their own key.pem file, and get .EHEX files created.
 
@defragster

Ran your sketch in post 57 (no delays) on the secure T4 but seeing the same temperatures on the secured T4. In a cool room;
Code:
Range: 38-52
Average when temp settled:  51degC
and it does take a while to get up to that temp.
Code:
Range: 36-52
Average when temp settled:  51degC

Exactly the same - the profile may be different - didn't plot it
Same sketch on Production - non-secured:
 
Confirmed, you're reading the wrong part of the verbose info. But as I said in msg #33, it's really my fault that the verbose info isn't clear. There are so many messages saying .hex and the one which matters isn't standing out:

Code:
20:06:53.984 (loader): elf appears to be for Teensy 4.0 (IMXRT1062) (2031616 bytes)
20:06:53.985 (loader): elf binary data matches hex file
20:06:53.985 (loader): elf file is for Teensy 4.0 (IMXRT1062)
20:06:53.985 (loader): [COLOR="#B22222"][B]using encrypted ehex[/B][/COLOR] (optional - secure mode not yet locked)  <===== we talked about this in previous post.
20:06:54.019 (loader): begin operation
20:06:54.031 (loader): remote cmd from 1380: "status"
20:06:54.031 (reboot 4): Status: 1, 1, 1, 1, 0, 1, C:\Users\Merli\AppData\Local\Temp\arduino_build_140851\, VerifySecure.ino.hex
........

Those status messages are from "reboot 4" which is the communication happening with Arduino (or the teensy_reboot program Arduino runs). Arduino just builds the .ehex file if it can, but none of the communication is about the .ehex file. Teensy Loader is supposed to notice if Arduino built both or only .hex.

For 1.55-beta2 I will work on improving the verbose info messages, so this is clearer.

However, the intended way to check whether encryption is working in that Verify Sketch from the Teensy 4 Security dialog box. It runs 4 specific tests that truly do confirm whether your code is running with or without encryption.

Thanks for the explanation Paul. Saw the first message on "using encrypted ehex" and interpreted it that it was using the .hex file. Then reading that other one got me confused - primarily because I had no clue what reboot 4 was and interpreted wrong. Think Tim was under the same impression as well.

Teensy Loader is supposed to notice if Arduino built both or only .hex.
From running both encrypted and normal sketches on the FuseWritten T4 it seems to be recognizing it as it should when you load from the IDE.
 
I'm working on sound playing from SD card to MQS pins (10 and 12). There is sound from both channels if I output a sound from a sine, for example (not from SD card). But after initialization SD (SD.begin(SDCARD_CS_PIN)) there is sound from pin 12 only. Pin 10 is not work.
I've described this problem in thread https://forum.pjrc.com/threads/67984-MQS-output-from-SD-card?p=286233#post286233

Teensy 4.0
Teensyduino v1.54

CS - pin 36
MISO - pin 34
MOSI - pin 35
SCK - pin 37
These pins are connected to SD card.

I'm using an audio amplifier "arduino module amplifier PAM8403 mini 5V 2x3W". It is connected to 10 and 12 pins.


Code:
#include <Audio.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

AudioPlaySdWav           playWav1;
AudioOutputMQS           audioOutput;
AudioConnection          patchCord1(playWav1, 0, audioOutput, 0);
AudioConnection          patchCord2(playWav1, 1, audioOutput, 1);

#define SDCARD_CS_PIN    36

void setup() {
  Serial.begin(9600);

  while (!(SD.begin(SDCARD_CS_PIN))) {
      Serial.println("Unable to access the SD card");
      delay(500);
  }

  AudioMemory(8);
}

void playFile(const char *filename)
{
  Serial.print("Playing file: ");
  Serial.println(filename);
  playWav1.play(filename);

  // A brief delay for the library read WAV info
  delay(5);

  // Simply wait for the file to finish playing.
  while (playWav1.isPlaying()) {
  }
}


void loop() {
  playFile("SDTEST1.WAV");
  delay(1500);
}
 
Last edited:
I'm working on sound playing from SD card to MQS pins (10 and 12). There is sound from both channels if I output a sound from a sine, for example (not from SD card). But after initialization SD (SD.begin(SDCARD_CS_PIN)) there is sound from pin 12 only. Pin 10 is not work.
I've described this problem in thread https://forum.pjrc.com/threads/67984-MQS-output-from-SD-card?p=286233#post286233

Teensy 4.0
Teensyduino v1.54

CS - pin 36
MISO - pin 34
MOSI - pin 35
SCK - pin 37
These pins are connected to SD card.

I'm using an audio amplifier "arduino module amplifier PAM8403 mini 5V 2x3W". It is connected to 10 and 12 pins.


.....

As Frank mentioned in the other thread you need to tell SD library you are using SPI2, as far as I know it does not default to SPI2 because you are using CS associated with SPI2. Pins 10 and 12 are typically associated with SPI.

You would need to modify your SD.begin statement to something like this:
Code:
SD.begin( SdSpiConfig(SDCARD_CS_PINs, DEDICATED_SPI, SD_SCK_MHZ(15), &SPI2) ) ;
 
Definitely interesting. Is it the right sound. Maybe an artifact from the amp board and using sdcard on spi1 since 12 is miso and the sdcard is reading from the amp board? Don’t know not an electronics guy
 
Using different Keys:
Test 1:
Using the fuseWrite T4 only, reran the Tim's kitchen sink sketch and uploaded with a different key hash so that is working.

Test 2:
Using a Normal T4 and write Fuse only. FAIL for some reason. Step to repeat

a. Open Teensy 4 Security
b. Generate Key (deleted previous key from Arduino first)
c. Run FuseWrite sketch - FAILS:
Code:
Writing public key hash
public key hash is good :-)
Writing secret key
key written, setting config
Error: Key can not be used

Testing Bus Encryption Engine
Error: ciphertext decryption did not match plaintext!
  plain:  97 86 84 4C
  cipher: F2 E1 15 02
  dcrypt: F2 E1 15 02

Error: JTAG can not be disabled

Error: Secure mode can not be set

EDIT: Think Kurt just posted the answer to the fail:
Standard Teensy 4.0 made after June 2021 can also run encrypted programs,

Don't think I have any made after June 2021 to test with.
 
Standard Teensy 4.0 made after June 2021 can also run encrypted programs, but the final secure lock mode can't be set. Running encrypted programs that way is akin to locking your door but leaving the window open. Still, might be worth trying. Anyone can open this window, create their own key.pem file, and get .EHEX files created.

Good morning all!

Wondering from this comment, a couple of things:
a) Ones after June 2021, would this imply bootloader version 1.06?
b) Is this limited to T4? Or all of the T4 family? In particular, T-MMOD have this firmware?


Side Note: Last night when I shut off my computer, I still had the Teensy program running on the machine, and the system gave me a fault message, I believe on accessing through a null pointer... Have not tried to reproduce this yet.

Kurt
 
Good morning all!

Wondering from this comment, a couple of things:
a) Ones after June 2021, would this imply bootloader version 1.06?
b) Is this limited to T4? Or all of the T4 family? In particular, T-MMOD have this firmware?


Side Note: Last night when I shut off my computer, I still had the Teensy program running on the machine, and the system gave me a fault message, I believe on accessing through a null pointer... Have not tried to reproduce this yet.

Kurt

Ok - got me curious. Took a TMM I had already setup and tried doing what I did in post #73 and it failed. Verbose did give me:
Code:
Teensy MicroMod (IMXRT1062), version 1.06
So has to to be more than version number since this is at 1.06
 
Status
Not open for further replies.
Back
Top