Teensyduino 1.54 Beta #5

[PaulStoffregen]

But, really, I don't know what the plan is.

I do have a plan (kinda 2 plans), but so far haven't written anything....

1: For the wav file player and other file-based audio library stuff, I'm planning to add a useFilesystem(FS &filesys) function, which would store "filesys" into a FS pointer, and of course use that pointer rather than hard coding SD.

2: For a unified unix-like virtual filesystem, which as I understand is done on ESP and maybe circuit python, I'm imagining another library which inherits FS and its own specialization of File. You would still create instances of SD, LittleFS, SerialFlash (when/if it's ported to FS & File) and then give references to those and mount folder strings to this special wrapper filesystem. Whether we really ever need that, I do not know.

The main plan is to use #1 and so #2 isn't necessarily needed just for libraries like Audio, unless we really want a unix-like virtual filesystem for something #1 can't do.

[Frank B]

That sounds like a good plan.
Perhaps I can add the SPIFFS then, too.. in a few months.
Actually, it should be possible to integrate USB drives, simple network file systems, etc. with it...

[mjs513]

I do have a plan (kinda 2 plans), but so far haven't written anything....

1: For the wav file player and other file-based audio library stuff, I'm planning to add a useFilesystem(FS &filesys) function, which would store "filesys" into a FS pointer, and of course use that pointer rather than hard coding SD.

2: For a unified unix-like virtual filesystem, which as I understand is done on ESP and maybe circuit python, I'm imagining another library which inherits FS and its own specialization of File. You would still create instances of SD, LittleFS, SerialFlash (when/if it's ported to FS & File) and then give references to those and mount folder strings to this special wrapper filesystem. Whether we really ever need that, I do not know.

The main plan is to use #1 and so #2 isn't necessarily needed just for libraries like Audio, unless we really want a unix-like virtual filesystem for something #1 can't do.

#1 I think is along the same lines as was done in MTP in the storage class:

 
  uint32_t addFilesystem(FS &fs, const char *name) {return sd_addFilesystem(fs, name);}
........
   uint32_t sd_addFilesystem(FS &fs, const char *name) {
      if (fsCount < MTPD_MAX_FILESYSTEMS) {
        sd_name[fsCount] = name;
        sdx[fsCount] = &fs;
        return fsCount++;
      }
      return 0xFFFFFFFFUL;  // no room left
    }

but of course much simpler. Agree with Frank - sounds like a plan.

[Frank B]

Things like that seem like a good addition to take the mystery out of a Teensy that 'just stops' - it doesn't generally happen - but when such things do happen it is an opaque puzzle.

And future more complex Teensy might even have more use for it.

I have an Idea.. I could extend the Hardfaults for a kind of "user" exceptions.
It would need a macro that prints the userdefined text together with the GCC macros
__FILE__, __func__, __LINE__

It would work like the existing Hardfaults I proposed, and could be used in the core, too (I think, the core - and libraries - are the main use-case - on other places a simple "printf" would do it too.)

So it would be possible to do something like die("No DMA Channel available"); or die("Hardwareserial: Wrong Pin#")...and we can use Watchdogs, which die("Watchdog starved")

Edit: And look like

c:\foo\greatest_off_all_c_file.c
Line: 47
Function: "setup" died. 
Last words: "Negative Baudrates not supported by Hardwareserial"

[defragster]

I have an Idea.. I could extend the Hardfaults for a kind of "user" exceptions.
It would need a macro that prints the userdefined text together with the GCC macros
__FILE__, __func__, __LINE__

It would work like the existing Hardfaults I proposed, and could be used in the core, too (I think, the core - and libraries - are the main use-case - on other places a simple "printf" would do it too.)

So it would be possible to do something like die("No DMA Channel available"); or die("Hardwareserial: Wrong Pin#")...and we can use Watchdogs, which die("Watchdog starved")

Anything that provides simple info logging would be cool. As noted your On_Restart T_4 display is an awesome extension for HardFaults.

That's where I got bogged down - tying to add generic debug stuff to HardFault handing and trying to print in either case - which often worked ...

"die" is cool Would be nice to have an Assert too - though that isn't always fatal.

Not seeing a lot of folks jumping up and down about how cool this is - not often needed - but when it would help it can save lots of wonder about the trouble and help with a quick resolution.

[PaulStoffregen]

Actually, it should be possible to integrate USB drives, simple network file systems, etc. with it...

Yup, that's been the plan all along.

[Frank B]

I have an Idea.. I could extend the Hardfaults for a kind of "user" exceptions.
It would need a macro that prints the userdefined text together with the GCC macros
__FILE__, __func__, __LINE__

Probably similar to this:

//Macro test
//#define DIE_WITH_PATH

