Forum Rule: Always post complete source code & details to reproduce any issue!
Page 8 of 9 FirstFirst ... 6 7 8 9 LastLast
Results 176 to 200 of 207

Thread: Teensyduino 1.54 Beta #5

  1. #176
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,781
    Quote Originally Posted by Frank B View Post
    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.

  2. #177
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,989
    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...

  3. #178
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,367
    Quote Originally Posted by PaulStoffregen View Post
    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:
    Code:
     
      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.

  4. #179
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,989
    Quote Originally Posted by defragster View Post
    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
    Code:
    c:\foo\greatest_off_all_c_file.c
    Line: 47
    Function: "setup" died. 
    Last words: "Negative Baudrates not supported by Hardwareserial"
    Last edited by Frank B; 01-16-2021 at 11:34 PM.

  5. #180
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,495
    Quote Originally Posted by Frank B View Post
    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.

  6. #181
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    23,781
    Quote Originally Posted by Frank B View Post
    Actually, it should be possible to integrate USB drives, simple network file systems, etc. with it...
    Yup, that's been the plan all along.

  7. #182
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,989
    Quote Originally Posted by Frank B View Post
    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:
    Code:
    //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() {}
    Last edited by Frank B; 01-17-2021 at 10:03 AM.

  8. #183
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,989
    I added DIE:
    https://github.com/FrankBoesing/cores/tree/hardfaults

    Code:
    void setup() { DIE("I felt it was time."); }
    void loop() {}
    resets and prints:
    Code:
    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.
    Last edited by Frank B; 01-17-2021 at 11:36 AM.

  9. #184
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,989

    Teensy LC Audio, Input Slave with SGTL

    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.
    Code:
    //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() {}
    Code:
    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.
    Last edited by Frank B; 01-18-2021 at 02:11 PM.

  10. #185
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,989

  11. #186
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,989
    Hi Paul

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

  12. #187
    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.

  13. #188
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,495
    Quote Originally Posted by Frank B View Post
    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?

  14. #189
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,989
    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

  15. #190
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,989

  16. #191
    Deleted User
    Guest
    'SNVS_LPGPR0' was not declared in this scope

  17. #192
    Deleted User
    Guest
    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.

  18. #193
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,502
    Quote Originally Posted by Deleted User View Post
    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.
    Code:
    #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:

    Code:
    #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?

  19. #194
    Deleted User
    Guest
    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.

  20. #195
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,367
    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

  21. #196
    Senior Member
    Join Date
    Oct 2015
    Location
    Vermont, USA
    Posts
    284
    >>> 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

  22. #197
    Deleted User
    Guest
    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.

  23. #198
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,502
    Quote Originally Posted by Deleted User View Post
    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.

  24. #199
    Senior Member
    Join Date
    Oct 2015
    Location
    Vermont, USA
    Posts
    284
    Quote Originally Posted by Deleted User View Post
    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!

  25. #200
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,367
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •