Teensyduino 1.54 Beta #5

Status
Not open for further replies.
So, we had a couple of users who try to plays multiple wav-files simultanously.
With this explanations it seems to be very easy to fix that by just buffering more blocks and read these sequentially?

Indeed I thought this when I wrote some SD Code a long time ago - but later I never got the Idea to just add more buffers to help these uses with their wav-"problem"
 
Last edited:
tf3cy said:
Hi

not sure if this is known issue, or not - I upgraded to BigSur on Macbook pro 2018
When i run the installer I get View attachment 22794

I recently started using VS Code with the Arduino expansion, but I have not been using Teensy in the projects up to now, but I now need Teensy and ran into this issue.
...So you can perhaps just stop me if the VSCode+Teensy will work or not.

I started with root and tried some command line hacks , If I click around the grey area I hit some buttons, at least cancel ;

- Benni
Click to expand...

This is a known “non-issue” since MacOS Catalina, reason being is that a separate download is already provided that has Teensyduino already preinstalled with Arduino.
 
Frank B said:
So, we had a couple of users who try to plays multiple wav-files simultanously.
With this explanations it seems to be very easy to fix that by just buffering more blocks and read these sequentially?

Indeed I thought this when I wrote some SD Code a long time ago - but later I never got the Idea to just add more buffers to help these uses with their wav-"problem"
Click to expand...

Wondering if like the T_4.x SERIAL_UART there could be code like: HardwareSerial::addMemoryForRead()

To supplement a reasonable default buffer when the USER can commit available memory for that purpose?

Of course that just means longer waits if the reads are blocking - and maybe other questions ???
 
You are right, Tim. It would probably need a spezialized wave-player. Perhaps with some kind of extra "read_ahead(filename)" function. And it would need a T4.x, maybe, due to higher RAM requirements.
 
SE Blank RT Famil

Hi Paul,
like in the very early T4.0 betas, sometimes my PC detects "SE Blank RT Family"
This time, it happened with a T4.1 board I got from you (the one with soldered mem chips, hand-written serial: 40)

I'm pretty sure it had a working program on it when i put it in the drawer, some weeks ago.
I can't remember which it was.

USB-View shows this:

Code: 
    =========================== USB Port3 ===========================

Connection Status        : 0x01 (Device is connected)
Port Chain               : 2-1-3

      ========================== Summary =========================
[COLOR=#ff0000]Vendor ID                : 0x1FC9 (NXP Semiconductors)[/COLOR]
Product ID               : 0x0135
USB version              : 2.00
Port maximum Speed       : High-Speed
Device maximum Speed     : High-Speed
Device Connection Speed  : High-Speed
Self Powered             : yes
Demanded Current         : 100 mA
Used Endpoints           : 2

      ======================== USB Device ========================

        +++++++++++++++++ Device Information ++++++++++++++++++
Device Description       : USB-Eingabegerät
Device Path              : \\?\USB#VID_1FC9&PID_0135#7&51349d7&0&3#{a5dcbf10-6530-11d2-901f-00c04fb951ed} (GUID_DEVINTERFACE_USB_DEVICE)
Kernel Name              : \Device\USBPDO-7
Device ID                : USB\VID_1FC9&PID_0135\7&51349D7&0&3
Hardware IDs             : USB\VID_1FC9&PID_0135&REV_0101 USB\VID_1FC9&PID_0135
Driver KeyName           : {745a17a0-74d3-11d0-b6fe-00a0c90f57da}\0054 (GUID_DEVCLASS_HIDCLASS)
Driver                   : \SystemRoot\System32\drivers\hidusb.sys (Version: 10.0.19041.1  Date: 2019-12-07)
Driver Inf               : C:\WINDOWS\inf\input.inf
Legacy BusType           : PNPBus
Class                    : HIDClass
Class GUID               : {745a17a0-74d3-11d0-b6fe-00a0c90f57da} (GUID_DEVCLASS_HIDCLASS)
Service                  : HidUsb
Enumerator               : USB
Location Info            : Port_#0003.Hub_#0004
Location IDs             : PCIROOT(0)#PCI(0801)#PCI(0004)#USBROOT(0)#USB(1)#USB(3), ACPI(_SB_)#ACPI(PCI0)#ACPI(GP17)#ACPI(XHC1)#ACPI(RHUB)#ACPI(PRT1)#USB(3)
Container ID             : {25bc2f8a-3c0c-11eb-8ecc-7085c2b760d5}
Manufacturer Info        : (Standardsystemgeräte)
Capabilities             : 0x84 (Removable, SurpriseRemovalOK)
Status                   : 0x0180600A (DN_DRIVER_LOADED, DN_STARTED, DN_DISABLEABLE, DN_REMOVABLE, DN_NT_ENUMERATOR, DN_NT_DRIVER)
Problem Code             : 0
HcDisableSelectiveSuspend: 0
EnableSelectiveSuspend   : 0
SelectiveSuspendEnabled  : 0
EnhancedPowerMgmtEnabled : 1
IdleInWorkingState       : 0
WakeFromSleepState       : 0
Power State              : D0 (supported: D0, D2, D3, wake from D0, wake from D2)
 Child Device 1          : HID-konformes, vom Hersteller definiertes Gerät
  Device Path            : \\?\HID#VID_1FC9&PID_0135#8&14d684b6&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} (GUID_DEVINTERFACE_HID)
  Kernel Name            : \Device\000000d5
  Device ID              : HID\VID_1FC9&PID_0135\8&14D684B6&0&0000
  Class                  : HIDClass
  Driver KeyName         : {745a17a0-74d3-11d0-b6fe-00a0c90f57da}\0055 (GUID_DEVCLASS_HIDCLASS)

        +++++++++++++++++ Registry USB Flags +++++++++++++++++
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\1FC901350101
 osvc                    : REG_BINARY 00 00

        ---------------- Connection Information ---------------
Connection Index         : 0x03 (Port 3)
Connection Status        : 0x01 (DeviceConnected)
Current Config Value     : 0x01 (Configuration 1)
Device Address           : 0x02 (2)
Is Hub                   : 0x00 (no)
Device Bus Speed         : 0x02 (High-Speed)
Number Of Open Pipes     : 0x01 (1 pipe to data endpoints)
Pipe[0]                  : EndpointID=1  Direction=IN   ScheduleOffset=0  Type=Interrupt
Data (HexDump)           : 03 00 00 00 12 01 00 02 00 00 00 40 C9 1F 35 01   ...........@..5.
                           01 01 01 02 00 01 01 02 00 02 00 01 00 00 00 01   ................
                           00 00 00 07 05 81 03 40 00 04 00 00 00 00         .......@......

        --------------- Connection Information V2 -------------
Connection Index         : 0x03 (3)
Length                   : 0x10 (16 bytes)
SupportedUsbProtocols    : 0x03
 Usb110                  : 1 (yes, port supports USB 1.1)
 Usb200                  : 1 (yes, port supports USB 2.0)
 Usb300                  : 0 (no, port not supports USB 3.0)
 ReservedMBZ             : 0x00
Flags                    : 0x00
 DevIsOpAtSsOrHigher     : 0 (Device is not operating at SuperSpeed or higher)
 DevIsSsCapOrHigher      : 0 (Device is not SuperSpeed capable or higher)
 DevIsOpAtSsPlusOrHigher : 0 (Device is not operating at SuperSpeedPlus or higher)
 DevIsSsPlusCapOrHigher  : 0 (Device is not SuperSpeedPlus capable or higher)
 ReservedMBZ             : 0x00
Data (HexDump)           : 03 00 00 00 10 00 00 00 03 00 00 00 00 00 00 00   ................

    ---------------------- Device Descriptor ----------------------
bLength                  : 0x12 (18 bytes)
bDescriptorType          : 0x01 (Device Descriptor)
bcdUSB                   : 0x200 (USB Version 2.00)
bDeviceClass             : 0x00 (defined by the interface descriptors)
bDeviceSubClass          : 0x00
bDeviceProtocol          : 0x00
bMaxPacketSize0          : 0x40 (64 bytes)
[COLOR=#ff0000]idVendor                 : 0x1FC9 (NXP Semiconductors)
idProduct                : 0x0135
bcdDevice                : 0x0101
iManufacturer            : 0x01 (String Descriptor 1)
 Language 0x0409         : "NXP      SemiConductors Inc "
iProduct                 : 0x02 (String Descriptor 2)
 Language 0x0409         : "SE Blank RT Family "[/COLOR]
iSerialNumber            : 0x00 (No String Descriptor)
bNumConfigurations       : 0x01 (1 Configuration)
Data (HexDump)           : 12 01 00 02 00 00 00 40 C9 1F 35 01 01 01 01 02   .......@..5.....
                           00 01                                             ..

    ------------------ Configuration Descriptor -------------------
bLength                  : 0x09 (9 bytes)
bDescriptorType          : 0x02 (Configuration Descriptor)
wTotalLength             : 0x0022 (34 bytes)
bNumInterfaces           : 0x01 (1 Interface)
bConfigurationValue      : 0x01 (Configuration 1)
iConfiguration           : 0x00 (No String Descriptor)
bmAttributes             : 0xC0
 D7: Reserved, set 1     : 0x01
 D6: Self Powered        : 0x01 (yes)
 D5: Remote Wakeup       : 0x00 (no)
 D4..0: Reserved, set 0  : 0x00
MaxPower                 : 0x32 (100 mA)
Data (HexDump)           : 09 02 22 00 01 01 00 C0 32 09 04 00 00 01 03 00   ..".....2.......
                           00 00 09 21 00 01 00 01 22 4C 00 07 05 81 03 40   ...!...."L.....@
                           00 04                                             ..

        ---------------- Interface Descriptor -----------------
bLength                  : 0x09 (9 bytes)
bDescriptorType          : 0x04 (Interface Descriptor)
bInterfaceNumber         : 0x00
bAlternateSetting        : 0x00
bNumEndpoints            : 0x01 (1 Endpoint)
bInterfaceClass          : 0x03 (HID - Human Interface Device)
bInterfaceSubClass       : 0x00 (None)
bInterfaceProtocol       : 0x00 (None)
iInterface               : 0x00 (No String Descriptor)
Data (HexDump)           : 09 04 00 00 01 03 00 00 00                        .........

        ------------------- HID Descriptor --------------------
bLength                  : 0x09 (9 bytes)
bDescriptorType          : 0x21 (HID Descriptor)
bcdHID                   : 0x0100 (HID Version 1.00)
bCountryCode             : 0x00 (00 = not localized)
bNumDescriptors          : 0x01
Data (HexDump)           : 09 21 00 01 00 01 22 4C 00                        .!...."L.
Descriptor 1:
bDescriptorType          : 0x22 (Class=Report)
wDescriptorLength        : 0x004C (76 bytes)
Error reading descriptor : ERROR_INVALID_PARAMETER (due to a obscure limitation of the Win32 USB API, see UsbTreeView.txt)

        ----------------- Endpoint Descriptor -----------------
bLength                  : 0x07 (7 bytes)
bDescriptorType          : 0x05 (Endpoint Descriptor)
bEndpointAddress         : 0x81 (Direction=IN EndpointID=1)
bmAttributes             : 0x03 (TransferType=Interrupt)
wMaxPacketSize           : 0x0040
 Bits 15..13             : 0x00 (reserved, must be zero)
 Bits 12..11             : 0x00 (0 additional transactions per microframe -> allows 1..1024 bytes per packet)
 Bits 10..0              : 0x40 (64 bytes per packet)
bInterval                : 0x04 (4 ms)
Data (HexDump)           : 07 05 81 03 40 00 04                              ....@..

    ----------------- Device Qualifier Descriptor -----------------
Error                    : ERROR_GEN_FAILURE

      -------------------- String Descriptors -------------------
             ------ String Descriptor 0 ------
bLength                  : 0x04 (4 bytes)
bDescriptorType          : 0x03 (String Descriptor)
Language ID[0]           : 0x0409 (English - United States)
Data (HexDump)           : 04 03 09 04                                       ....
             ------ String Descriptor 1 ------
bLength                  : 0x3A (58 bytes)
bDescriptorType          : 0x03 (String Descriptor)
Language 0x0409          : "NXP      SemiConductors Inc "  *!*CAUTION  trailing space character
Data (HexDump)           : 3A 03 4E 00 58 00 50 00 20 00 20 00 20 00 20 00   :.N.X.P. . . . .
                           20 00 20 00 53 00 65 00 6D 00 69 00 43 00 6F 00    . .S.e.m.i.C.o.
                           6E 00 64 00 75 00 63 00 74 00 6F 00 72 00 73 00   n.d.u.c.t.o.r.s.
                           20 00 49 00 6E 00 63 00 20 00                      .I.n.c. .
             ------ String Descriptor 2 ------
bLength                  : 0x28 (40 bytes)
bDescriptorType          : 0x03 (String Descriptor)
Language 0x0409          : "SE Blank RT Family "  *!*CAUTION  trailing space character
Data (HexDump)           : 28 03 53 00 45 00 20 00 42 00 6C 00 61 00 6E 00   (.S.E. .B.l.a.n.
                           6B 00 20 00 52 00 54 00 20 00 46 00 61 00 6D 00   k. .R.T. .F.a.m.
                           69 00 6C 00 79 00 20 00                           i.l.y. .

I know, I can use the "15-Seconds" procedure. Hav'nt done it so far. I can send the board to you if you want.

Do you have any idea what is happening?
 
Hi @FrankTest ;)

I have seen this as well on T4.1, with my experiment board, where I soldered on a castellated extension to the board that included the memory chip areas and then used some memory breakout boards to connect up to it. When I tried two extensions one PSRAM and the other WinBond... It fails to boot and I would sometimes get that type of USB device.

I still want to experiment more, but right now I have the two breakouts connected up using up with just PSRAM going to FLEXSPI and the other going to SPI... Note: sometimes the PSRAM shows up (Size 8) other times Size0, so guessing maybe timing related due to long paths
 
KurtE said:
Hi @FrankTest ;)

I have seen this as well on T4.1, with my experiment board, where I soldered on a castellated extension to the board that included the memory chip areas and then used some memory breakout boards to connect up to it. When I tried two extensions one PSRAM and the other WinBond... It fails to boot and I would sometimes get that type of USB device.

I still want to experiment more, but right now I have the two breakouts connected up using up with just PSRAM going to FLEXSPI and the other going to SPI... Note: sometimes the PSRAM shows up (Size 8) other times Size0, so guessing maybe timing related due to long paths
Click to expand...


Thank you, Kurt. It seems to be known issue.
I guess, while the Teensy is in this mode, the NXP USB-Bootloader can be used?

Different topic:
Everybody but me ;-) seems to be working on external memory. Is this APP-Note known? I think it would be an interesting feature to get encryption working (and if is for the optional chips only)


AN12852
How to Enable the On-the-fly Decryption

i.MX RT10xx, except i.MX1010, provides an on-the-fly encryption enginecalled Bus Encryption Engine(BEE), which is dedicated for FlexSPI. Thisapplication note explains how to use BEE to decrypt data in application layer.The purpose is that data is encrypted in FlexSPI to avoid getting plain text andcode is encrypted and can be read and on-the-fly executed. This is especiallyuseful for a second secure boot.

BEE can only decrypt data.
Click to expand...

 https://www.nxp.com/docs/en/application-note/AN12852.pdf
 
Last edited:
@Frank B
Never saw that one before, thanks for the reference.

It does reference the SRM for the 1050 but can't get that unless you provide a reference name. Good news is there looks like there may be a BEE example in the SDK manual :).
 
Frank B said:
Thank you, Kurt. It seems to be known issue.
I guess, while the Teensy is in this mode, the NXP USB-Bootloader can be used?
...
https://www.nxp.com/docs/en/application-note/AN12852.pdf
Click to expand...

I can't say I've seen this "PC detects "SE Blank RT Family" anytime recently? And also most times (IIRC) it was seen in Beta was After 15s Restore before the Restore image was perfected.

Does it recur if powered ( caps charged ) and then TyComm Reset?
 
At the moment I prefer to leave it in this state, til I have time to test the NXP loader.So i don't want to do experiments now..
 