#if !defined(DIE_WITH_PATH)
#define _FILENAME_ (__builtin_strrchr(__FILE__, '/') ? __builtin_strrchr(__FILE__, '/') + 1 : (__builtin_strrchr(__FILE__, '\\') ? __builtin_strrchr(__FILE__, '\\') + 1 : __FILE__) )
#define DIE(msg) _die(_FILENAME_, __func__, __LINE__, msg)
#else
#define DIE(msg) _die(__FILE__, __func__, __LINE__, msg)
#endif

FLASHMEM
void _die(const char *file, const char *func, unsigned line, const char *msg)
{
//Testing only. This should reset and print these texts _after_that.
//Does not use printf on purpose.
 while(!Serial);
 Serial.println(file); 
 Serial.print("Function \"");
 Serial.print(func);
 Serial.print("\" died in line ");
 Serial.println(line);
 if ( msg != nullptr ) {
  Serial.print("Last words:\"");
  Serial.print(msg);
  Serial.print("\"\n");
 } 
 while(1) asm("wfi");
}

void setup() {DIE("I felt it was time.");}
void loop() {}

[Frank B]

I added DIE:
https://github.com/FrankBoesing/cores/tree/hardfaults

void setup() { DIE("I felt it was time."); }
void loop() {}

resets and prints:

sketch_jan17a.ino
Function "setup" died in line 1
Last words:"I felt it was time."

stopping working,commenting at this, and disturbing this thread until its clear that this gets merged or not
I don't care that much if in the end it will be my solution or something different. But we need *something*. It will greatly reduce amount of forum questions where Teensy just dies silently.
Maybe we need to add something for USB-Types where Serial is not available.

[Frank B]

Hi Paul,

i *think* the I2S slave-input works now, too.
I have some problems with my hardware.. need to check the soldering of the microphone or have to connect a line-in somehow (I never use the input)
I've just uploaded - I think it is not *that* important and maybe check it later. I hear some noise and can hear when I touch the microphone. So far a good sign - maybe it works
maybe you want to check it when you have more time.

//Teensy LC SGTL-5000 test *input*
#include <Audio.h>

AudioInputI2Sslave       i2sslave1;
AudioOutputI2Sslave      i2sslave2;
AudioConnection          patchCord2(i2sslave1, 0, i2sslave2, 0);
AudioConnection          patchCord3(i2sslave1, 1, i2sslave2, 1);
AudioControlSGTL5000     sgtl5000_1;

void setup() {  
  AudioMemory(8);
  sgtl5000_1.enable();
  sgtl5000_1.inputSelect(AUDIO_INPUT_MIC);
  //sgtl5000_1.micGain(63);
  sgtl5000_1.volume(0.7);
}

void loop() {}

Globale Variablen verwenden 6744 Bytes (82%) des dynamischen Speichers, 1448 Bytes für lokale Variablen verbleiben. Das Maximum sind 8192 Bytes.

I2S input as "Master" is still TBD. Is there any use-case for this? (16MHz MCLK)


Edit: Fixed the Mic. The I2S-slave code works.
Edit: I2S-Master-Input added, but is untested.

[Frank B]

@Paul,

please take a look here : https://forum.pjrc.com/threads/65851...tly-into-PSRAM

[Frank B]

Hi Paul

do you have some time next week to merge some PRs?

[noisymime]

Not sure if this is the best (Or correct) place to request this, but would it be possible to get an update of the FlexCAN_T4 library included?