@Paul,
I don't know why it did not happened before, und I don't know if the other outputs are affected, too, but we have a minor problem with the audio-libary.
"DMAMEM" gets not initialized with 0 - was there a change or has it always been like this? Was there a change in the Linker-script, maybe?
I can reproduce the "beep" in this thread: https://forum.pjrc.com/threads/65265-HELP-Audio-Beeps-with-Teensy-4-1-and-PT8211
The problem there is, that there seems to be a delay between starting DMA and the audio-lib update(). So, for a short time, DMA transfers random data to the output.
My fix - which works for me (waiting for response from "Regis Monte") - is to init the buffer with zero (code: see linked thread).

I think the "bug" affects ALL outputs.

What do you think? I can do a PR, if wanted, to add this to all outputs - if you don't have a better fix.
 
Last edited:
Maybe it's a good idea to init the entire OCRAM with zeros (and flush cache) in startup.c anyway.. that can fix many other potential problems, too.
Want a PR?
 
Frank B said:
The problem there is, that there seems to be a delay between starting DMA and the audio-lib update(). So, for a short time, DMA transfers random data to the output.
My fix - which works for me (waiting for response from "Regis Monte") - is to init the buffer with zero (code: see linked thread).

I think the "bug" affects ALL outputs.

What do you think? I can do a PR, if wanted, to add this to all outputs - if you don't have a better fix.
Click to expand...

The PT8211 constructor should use memset() to zero its buffer memory before it turns on the DMA hardware.
 
Hello,
Just a small report about playing files from builtin SD.
I made a simple sample player with T3.5 + audioshield + builtin SD. I trigger samples with of TouchPins.
When testing, I noticed clics and artefacts when playing mono wav files from SD, at the very beginning of the sample. I couldn't have a clean start.

Defragster suggested to try 1.54 beta. It has solved the problem. My samples are played with a clean start. Polyphony is OK at least for 6 samples playing at the same time.
But it seems that there is still a problem raw files. When using AudioPlaySdRaw, I have unpredictable lags and glitches.

Original thread :
https://forum.pjrc.com/threads/65365-playing-samples-from-SD-card-strange-behavior?p=263781

Thanks for all your work.
Emmanuel
 
Is it only at the beginning? It may be the same bug as in #112
It was fixed for PT8211 only, but it can affect everything that uses DMA (or just reads DMAMEM...)
 
Last edited:
@emmanuel63: If you upload the whole project somewhere, including the sound files, I can try to find & fix the bug.
 
What is the thinking on a release date for 1.54 (not beta, but actual release)?

The inclusion of the Greiman SD in teensyduino is a game changer for me with my Tympan stuff. It's a huge leap forward to have it in teensyduino cpared to my own kludge of stuffing it into the Tympan library.

I've now pulled it all out of the Tympan library so that it relies upon the version in 1.54 Beta. But, I don't feel that I can release my own updated library until the Teensyduino stuff leaves Beta.

Is there a schedule (even a notional one) of when this SD stuff will be part of a full Teensyduino release?

Excited!

Chip
 
@frankB: installing the 1.54 beta has solved the problem. I can read mono wav files from SD without latency and artefacts.
 
Frank B said:
As this beta still will take some time - can't we test a higher flash-clock, too? We'll notice if something does not work...
https://forum.pjrc.com/threads/60021-Program-Flash-W25Q-speed
Currently, it is used well below its spec...
Or is there something else against it that I am not aware of?
Click to expand...

On a few boards, I have tried faster QSPI speeds. Appeared to work OK at the I think 104mhz, but at times the PSRAM failed at 133mhz.
 
Kurt, I was talking about the program flash, not PSRAM.
PSRAM can't do 133MHz.

Even then ESP uses higher speed (80Mhz) for its flash than we do, and it works good on millions of boards. That's not surprising, as the flash datasheed says it is OK.
 
Frank B said:
Kurt, I was talking about the program flash, not PSRAM.
PSRAM can't do 133MHz.

Even then ESP uses higher speed (80Mhz) for its flash than we do, and it works good on millions of boards. That's not surprising, as the flash datasheed says it is OK.
Click to expand...

It seemed you meant PROGRAM PCB onboard Flash when I read that. Can you point out the needed change? On way to test it would be doing LittleFS test runs then on _Program disk media.
I just did a set of tests SPI .vs. QSPI NAND on the LittleFS thread at current speed. @mjs513 did a compare of current and faster clock on the NAND's and it showed little improvement.
If you had a test worthy clock change I could run those same steps on _Program FLASH.
 
defragster said:
Can you point out the needed change?
Click to expand...

https://forum.pjrc.com/threads/60021-Program-Flash-W25Q-speed

bootdata.c,
0x00030401, // lutCustomSeqEnable,serialClkFreq,sflashPadType,deviceType

Change that "3" to a higher number up to "8".

Edit: Don't ask me what value what speed is. I forgot it. It must be somewhere in the posts from march. Currently I don't really feel like looking at the details again.

If want to test that for a benchmark or similar, you must keep in mind that the cache is enabled. It's not easy to test.
It plays a role for non-sequential random accesses. For data, for example. In cases when the cache, or its read ahead can not help.
I'd see it from the other side: Why put on a brake that is not necessary? This makes no sense.
 
Status
Not open for further replies.
Back
Top