We had an issue with the init routine of this library that was resolved back in July (https://github.com/tonton81/FlexCAN_...1e9628e869080e) but given there haven't been many other changes to the library it doesn't look like it's been pulled in recently. It would be fantastic if this could be included in the next release.

[defragster]

imxrt-size:
@Paul, not sure if you're following the other thread, so I ask here.

It's almost done. Works for linux and Windows now - and I see no reason why it shouldn't work with a MAC.
Which output-format do you want? I can change it today. Luni proposed a good one.

@Frank - the copy of imxrt-size I have is missing an ending \n=newline it seems? In console output last line shares other output. Not sure if that is correct in current code or as offered for a PR?

[Frank B]

Where ?
The output is only a suggestion. Can be customized in 5 minutes. But if I do not even know if the tool is even considered, meaningful changes are difficult

[Frank B]

@Paul, important: Please edit this page: https://www.pjrc.com/teensy/tutorial4.html
5V is not good..

https://forum.pjrc.com/threads/65961...091#post268091

[Deleted User]

'SNVS_LPGPR0' was not declared in this scope

[Deleted User]

oh, sorry for the crippled post... ^.^
Now the problem is on Teensy 4.x, the battery buffered RTC RAM seems to be not working in several aspects. Teensy 4.1 documentation says

RTC RAM
16 bytes of memory are located within the RTC. If a coin cell is connected to VBAT, contents of
this memory is preserved while power is off. This memory is accessed as 32 bit registers
LPGPR0-LPGPR3.

These LPGPR0 ff are not defined. SO this docuemtation is misleading.

Using SNVS_LPGPR does not work. Write to this has no effect.
#define SNVS_LPGPR0 (IMXRT_SNVS.offset100) .. 10C and accessing these does compile, but writing has no effect.
GPR_Z_DIS in LPCR gets reset every boot, so LPGPR0 .. 3 get zeroed as well, rendering the battery backed memory useless.

[KurtE]

oh, sorry for the crippled post... ^.^
Now the problem is on Teensy 4.x, the battery buffered RTC RAM seems to be not working in several aspects. Teensy 4.1 documentation says

These LPGPR0 ff are not defined. SO this docuemtation is misleading.

Using SNVS_LPGPR does not work. Write to this has no effect.
#define SNVS_LPGPR0 (IMXRT_SNVS.offset100) .. 10C and accessing these does compile, but writing has no effect.
GPR_Z_DIS in LPCR gets reset every boot, so LPGPR0 .. 3 get zeroed as well, rendering the battery backed memory useless.

Looks like so far the imxrt.h file only has the original location for LPGR0 defined:

The SNVS_LP General Purpose Register is a 128-bit read/write register located in
SNVS_LP, which can be used by any application for retaining data during an SoC powerdown
mode. This is a privileged read/write register. The full GPR register is accessed as
4 32-bit registers located in successive word addresses starting at offset 100h. For
backward compatibility with earlier versions of SNVS, LPGPR0..LPGPR3 are aliased at
the earlier offset of 90h and LPGPR0 is aliased at its original offset of 68h. The GPR will
be automatically zeroized when a tamper event occurs, unless GPR zeroization is
disabled via the GPR_Z_DIS bit in the LP Control Register.

#define SNVS_LPGPR            (IMXRT_SNVS.offset068)

Note: I am not seeing the GPR_Z_DIS defined in the PDF?

Is this stuff that is the Security manual? Actually if I look at earlier version of the 1052SDK I see:

#define SNVS_LPCR_GPR_Z_DIS_MASK                 (0x1000000U)
#define SNVS_LPCR_GPR_Z_DIS_SHIFT                (24U)
#define SNVS_LPCR_GPR_Z_DIS(x)                   (((uint32_t)(((uint32_t)(x)) << SNVS_LPCR_GPR_Z_DIS_SHIFT)) & SNVS_LPCR_GPR_Z_DIS_MASK)

Where in the PDF files bit 24 appears to be marked only as Reserved...

Also don't see example code, to see what other registers you set.
Like what is the thate of the SNVS_HP register? Maybe the NPSWA_EN needs to be set?

[Deleted User]

The Security Reference Manual is a moderated document that requires an NDA. Please contact your NXP Distributor or FAE to obtain more information and this document.

So I am not allowed to give more information... it is hard to understand why they enforce NDA for this, but I wish to make other projects with them in the future, so....
And yes.
I thought the devs at PJRC have all the information...

So until this is solved, the Teensy 4.x shall be considered as not having RTC user memory or battery backed memory at all.

[mjs513]

Believe the "devs" at PJRC is just one person - Paul - just for clarity.

If what you are trying to do is implement boot security you might what to check this thread out: https://forum.pjrc.com/threads/57173...-code-security

[chipaudette]

>>> the Teensy 4.x shall be considered as not having RTC user memory

Does this mean that the RTC on Teensy 4.x doesn't work? Or, maybe you mean that RTC does function on T4.x but that it's not secure in its current form and, therefore, open to being hacked?

I have widget based on the 3.6 that I and some collaborators use for our research. The RTC is important. But so is computational speed. So, we've started the work to transition from T3.6 to T4.1. But if the RTC is unavailable on T4.1, that would probably halt our transition. Hence, my question.

Chip

[Deleted User]

Battery powered RTC seems to work on T4, but the advertised freely programmable user bytes to keep 4 x 32 bit during power-off are not usable, because they are zeroed at boot time.

[KurtE]

Battery powered RTC seems to work on T4, but the advertised freely programmable user bytes to keep 4 x 32 bit during power-off are not usable, because they are zeroed at boot time.

Are you sure? again what registers have you tried to set?

For example it states:

This is a privileged read/write register

So again sometimes hard to know what is going on without an example code base showing what you are trying to do.

And as @mjs513 mentioned - The only PJRC developer is Paul, all of the rest of us are just customers, who have fun playing with the different boards. In my case a retired software guy who likes to tinker.

[chipaudette]

Battery powered RTC seems to work on T4, but the advertised freely programmable user bytes to keep 4 x 32 bit during power-off are not usable, because they are zeroed at boot time.

Ah, thanks for the clarification!

[mjs513]

Just as a note if I read page 1306 of the IMXRT1064 reference manual for the (20.6.16) SNVS_LP General Purpose Registers 0 .. 3 (LPGPR0_alias - LPGPR3_alias) it states:

This is a privileged read/write register

so you may not be able to write. How to get it into privileged mode have no idea or if you need to have security features turned or.... Try reading that thread on Teensy 4.0 security. Don't think security features are turned on as of yet. I know its on the list of things to get done.