PDA

View Full Version : Teensyduino 1.54 Beta #5

Paul
11-19-2020, 11:17 PM
Here is a fifth beta test for Teensyduino 1.54.

Install into a clean copy of Arduino if you previously installed beta3 or beta4.
SdFat-beta was renamed to SdFat. You may end up with conflicting duplicates if
installing over the top of beta3 or beta4.

Linux 32 bit:
https://www.pjrc.com/teensy/td_154-beta5/TeensyduinoInstall.linux32

Linux 64 bit:
https://www.pjrc.com/teensy/td_154-beta5/TeensyduinoInstall.linux64

Linux ARM:
https://www.pjrc.com/teensy/td_154-beta5/TeensyduinoInstall.linuxarm

Linux ARM64:
https://www.pjrc.com/teensy/td_154-beta5/TeensyduinoInstall.linuxaarch64

MacOS 10.10 to 10.15:
https://www.pjrc.com/teensy/td_154-beta5/Teensyduino_MacOS_Catalina.zip

MacOS 10.8 to 10.14:
https://www.pjrc.com/teensy/td_154-beta5/TeensyduinoInstall.dmg

Windows:
https://www.pjrc.com/teensy/td_154-beta5/TeensyduinoInstall.exe

Changes since Teensyduino 1.54-beta4:

File & FS classes improved - many changes!
Add LittleFS library - lots of new stuff here...
FS open() supports FILE_WRITE_BEGIN mode
SdFat-beta renamed to SdFat
Add delayNanoseconds() on Teensy 2.0, LC, 3.x
Print class support for 64 bit integers
DMAChannel attachInterrupt(isr, priority) (WMXZ)
Update NativeEthernet
SD listfiles example improved
Fix Audio PT8211 issue on Teensy 4.x
Improve Audio simultaneous WAV playing
Fix USB issue for MTP to run at 600 MHz
Fix double space on copy from serial monitor on Windows
Configurable MIDIx16 port names (vjmuzik)
Support for no USB (vjmuzik)

Known / Suspected bugs:

Selecting text in serial monitor gives visually wrong results
NativeEthernet WebClient example may hang

mjs513
11-19-2020, 11:39 PM
Did a clean install on a Win10 x64 of Arduino 1.8.13. Installed TD1.54-beta5 with no issues.

As a quick and dirty since it kind of hits everything that was edited on Filesystems tested with latest MTPResonder with the sketch modified to hit SD Card, RAM, SPIFlash and QSPIflash. Seems to be working for this appication:
22540

defragster
11-20-2020, 12:16 AM
Downloaded and installed beta 5 fine on Windows 10.

FIRST:: Went into the 1.8.13 IDE install and removed the "hardware\teensy\avr" to clear of prior betas etc, and removed local library for LittleFS.

Test sketch LFSintegrity built and runs fine on RAM [EXTMEM] as last run. No warnings or errors.

jonr
11-20-2020, 02:01 AM
Frequent overruns unless I patch the feedback code in usb_audio.cpp.

KurtE
11-20-2020, 02:37 AM
Installed, updated MTP removed other mtp.. built, nothing showed up on pc. Figured out I did not have so on pin 4, commented that out and now all the others show up :D

defragster
11-20-2020, 05:34 AM
Wondering why in boards.txt usage :

>> USB_MTPDISK_SERIAL results in :: error: 'Serial' was not declared in this scope

But >> teensy41.menu.usb.mtp.build.usbtype=USB_MTPDISK has Serial defined

Or is that another mystery hidden in the MTP code?

WMXZ
11-20-2020, 07:53 AM
beta5 happened overnight
Will next test MTP with beta5 (had to chase an issue first)

WMXZ
11-20-2020, 09:16 AM
Tested MTP on beta5, seems to work.
Note: for using USB_MTPDISK_SERIAL one has to a) copy file contents into different usb_desc.h and boards.txt
Native MTP mode uses SEREMU and not Serial
If using T4 one needs USB2 from same github

defragster
11-20-2020, 09:18 AM
Using latest WMXZ github of MTP : WORKING HERE TOO

About to post extended test sketch there

LitterBug
11-20-2020, 01:35 PM
OOoooo nice! I've been wanting to clean up my installs. Amazing how fast I get them polluted with excess stuff. Will throw it down on Ubuntu and W10.

kd5rxt-mark
11-23-2020, 12:13 AM
I'm getting different results when compiling my TeensyMIDIPolySynth project source between the latest TD1.54beta5 & the previous TD1.54beta4. For each test, I uninstalled Arduino, installed Arduino 1.8.13, then installed TD1.54beta(4,5) under Windows10pro.

Arduino IDE Configuration:
Tools/Board: "Teensy 4.0"
Tools/USB Type: "Serial + MIDI"
Tools/CPU Speed: "600MHz"
Tools/Optimize: "Fastest"
Tools/Keyboard Layout: "US English"
Tools/Port: "COMx Serial (Teensy 4.0)"

Compilation results using TD1.54beta4:

Sketch uses 318972 bytes (15%) of program storage space. Maximum is 2031616 bytes.
Global variables use 500756 bytes (95%) of dynamic memory, leaving 23532 bytes for local variables. Maximum is 524288 bytes.

Failed compilation results using TD1.54beta5:

data section exceeds available space in board
Sketch uses 354968 bytes (17%) of program storage space. Maximum is 2031616 bytes.
Global variables use 533524 bytes (101%) of dynamic memory, leaving -9236 bytes for local variables. Maximum is 524288 bytes.
Not enough memory; see http://www.arduino.cc/en/Guide/Troubleshooting#size for tips on reducing your footprint.
Error compiling for board Teensy 4.0.

Just for comparison, compilation results using previous TD1.53:

Sketch uses 315776 bytes (15%) of program storage space. Maximum is 2031616 bytes.
Global variables use 467988 bytes (89%) of dynamic memory, leaving 56300 bytes for local variables. Maximum is 524288 bytes.

I know that there are different memory regions/types, so I'm assuming that I need to assign one or more of my variable allocations to a different memory type, but I do not know specifically where to begin. Recommendations on where to look and/or start ??

Also getting some new compiler warnings, but these don't worry me nearly as much as being unable to compile successfully (exceeding RAM):

In file included from C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MIDI\s rc/MIDI.h:307:0,
from C:\Users\mjculross\Documents\Arduino\MJCsource\Tee nsyMIDIPolySynth\TeensyMIDIPolySynth.ino:61:
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MIDI\s rc/MIDI.hpp:285:6: note: declared here
void MidiInterface<Transport, Settings, Platform>::sendPolyPressure(DataByte inNoteNumber,
^
TeensyMIDIPolySynth: In function 'void usbhostMIDI_handleAfterTouchPoly(byte, byte, byte)':
TeensyMIDIPolySynth:17712: warning: 'void midi::MidiInterface<Transport, _Settings, _Platform>::sendPolyPressure(midi::DataByte, midi::DataByte, midi::Channel) [with Transport = midi::SerialMIDI<HardwareSerial>; _Settings = midi::DefaultSettings; _Platform = midi::DefaultPlatform; midi::DataByte = unsigned char; midi::Channel = unsigned char]' is deprecated
MIDI.sendPolyPressure(note, pressure, channel);
^
In file included from C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MIDI\s rc/MIDI.h:307:0,
from C:\Users\mjculross\Documents\Arduino\MJCsource\Tee nsyMIDIPolySynth\TeensyMIDIPolySynth.ino:61:
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\MIDI\s rc/MIDI.hpp:285:6: note: declared here
void MidiInterface<Transport, Settings, Platform>::sendPolyPressure(DataByte inNoteNumber,
^
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SdFat-beta\src\ExFatLib\ExFatPartition.cpp: In member function 'bool ExFatPartition::freeChain(uint32_t)':
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SdFat-beta\src\ExFatLib\ExFatPartition.cpp:328:5: warning: 'next' may be used uninitialized in this function [-Wmaybe-uninitialized]
if ((cluster + 1) != next || status == 0) {
^
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SdFat-beta\src\FatLib\FatPartition.cpp: In member function 'bool FatPartition::freeChain(uint32_t)':
C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SdFat-beta\src\FatLib\FatPartition.cpp:368:36: warning: 'next' may be used uninitialized in this function [-Wmaybe-uninitialized]
m_allocSearchStart = cluster - 1;
^

Thanks,

Mark J Culross
KD5RXT

PaulStoffregen
11-23-2020, 02:26 AM
Some of this increase is probably due to the change to SdFat. It's much faster and supports cards larger than 32GB and long filenames, but all that SD card goodness does come with a code size cost.

Recommendations on where to look and/or start ??

The linker creates a .sym file detailing all the memory allocation. After you compile, it should be sitting inside the temporary folder where Arduino built your code. To find that folder, you may need to enable verbose output while compiling in File > Preference. Then you can look for the pathnames in the many compiler commands.

If you'd like me (or maybe others) to take a look, just capture the .sym files from each version's compile. Arduino should automatically delete all temporary files when you quit, so grab it before you close the IDE. You might have to put them into a zip file to attach to a message here on the forum.

Other recent changes might be burning up memory. Those .sym files are the first step to figure out what's using so much more memory.

kd5rxt-mark
11-23-2020, 02:58 AM
Other recent changes might be burning up memory. Those .sym files are the first step to figure out what's using so much more memory.

@PaulStoffregen:

Thanks for your reply to my inquiry. I'll take a detailed look at the .sym files as recommended. If I'm not able to narrow down the resolution with that analysis, I'll post the files for further help.

Thanks again,

Mark J Culross
KD5RXT

P.S. I've been following the SDFat related discussions & it all sounds like it will provide a very nice capability !! However, I am surprised that those changes would have the effects that I'm seeing, since the only extra includes in my project are: USBHost_t36.h, MIDI.h, EEPROM.h, & Audio.h. This seems to indicate that the SDFat stuff must be built into every project, rather than "included" only when needed. Convenience & capability always comes at a cost, but that cost is looking like it will be well worth the convenience in this case !! And besides that, it's an opportunity for me to learn something new (.sym file contents) !! Thanks again. MJC

kd5rxt-mark
11-23-2020, 04:41 AM
Additional observation: in the process of generating the .sym files for the different TD versions, I thought I'd tinker with some of the other optimizations (I normally build everything at "Fastest" as indicated earlier) just to see how the optimization might affect memory usage. Setting optimization to "Smallest Code" gives the following results (& even better, it successfully avoids the problem of exceeding available RAM):

[with TD.154beta5 installed]

Sketch uses 240620 bytes (11%) of program storage space. Maximum is 2031616 bytes.
Global variables use 398356 bytes (75%) of dynamic memory, leaving 125932 bytes for local variables. Maximum is 524288 bytes.

I've never delved into the black art & science of compilers, but the resulting reduction in RAM usage is very surprising to me !!

Mark J Culross
KD5RXT

Frank B
11-23-2020, 07:21 AM
Hm, "blink" shows high RAM usage, too:

Der Sketch verwendet 15668 Bytes (0%) des Programmspeicherplatzes. Das Maximum sind 8126464 Bytes.
Globale Variablen verwenden 45756 Bytes (8%) des dynamischen Speichers, 478532 Bytes für lokale Variablen verbleiben. Das Maximum sind 524288 Bytes.

heres the sym (nm) output:

00000000 T _stext
00000001 A _itcm_block_count
00000020 t __do_global_dtors_aux
00000025 A _teensy_model_identifier
00000044 t frame_dummy
0000007c 00000010 T setup
0000008c 0000002c T loop
000000b8 000000cc T delay
00000184 0000004c t digitalWrite.part.0
000001d0 0000000a T digitalWrite
000001dc 00000080 T pinMode
0000025c 00000018 T unused_interrupt_vector
0000026c t _MSP
00000274 00000002 T startup_default_early_hook
00000274 00000002 W startup_early_hook
00000278 00000002 T startup_default_late_hook
00000278 00000002 W startup_late_hook
0000027c 0000008c W HardFault_HandlerC
00000308 00000024 T Panic_Temp_isr
0000032c 00000070 t schedule_transfer
0000039c 00000036 t run_callbacks
000003d4 000000a0 t endpoint0_transmit.constprop.1
00000474 0000066c t isr
00000ae0 00000064 T usb_config_rx
00000b44 00000068 T usb_config_tx
00000bac 0000002e T usb_prepare_transfer
00000bdc 00000028 T usb_transmit
00000c04 00000024 T usb_receive
00000c28 00000058 T usb_init_serialnumber
00000c80 0000006c t rx_queue_transfer
00000cec 000000b4 t rx_event
00000da0 00000098 t usb_serial_flush_callback
00000e38 00000002 T usb_serial_reset
00000e3c 00000108 T usb_serial_configure
00000f44 0000000c T usb_serial_available
00000f50 00000044 T EventResponder::runFromInterrupt()
00000f94 00000004 T pendablesrvreq_isr
00000f98 00000020 T systick_isr
00000fb8 00000010 T main
00000fc8 000000f0 W yield
000010b8 00000134 T memcpy
000011ec 000002c4 T set_arm_clock
000014b0 0000004e T ultoa
00001500 000002b8 T pwm_init
000017b8 00000050 T sm_align_pool
00001808 00000090 T sm_set_pool
00001898 00000002 W serialEvent()
0000189c 0000000c T __errno
000018a8 00000050 T __libc_init_array
000018f8 0000009a T memset
00001998 00000008 t ___init_veneer
000019a0 T _etext
000019a0 T _fini
000019a4 T __exidx_end
000019a4 T __exidx_start
00004934 A _flashimagelen
20000000 D _sdata
20000000 00000370 D digital_pin_to_info_PGM
20000370 0000006c D usb_descriptor_list
200003dc 00000004 D led
200003e0 00000012 d device_descriptor
200003f4 00000016 V usb_string_serial_number
200003f4 00000016 D usb_string_serial_number_default
2000040a 00000001 D yield_active_check_flags
2000040c 00000004 D F_BUS_ACTUAL
20000410 00000004 D F_CPU_ACTUAL
20000418 00000428 d impure_data
20000840 00000004 D _impure_ptr
20000844 D _edata
20000844 B _sbss
20000844 b completed.8605
20000848 b object.8610
20000860 00000004 B systick_cycle_count
20000864 00000004 B scale_cpu_cycles_to_microseconds
20000868 00000004 B systick_millis_count
2000086c 00000001 B external_psram_size
20000870 00000004 b s_hotTemp
20000874 00000004 b s_hot_ROOM
20000878 00000004 b s_roomC_hotC
2000087c 00000004 b s_hotCount
20000880 00000004 B usb_timer0_callback
20000884 00000004 b endpointN_notify_mask
20000888 00000001 b sof_usage
2000088c 00000004 B usb_timer1_callback
20000890 00000001 B usb_high_speed
20000894 00000004 b endpoint0_notify_mask
20000898 00000001 b usb_reboot_timer
200008a0 00000008 b endpoint0_setupdata
200008a8 00000008 b reply_buffer
200008b0 00000008 b endpoint0_buffer
200008b8 00000001 B usb_configuration
200008bc 00000010 b rx_index
200008cc 00000002 b tx_packet_size
200008ce 00000001 b tx_noautoflush
200008cf 00000001 b tx_head
200008e0 00000100 b rx_transfer
200009e0 00000001 b rx_tail
200009e4 00000009 b rx_list
200009ee 00000002 b rx_packet_size
200009f0 00000010 b rx_count
20000a00 00000004 b rx_available
20000a04 00000001 b rx_head
20000a06 00000002 b tx_available
20000a08 00000001 B usb_cdc_line_rtsdtr
20000a20 00000080 b tx_transfer
20000aa0 00000004 B EventResponder::firstInterrupt
20000aa4 00000004 B EventResponder::lastInterrupt
20000aa8 00000004 B EventResponder::lastYield
20000aac 00000004 B EventResponder::firstYield
20000ab0 00000001 B EventResponder::runningFromYield
20000ab1 00000001 b yield::running
20000ab2 00000001 b calibrating
20000ab4 00000020 B HardwareSerial::s_serials_with_serial_events
20000ad4 00000001 B HardwareSerial::s_count_serials_with_serial_events
20000c00 00000010 B extmem_smalloc_pool
20001000 000002c0 B _VectorsRam
20002000 00000020 B endpoint0_transfer_data
20002020 00000020 B endpoint0_transfer_ack
20003000 00000280 B endpoint_queue_head
20003280 00000008 B usb_cdc_line_coding
20003288 00000004 B usb_cdc_line_rtsdtr_millis
200032c0 B _ebss
20078000 T _estack
20200000 0000004b B usb_descriptor_buffer
20200060 00001000 b rx_buffer
20201060 00002000 b txbuffer
20203060 b _heap_start
20280000 T _heap_end
60000000 00000200 T FlexSPI_NOR_Config
60001000 00000020 T ImageVectorTable
60001020 0000000c T BootData
6000102c 00000270 T ResetHandler
6000129c 000000f8 T configure_cache
60001394 000003bc T configure_external_ram
60001750 00000064 T usb_pll_start
600017b4 0000011c T tempmon_init
600018d0 000000ec T usb_init
600019bc 00000058 T analog_init
60001a14 00000016 V usb_string_product_name
60001a14 00000016 T usb_string_product_name_default
60001a2c 00000018 V usb_string_manufacturer_name
60001a2c 00000018 T usb_string_manufacturer_name_default
60001a44 00000004 T string0
60001a48 0000004b T usb_config_descriptor_12
60001a94 0000004b T usb_config_descriptor_480
60001ae0 0000000a t qualifier_descriptor
60001aea 00000001 T _serialEvent_default
60001aec T _init
60001af8 00000008 t __usb_init_serialnumber_veneer
60001b00 00000008 t __startup_late_hook_veneer
60001b08 00000008 t __sm_set_pool_veneer
60001b10 00000008 t __memset_veneer
60001b18 00000008 t __delay_veneer
60001b20 00000008 t ____libc_init_array_veneer
60001b28 00000008 t __startup_early_hook_veneer
60001b30 00000008 t __main_veneer
60001b38 00000008 t __set_arm_clock_veneer
60001b40 00000008 t __pwm_init_veneer
60001b48 t __frame_dummy_init_array_entry
60001b48 T __init_array_start
60001b48 T __preinit_array_end
60001b48 T __preinit_array_start
60001b4c T __init_array_end
60003d38 00000c00 T hab_csf
70000000 B _extram_end
70000000 B _extram_start
aaaaaaab A _flexram_bank_config

I'm not sure if the Arduino-Output is correct.. or I do miss something..
ebss is at 32c0, which is 12992 decimal - makes more sense(?)

Seems to a problem in the *.ld files and/or platform.txt
The displayed numbers are a bit off...

Frank B
11-23-2020, 07:39 AM
-> @kd5rxt-mark (https://forum.pjrc.com/members/71599-kd5rxt-mark) maybe your project works, despite of displayed "101%" RAM. Just try it.

defragster
11-23-2020, 09:05 AM
It has seemed the % used calc is accurate and fails when RAM abused and no room for stack - not included in those calcs.

@luni showed this the other day (https://forum.pjrc.com/threads/64480-makefile-interpreting-arm-none-eabi-size-output-am-I-over-any-limit-t4-1?p=259539&viewfull=1#post259539) - an edit to boards.txt on the .ld line:

@luni: --print-memory-usage is cool it works in boards.txt on the .ld line.

Edit like this - per processor:

teensy41.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax "-T{build.core.path}/imxrt1062_t41.ld"

Shows this on verbose build:

Memory region Used Size Region Size %age Used
ITCM: 64 KB 512 KB 12.50%
DTCM: 54080 B 512 KB 10.31%
RAM: 24736 B 512 KB 4.72%
FLASH: 73916 B 7936 KB 0.91%
ERAM: 0 GB 16 MB 0.00%

Where ITCM and DTCM share the same 512 KB TCM memory - Instructions and Data

Frank B
11-23-2020, 09:28 AM
Great!

you can just create a boards.local.txt (seems not to work on a MAC) ,

teensy41.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax "-T{build.core.path}/imxrt1062_t41.ld"
teensyMM.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax "-T{build.core.path}/imxrt1062_mm.ld"
teensy40.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax "-T{build.core.path}/imxrt1062.ld"
teensy36.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax,--defsym=__rtc_localtime={extra.time.local} "-T{build.core.path}/mk66fx1m0.ld"
teensy35.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax,--defsym=__rtc_localtime={extra.time.local} "-T{build.core.path}/mk64fx512.ld"
teensy31.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax,--defsym=__rtc_localtime={extra.time.local} "-T{build.core.path}/mk20dx256.ld"
teensy30.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax,--defsym=__rtc_localtime={extra.time.local} "-T{build.core.path}/mk20dx128.ld"
teensyLC.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax,--defsym=__rtc_localtime={extra.time.local} "-T{build.core.path}/mkl26z64.ld"

boards.local.txt stays and will not be overwritten by updates.

defragster
11-23-2020, 09:35 AM
Great!

you can just create a boards.local.txt (seems not to work on a MAC) ,

teensy41.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax "-T{build.core.path}/imxrt1062_t41.ld"
teensyMM.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax "-T{build.core.path}/imxrt1062_mm.ld"
teensy40.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax "-T{build.core.path}/imxrt1062.ld"

boards.local.txt stays and will not be overwritten by updates.

DONE! And tested to work with TSET in SublimeText - I already lost my prior edit with Beta5 install and had to look it up. Thanks for the reminder to do the .local. :: T:\arduino-1.8.13_t54\hardware\teensy\avr

It will of course need redone if the Arduino folder changes with a new IDE or other reason. Like the other day I deleted that Directory to make sure Beta 5 installed clean.

Frank B
11-23-2020, 10:17 AM
@Paul,
As you (maybe) touch the ld-files anyway - could you rename "RAM" to "OCRAM"?
That would make the output a little bit more logical.

mjs513
11-23-2020, 11:24 AM
Great!

you can just create a boards.local.txt (seems not to work on a MAC) ,

teensy41.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax "-T{build.core.path}/imxrt1062_t41.ld"
teensyMM.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax "-T{build.core.path}/imxrt1062_mm.ld"
teensy40.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax "-T{build.core.path}/imxrt1062.ld"
teensy36.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax,--defsym=__rtc_localtime={extra.time.local} "-T{build.core.path}/mk66fx1m0.ld"
teensy35.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax,--defsym=__rtc_localtime={extra.time.local} "-T{build.core.path}/mk64fx512.ld"
teensy31.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax,--defsym=__rtc_localtime={extra.time.local} "-T{build.core.path}/mk20dx256.ld"
teensy30.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax,--defsym=__rtc_localtime={extra.time.local} "-T{build.core.path}/mk20dx128.ld"
teensyLC.build.flags.ld=-Wl,--print-memory-usage,--gc-sections,--relax,--defsym=__rtc_localtime={extra.time.local} "-T{build.core.path}/mkl26z64.ld"

boards.local.txt stays and will not be overwritten by updates.

Very cool! Just did it myself on a Windows 10 machine. Thank you. :)

Frank B
11-23-2020, 11:39 AM
Very cool! Just did it myself on a Windows 10 machine. Thank you. :)

Thank Luni

PaulStoffregen
11-27-2020, 01:09 AM
Here is a fix for the serial monitor text selecting bug (https://forum.pjrc.com/threads/64303-Teensyduino-1-54-Beta-4?p=259625&viewfull=1#post259625), which was added by 1.54-beta4. Turns out I made a silly off-by-1 mistake while fixing the problem where a long line of text would force the serial monitor to horizontal scroll. That error would not manifest until much later, when selecting text or when the serial monitor would need to redraw its window.

To install this, extract the zip file and copy pde.jar to {Arduino}/lib. On Windows, the default Arduino folder is C:/Program Files (x86)/Arduino.

defragster
11-27-2020, 03:03 AM
Here is a fix for the serial monitor text selecting bug (https://forum.pjrc.com/threads/64303-Teensyduino-1-54-Beta-4?p=259625&viewfull=1#post259625), which was added by 1.54-beta4. Turns out I made a silly off-by-1 mistake while fixing the problem where a long line of text would force the serial monitor to horizontal scroll. That error would not manifest until much later, when selecting text or when the serial monitor would need to redraw its window.

To install this, extract the zip file and copy pde.jar to {Arduino}/lib. On Windows, the default Arduino folder is C:/Program Files (x86)/Arduino.

Seems to have made it right.

For Windows ZIP extract the file is :: {arduino}\lib

Frank B
11-29-2020, 08:47 PM
Reminder:

The information about the used memory is wrong.
Also for Teensy 3.x

Would be good to have that working :)

Memory region Used Size Region Size %age Used
FLASH: 7136 B 1 MB 0.68%
RAM: 3464 B 256 KB 1.32%

vs:

Der Sketch verwendet 8376 Bytes (0%) des Programmspeicherplatzes. Das Maximum sind 1048576 Bytes.
Globale Variablen verwenden 3112 Bytes (1%) des dynamischen Speichers, 259032 Bytes für lokale Variablen verbleiben. Das Maximum sind 262144 Bytes.

T4:

Memory region Used Size Region Size %age Used
ITCM: 32 KB 512 KB 6.25%
DTCM: 5376 B 512 KB 1.03%
RAM: 12384 B 512 KB 2.36%
FLASH: 15704 B 1984 KB 0.77%

vs:

Der Sketch verwendet 12628 Bytes (0%) des Programmspeicherplatzes. Das Maximum sind 2031616 Bytes.
Globale Variablen verwenden 38140 Bytes (7%) des dynamischen Speichers, 486148 Bytes für lokale Variablen verbleiben. Das Maximum sind 524288 Bytes.

Frank B
11-29-2020, 09:20 PM
... i'd remove the adding from platform.txt, and do the adds for all models "Teensy 4- like" in the linkerfiles.
Otherwise it will be difficult to get that right for all models.

recipe.size.pattern="{compiler.path}{build.toolchain}{build.command.siz e}" -A "{build.path}/{build.project_name}.elf"
recipe.size.regex=^(?:\.text|\.text\.progmem|\.tex t\.itcm|\.data)\s+([0-9]+).*
recipe.size.regex.eeprom=^(?:\.eeprom)\s+([0-9]+).*

I.e. for Teensy 4, for flash-size it would just be _flashimagelen (which is "internally" correct, but is not displayed?!?)
Similar for RAM.
Or, best, don't use the size-tool. It is not useful for Teensy 4, anyway.

Edit: For ESP 8266, it looks like this:

Executable segment sizes:
IROM : 228656 - code in flash (default or ICACHE_FLASH_ATTR)
IRAM : 26756 / 32768 - code in IRAM (ICACHE_RAM_ATTR, ISRs...)
DATA : 1252 ) - initialized variables (global, static) in RAM/HEAP
RODATA : 688 ) / 81920 - constants (global, static) in RAM/HEAP
BSS : 24880 ) - zeroed variables (global, static) in RAM/HEAP

Frank B
11-29-2020, 09:57 PM
@Paul, please edit platform.text and use this:
recipe.size.regex=^(?:\.text|\.text\.progmem|\.tex t\.itcm|\.data|\.text\.csf)\s+([0-9]+).*
This fixes the used flash (almost, 4 Bytes are still missing) (...whatever csf is...) for T4.x, at least (T3 still wrong)

PaulStoffregen
11-29-2020, 10:35 PM
@Paul, please edit platform.text and use this:
recipe.size.regex=^(?:\.text|\.text\.progmem|\.tex t\.itcm|\.data|\.text.csf)\s+([0-9]+).*

Ok, added. It'll be in 1.54-beta6.

...whatever csf is...

CSF is a digital signature format defined by NXP which can be appended to your program. Currently Teensy is configured to ignore it, and that configuration is locked so you can't make any Teensy actually enforce the signature. Well, except for 5 special boards I created a while back which have that setting unlocked.

The way CSF is supposed to work involves burning a SHA256 hash of your public key into the fuse memory. While NXP's "high assurance boot" is complicated, the essential idea is the contents of flash memory are checked against the CSF signature, and the CSF signature compared against the SHA256 hash. If you've turned on the security requirement (which can't be turned on for any Teensy, except those 5 test boards), the chip won't run your program unless both of those checks match. In other words, once you write that SHA256 hash and set the secure mode, the chip can only run code you have signed. Nobody else can create programs to run on a chip with the security set (and you can't either if you lose your private key). Setting the security is a permanent, utterly irreversible one-time operation. Once locked, there is no erase and no way to alter the private key hash.

The CSF data is meant to be appended after the compiler has produced the final binary output. Typical size for CSF (at least the relatively simple way that makes sense for Teensy) is about 3K to 4K.

Frank B
11-29-2020, 10:42 PM
That sounds like a very nice feature, for the future!

If missed a "\" backslash before ".csf" and inserterted it with a later edit. Don't know wether it is important - at least with windows it works without.

daj59
11-30-2020, 09:43 PM
The latest big sur 11.1 update doesn't load the teensyloader, it's also still crashing when opening arduino, but works on reload..it was doing this before but now as i said won't lode the loader?

PaulStoffregen
11-30-2020, 09:49 PM
The latest big sur 11.1 update doesn't load the teensyloader

Which Mac are you using? It is an Intel model or the new ARM M1?

daj59
11-30-2020, 09:51 PM
Which Mac are you using? It is an Intel model or the new ARM M1?

Intel macbook pro 2018

Deleted User
12-01-2020, 11:15 AM
What is that? Always that Apple Extra! Catalina solved, Big Sur on. Would it be rude to drop Mac support altogether to keep the development going? There need to be many and strong signals towards Cupertino!

ed: btw, i've recycled my Mac, because it was getting on my nerves with Catalina already.

Theremingenieur
12-01-2020, 02:25 PM
I strongly oppose against dropping Mac support. It looks like the new Apple Silicon based hardware will rather boost their market share:
https://appleinsider.com/articles/20/11/30/m1-mac-mini-catapulted-apple-to-number-one-in-japanese-desktop-pc-market

Seen how the "little" M1 outperforms already most Intel CPUs, I'd rather consider dropping the Wintel platform... ;)

mjs513
12-01-2020, 02:33 PM
.........

Seen how the "little" M1 outperforms already most Intel CPUs, I'd rather consider dropping the Wintel platform... ;) Funny person :) :) :)

Deleted User
12-01-2020, 02:39 PM
Apple users can still use one of the existent Windows or Linux VM solutions.
You can not burden a similar requirement onto people using a functional OS!
This completely arrogant Apple-tude needs to be grounded once, and hopefully forever.

At the End it is good, Apple reverts to console chips, showing their true colours.

There is no reason why a hold on Mac support has to be eternal. Once the Costermongers change their strategy from sucking and bullying users to making a working functional system, Mac support might be considered again.

Frank B
12-01-2020, 08:01 PM
platform.txt:

Is it possible to specify the teensy-mode for this line?
recipe.size.regex.data=

For T4, it would be just
recipe.size.regex.data=^(?:\.data|\.bss)\s+([0-9]+).*

Frank B
12-01-2020, 08:43 PM
..if you add something like

teensy40.build.flags.size=^(?:\.data|\.bss)\s+([0-9]+).*
to boards.txt and use it as {build.flags.size} in platform.txt it ends corrupted
as "^(?:\\.data|\\.bss)\\s+([0-9]+).*"

Is there a flag that can prevent this? Or a kind of escape-character?

TFTLCDCyg
12-02-2020, 04:45 AM
Thanks for your constant work on improving the working environment for teensy boards. Great effort.

I am getting familiar with the ILI9488_t3 library and the settings to SdFat. Today I was reviewing the JPEGDEC library; To migrate the old projects to the new screen, I was compiling some examples that worked well in the IDE 1.8.13 with the Teensy Loader 1.54-beta3.

Now with the Teensy Loader 1.54-beta5 only errors jump like rabbits!

C:\arduino-1.8.13\hardware\teensy\avr\libraries\SD\src/SD.h:159:49: error: 'FILE_READ' was not declared in this scope
File open(const char *filepath, uint8_t mode = FILE_READ) {
^
C:\arduino-1.8.13\hardware\teensy\avr\libraries\SD\src/SD.h: In member function 'virtual File SDClass::open(const char*, uint8_t)':
C:\arduino-1.8.13\hardware\teensy\avr\libraries\SD\src/SD.h:161:15: error: 'FILE_WRITE' was not declared in this scope
if (mode == FILE_WRITE) flags = O_RDWR | O_CREAT | O_AT_END;
^
JPG_decoder: In function 'void* myOpen(const char*, int32_t*)':
JPG_decoder:5: error: call to 'virtual File SDClass::open(const char*, uint8_t)' uses the default argument for parameter 2, which is not yet defined
myfile = SD.open(filename);
^
SliderJPG: In function 'void loop1()':
SliderJPG:5: error: call to 'virtual File SDClass::open(const char*, uint8_t)' uses the default argument for parameter 2, which is not yet defined
File dir = SD.open("/");

Is the JPEGDEC library still compatible with the settings made to SdFat (formerly SdFat beta)? .

Theremingenieur
12-02-2020, 10:27 AM
The latest big sur 11.1 update doesn't load the teensyloader, it's also still crashing when opening arduino, but works on reload..it was doing this before but now as i said won't lode the loader?

Can't confirm. Had Teensyduino crashing once on opening, but that problem disappeared after a reboot. Now opens consistently and launches the teensy loader as expected :
22713

Edit: Teensy loader can also be launched without problems from PlatformIO, still in Big Sur 11.1 beta :
22714

PaulStoffregen
12-02-2020, 12:12 PM
Now with the Teensy Loader 1.54-beta5 only errors jump like rabbits!

I was able to reproduce this problem. It's a bug in the new SD.h, where it's a bit too aggressive about undefining the incompatible FILE_READ and FILE_WRITE from SdFat.h. When headers are included in an unexpected order, as the JPEGDEC example does, SD.h was undefining the correct values, and then FS.h was not redefining them because it had already been included. That causes code elsewhere in SD.h to not compile because we undefined them, expecting FS.h to define them properly.

I've committed a fix on github.

https://github.com/PaulStoffregen/SD/commit/947085342ff7ce15d9e725fecc40572d10ff368b

PaulStoffregen
12-02-2020, 12:38 PM
I'm absolutely not going to drop Macintosh support. Anyone who's worried by the talk on this thread can consider can this message to be official word from PJRC. Mac support will continue. No need to worry - stand down from Red Alert. ;)

But seriously, I'm usually only able to fix problems I can reproduce one 1 of my 5 Macs (an old 11 inch Macbook Air, a 13 inch Macbook Air, a "trashcan" Mac Pro, and a really slow Mac Mini, and a very old 17 inch Macbook Pro). Currently those 5 machines have 10.7, 10.12, 10.13, 10.14 and 10.15 installed. I'm currently running a Time Machine backup on the 13 inch Macbook Air, which is the one with 10.15 Catalina installed. It's also the newest of my machines, from 2015. Later today I'll update it to Big Sur. This means I won't be able to test Catalina, unless I update one of the other machines or find a way to revert this machine.

FWIW, even though I haven't bought a Mac for 5 years, I do have 5 of them sitting around. I'm planning to get a 6th Mac with the new M1 chip, but hoping to wait until Apple releases a faster version with more RAM.

I'm guessing my Big Sur experience will be similar to what Theremingenieur showed, partly because Big Sur has been out for a while and this is only the first report of it not working. If it does work when I test, of course I'll give you a screenshot, and you can take that to mean I probably won't be able to resolve the problem unless you give my a *lot* of info that's often hard to find with Macs (and even then, odds are slim I'll figure it out from only tech info). If I can reproduce the problem, of course I'll work on a fix!

PaulStoffregen
12-02-2020, 01:02 PM
On the Big Sur issue, please check the System Preferences > Security & Privacy settings. First look at "Files and Folders" to check whether you've (perhaps unintentionally) disallowed the software to access files it needs.

This is a known issue on Catalina, where disallowing access to Documents causes the software to be unable to start up.

Maybe also look through the many other types of access on the left side column and check whether Teensyduino or Arduino or Teensy Loader are listed in any of them. Apple may have added more types of privacy restrictions in Big Sur, where disallowing access has (so far) unknown effects on the software. We do know 100% for sure that disallowing Documents causes Teensyduino to quit before it can fully start up, so these sorts of privacy restrictions can be a real problem if something the software needs is restricted.

Frank B
12-02-2020, 02:49 PM
Paul i'm not sure if I use the newest version of the Serial Monitor.
I'm using Windows. The problem with empty lines is gone. Good!

BUT:

With STRG+A, STRG+C it copies only a small part of the text in the monitor.
In my current example, 19 lines only . But there are many more.

TFTLCDCyg
12-02-2020, 03:01 PM
THX Paul.

I put these lines at the beginning of the SD.h file:

// Use FILE_READ & FILE_WRITE as defined by FS.h
#if defined(FILE_READ) && !defined(FS_H)
#endif
//#ifdef FILE_WRITE
#if defined(FILE_WRITE) && !defined(FS_H)
#undef FILE_WRITE
#endif
#include <FS.h>

Now both libraries: SD and JPEGDEC can coexist without problems.

https://www.mediafire.com/convkey/5366/15sesk1z2bvqi6kzg.jpg
Teensy 4 + ILI9488 3.5" + SD + JPEGDEC

Thanks for the prompt response.

Theremingenieur
12-02-2020, 03:09 PM
I'm absolutely not going to drop Macintosh support. Anyone who's worried by the talk on this thread can consider can this message to be official word from PJRC. Mac support will continue. No need to worry - stand down from Red Alert. ;)
Thank you! It's not because just I am a Mac user, but as I wrote above, odds are good that parts of the PC market will be overtaken by M1 based hardware in 2021/22.

But seriously, I'm usually only able to fix problems I can reproduce one 1 of my 5 Macs (an old 11 inch Macbook Air, a 13 inch Macbook Air, a "trashcan" Mac Pro, and a really slow Mac Mini, and a very old 17 inch Macbook Pro). Currently those 5 machines have 10.7, 10.12, 10.13, 10.14 and 10.15 installed. I'm currently running a Time Machine backup on the 13 inch Macbook Air, which is the one with 10.15 Catalina installed. It's also the newest of my machines, from 2015. Later today I'll update it to Big Sur. This means I won't be able to test Catalina, unless I update one of the other machines or find a way to revert this machine.
From my experience, at least on Intel based Macs, you can at 99.99% be sure that if something runs in Big Sur, it will also run in the latest Catalina. I'm running the latest Catalina on a 2012 Mac mini (it can't be updated further) and always the newest beta on my MacBook Pro. There are things which (temporarily, until fixed by the devs) don't run in Big Sur, but everything I use (including some weird USB over network redirection stuff) works well in Catalina. Never had the case that something which ran in Big Sur wouldn't run in Catalina.

KurtE
12-02-2020, 05:14 PM
Quick wondering... Usually I try to remove all warning from my programs and libraries...

But now when using the SD library I keep getting warning messages about including Time.h that should be replaced by TimeLib.h...

Problem is, the include of Time.h is in run time of the compiler...

"C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_CSI_41_OV7670_ILI.ino\\sketch\\CSI_41_OV7670_I LI.ino.cpp.o"
In file included from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\sys\stat.h:9:0,
from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\sys\_default_fcntl.h:188,
from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\sys\fcntl.h:4,
from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\fcntl.h:1,
from c:\arduino-1.8.13\hardware\teensy\avr\libraries\sdfat\src\com mon\fsapiconstants.h:30,
from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/ExFatLib/ExFatFile.h:36,
from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/ExFatLib/ExFatVolume.h:28,
from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/ExFatLib/ExFatLib.h:27,
from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/SdFat.h:33,
from C:\Users\kurte\Documents\Arduino\libraries\SD\src/SD.h:27,
from C:\Users\kurte\Documents\Arduino\Teensy Tests\CSI_41_OV7670_ILI\CSI_41_OV7670_ILI.ino:24:
C:\arduino-1.8.13\hardware\teensy\avr\libraries\Time/time.h:1:2: warning: #warning "Please include TimeLib.h, not Time.h. Future versions will remove Time.h" [-Wcpp]
And in programs that for example include SD.h in several source files, this gets repeated over and over again.

Wonder best way to suppress this? Change from #warning to #message or some such thing?

WMXZ
12-02-2020, 05:33 PM
Quick wondering... Usually I try to remove all warning from my programs and libraries...

But now when using the SD library I keep getting warning messages about including Time.h that should be replaced by TimeLib.h...

Problem is, the include of Time.h is in run time of the compiler...

"C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_CSI_41_OV7670_ILI.ino\\sketch\\CSI_41_OV7670_I LI.ino.cpp.o"
In file included from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\sys\stat.h:9:0,
from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\sys\_default_fcntl.h:188,
from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\sys\fcntl.h:4,
from c:\arduino-1.8.13\hardware\tools\arm\arm-none-eabi\include\fcntl.h:1,
from c:\arduino-1.8.13\hardware\teensy\avr\libraries\sdfat\src\com mon\fsapiconstants.h:30,
from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/ExFatLib/ExFatFile.h:36,
from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/ExFatLib/ExFatVolume.h:28,
from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/ExFatLib/ExFatLib.h:27,
from C:\arduino-1.8.13\hardware\teensy\avr\libraries\SdFat\src/SdFat.h:33,
from C:\Users\kurte\Documents\Arduino\libraries\SD\src/SD.h:27,
from C:\Users\kurte\Documents\Arduino\Teensy Tests\CSI_41_OV7670_ILI\CSI_41_OV7670_ILI.ino:24:
C:\arduino-1.8.13\hardware\teensy\avr\libraries\Time/time.h:1:2: warning: #warning "Please include TimeLib.h, not Time.h. Future versions will remove Time.h" [-Wcpp]
And in programs that for example include SD.h in several source files, this gets repeated over and over again.

Wonder best way to suppress this? Change from #warning to #message or some such thing?

I simply delete the Time.h file in Time library and use only TimeLib.h for the specific Arduino stuff (i.e. I anticipate the threatened action)
Sure in some cases there will be a missing functionality, but then edit the library to correct

Frank B
12-02-2020, 06:40 PM
Time.h / time.h: The problem is, Windows ignores the case of filenames (by default). There is a switch that can be set to switch that off for certain directories, but this is not the solution here, as it is complicated and needs Admin-rights.

Yes, best would be to delete this file. It is long enough marked as "deprecated" now. And the worst what could happen would be that most users DON'T get the wrong warning anymore, and a few users will see a correct errormessage.

KurtE
12-02-2020, 06:58 PM
Time.h / time.h: The problem is, Windows ignores the case of filenames (by default). There is a switch that can be set to switch that off for certain directories, but this is not the solution here, as it is complicated and needs Admin-rights.

Yes, best would be to delete this file. It is long enough marked as "deprecated" now. And the worst what could happen would be that most users DON'T get the wrong warning anymore, and a few users will see a correct errormessage.

I agree that might be the best approach here...
I did a quick search within sublimetext for all files under <Arduino install>/hardware/teensy/avr directory and found:

Searching 6638 files for ""Time.h""

C:\arduino-1.8.13\hardware\teensy\avr\libraries\Time\TimeLib. h:
25 // This ugly hack allows us to define C++ overloaded functions, when included
26 // from within an extern "C", as newlib's sys/stat.h does. Actually it is
27: // intended to include "time.h" from the C library (on ARM, but AVR does not
28 // have that file at all). On Mac and Windows, the compiler will find this
29: // "Time.h" instead of the C library "time.h", so we may cause other weird
30: // and unpredictable effects by conflicting with the C library header "time.h",
31 // but at least this hack lets us define C++ functions as intended. Hopefully
32 // nothing too terrible will result from overriding the C library header?!

4 matches in 1 file

Searching 6638 files for "<Time.h>"

C:\arduino-1.8.13\hardware\teensy\avr\libraries\Audio\extras\ miditones\miditones.c:
193 #include <ctype.h>
194 #include <stdbool.h>
195: #include <time.h>
196 #include <inttypes.h>
197

C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\stac k\fnet_stack_config.h:
635 /************************************************** ************************/ /*!
636 * @def FNET_CFG_TIME
637: * @brief FNET time() implementation, defined by <time.h>:
638 * - @c 1 = is enabled.
639 * - @c 0 = is disabled.

C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\stac k\fnet_timer.h:
113
114 #if FNET_CFG_TIME || defined(__DOXYGEN__)
115: #include <time.h>
116
117: #define fnet_time time /* Compliance with <time.h> */
118
119 /************************************************** *************************/ /*!

C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\thir d_party\mbedtls-2.12.0\src\net_sockets.c:
106 #include <stdio.h>
107
108: #include <time.h>
109
110 #include <stdint.h>

C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\thir d_party\mbedtls-2.12.0\src\timing.c:
65 #include <sys/time.h>
66 #include <signal.h>
67: #include <time.h>
68
69 struct _hr_time

C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\thir d_party\mbedtls-2.12.0\src\x509.c:
68 #endif
69 #if defined(MBEDTLS_HAVE_TIME_DATE)
70: #include <time.h>
71 #endif
72

C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\thir d_party\mbedtls-2.12.0\src\x509_crl.c:
61 #include <windows.h>
62 #else
63: #include <time.h>
64 #endif
65

C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\thir d_party\mbedtls-2.12.0\src\x509_crt.c:
67 #include <windows.h>
68 #else
69: #include <time.h>
70 #endif
71

C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\thir d_party\mbedtls-2.12.0\src\mbedtls\platform.h:
59 #include <stdio.h>
60 #include <stdlib.h>
61: #include <time.h>
62 #if !defined(MBEDTLS_PLATFORM_STD_SNPRINTF)
63 #if defined(_WIN32)

C:\arduino-1.8.13\hardware\teensy\avr\libraries\FNET\src\thir d_party\mbedtls-2.12.0\src\mbedtls\platform_time.h:
50 #else
51 /* For time_t */
52: #include <time.h>
53 typedef time_t mbedtls_time_t;
54 #endif /* MBEDTLS_PLATFORM_TIME_TYPE_MACRO */

11 #if (RH_PLATFORM == RH_PLATFORM_RASPI)
12 #include <sys/time.h>
13: #include <time.h>
14 #include "RasPi.h"
15

15 #if (RH_PLATFORM == RH_PLATFORM_RASPI)
16 #include <sys/time.h>
17: #include <time.h>
18 #include "RasPi.h"
19 #include <stdio.h>

11 #include <sys/time.h>
12 #include <unistd.h>
13: #include <time.h>
14
15 SerialSimulator Serial;

49 A weekly alarm is triggered every Sunday at 8:30:30
50
51: #include <Time.h>
52 #include <TimeAlarms.h>
53

15 matches across 14 files
Looks like many of them would be easy to get awy from. Looks like many/most of them are under some form of #if to either RASPI or windows..

WMXZ
12-02-2020, 07:13 PM
Looks like many of them would be easy to get awy from. Looks like many/most of them are under some form of #if to either RASPI or windows..

the ones <time.h> or "time.h" are probably genuine system libraries while "Time.h" should be changed, and then one can get rid of the "Time.h" file

Frank B
12-02-2020, 07:57 PM
Most if not all of them will just work when deleting Time.h
Even "TimeAlarms" seems to use it in the readme only?!? (did not look at the sourcecode)

Frank B
12-02-2020, 08:12 PM
@Paul, if you add a check to the 1.54 installer that allows an empty target directory (or at least an empty "... hardware/teensy/" directory) only, this would be way to have a clean install - (and you can get rid of Time.h) without having to delete something.

PaulStoffregen
12-02-2020, 10:00 PM
I completed the upgrade to MacOS Big Sur 11.0.1. Sure enough, just as Theremingenieur said in msg #40 (https://forum.pjrc.com/threads/64592-Teensyduino-1-54-Beta-5?p=261762&viewfull=1#post261762), this latest beta runs fine on Big Sur. Here's a screenshot from my freshly updated 13 inch Macbook Air.

22718

@daj59 - Did you try looking at the System Preferences > Security & Privacy settings, as I suggested on msg #43 (https://forum.pjrc.com/threads/64592-Teensyduino-1-54-Beta-5?p=261773&viewfull=1#post261773), to check if you've accidentally disallowed Teensyduino access to Documents or other things it needs?

daj59
12-03-2020, 12:42 AM
Many thanks,
The problem is updating to beta 11.1, it did indeed work fine on 11.01 release.
I will wait till the next release, currently there are a few other things not working quite right apart from teenysduino, I might come off the beta program.
David

PaulStoffregen;261844]I completed the upgrade to MacOS Big Sur 11.0.1. Sure enough, , this latest beta runs fine on Big Sur. Here's a screenshot from my freshly updated 13 inch Macbook Air.

PaulStoffregen
12-03-2020, 12:49 AM
Ah, now I see. Today was my very first use of MacOS Big Sur. When I read msg #30 (https://forum.pjrc.com/threads/64592-Teensyduino-1-54-Beta-5?p=261609&viewfull=1#post261609) "latest big sur 11.1", I didn't manage to equate "11.1" to mean a beta version.

I am going to keep support for MacOS, but I'm drawing the line at testing with Apple's betas. There's far too much work to do on the Teensy side to mess with those.

In other news, it seems rEFInd Boot Manager (https://www.rodsbooks.com/refind/) is incompatible with Big Sur. :(

Theremingenieur
12-03-2020, 10:15 AM
As I said in msg#40 (https://forum.pjrc.com/threads/64592-Teensyduino-1-54-Beta-5?p=261762&viewfull=1#post261762), the same applies to the 11.1 beta which is running here and which allowed me to take the screenshots of a working Teensyduino installation.
But I second Paul, it's a waste of time to test at least with early Apple betas. I've too often seen that things were newly introduced first and then removed in later betas. And that's why Apple tells everybody to not install betas on production machines ;)

defragster
12-03-2020, 07:16 PM
@Paul - the teensy Command line utilty was updated for T_4.x - but presented text still suggest: "The usage text does say it's just for the 3.x series"

I've seen two posts in recent days - it may be the download page or text in the code or both?

PaulStoffregen
12-03-2020, 07:32 PM
@Paul - the teensy Command line utilty was updated for T_4.x - but presented text still suggest: "The usage text does say it's just for the 3.x series

Updated the usage info.

Theremingenieur
12-03-2020, 10:29 PM
And everything works still in the (only hours old) Big Sur 11.1 beta 2 :

22728

PaulStoffregen
12-04-2020, 08:41 PM
Unrelated to Teensy, I'm going to be happy when Apple releases 11.1. The bright red background on 11.0 kinda hurts my eyes. Yeah, I know it can be changed in System Preferences - but for the sake of screenshots while testing I always leave the default background.

I'm still hoping to put off buying yet another Mac machine until the 2nd gen M1 chip.

Theremingenieur
12-04-2020, 10:44 PM
I’m afraid you will be disappointed, Paul. 11.1 has by default still the red background. To protect myself from getting eye cancer, I replaced it manually...

defragster
12-06-2020, 11:15 PM

When a New release of TeensyDuino is made an Admin can add a post like:

TeensyDuino 1.53 has been released.

For release notes and added information see :: pjrc.com/...Teensyduino-1-53-Released (https://forum.pjrc.com/threads/61623-Teensyduino-1-53-Released)

If seeing this email would be of interest then go to thread TeensyDuino-New-Release-Thread-Subscribe-for-notice-of-future-releases (https://forum.pjrc.com/threads/64978-TeensyDuino-New-Release-Thread-Subscribe-for-notice-of-future-releases)

and :: Click Thread Tools and select : "Subscribe to this thread ..."

>> It is a closed thread so it won't get pinged except for Admin release notes

defragster
12-07-2020, 09:37 AM
@Paul - what's up with included lib :: T:\arduino-1.8.13_t54\hardware\teensy\avr\libraries\Adafruit_ NeoPixel

Of course the raw Adafruit version does not work on Teensy, and of course they are updating it to include NRF's and whatever CPU of the month etc. And of course I got some of their NRF's so they put the LIB in sketchbook\libraries - and the build used it.

I got this 8 strip : protosupplies.com/.../ws2812-addressable-rgb-led-stick-module/ (https://protosupplies.com/product/ws2812-addressable-rgb-led-stick-module/)

CODE sample there uses : #include <Adafruit_NeoPixel.h>

I removed the sketchbook\libraries copy of the updated library.
But sample code calls things in an updated version so build breaks not having ColorHSV, gamma32 : strip.setPixelColor(i, strip.gamma32(strip.ColorHSV(pixelHue)));

I got the strip working removing the gamma32 and making an INO local unClass'y copy of : uint32_t ColorHSV(uint16_t hue, uint8_t sat, uint8_t val) {

It is working with hacked in (..., sat, val ) params like :: strip.setPixelColor(i, ColorHSV(pixelHue, 127, 127 ));

Actual Errors using linked code from product:

-fsingle-precision-constant -D__MK66FX1M0__ -DTEENSYDUINO=154 -DARDUINO=10600 -DARDUINO_TEENSY36 -DF_CPU=180000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IT:\\TEMP\\arduino_build_ws2812_leds.ino/pch" "-IT:\\arduino-1.8.13_t54\\hardware\\teensy\\avr\\cores\\teensy3" "-IT:\\arduino-1.8.13_t54\\hardware\\teensy\\avr\\libraries\\Adaf ruit_NeoPixel" "T:\\TEMP\\arduino_build_ws2812_leds.ino\\sketch\\w s2812_leds.ino.cpp" -o "T:\\TEMP\\arduino_build_ws2812_leds.ino\\sketch\\w s2812_leds.ino.cpp.o"
T:\tCode\LEDS_WS\ws2812_leds\ws2812_leds.ino: In function 'void rainbow(int)':
T:\tCode\LEDS_WS\ws2812_leds\ws2812_leds.ino:68:36 : error: 'class Adafruit_NeoPixel' has no member named 'gamma32'
strip.setPixelColor(i, strip.gamma32(strip.ColorHSV(pixelHue)));
^
T:\tCode\LEDS_WS\ws2812_leds\ws2812_leds.ino:68:50 : error: 'class Adafruit_NeoPixel' has no member named 'ColorHSV'
strip.setPixelColor(i, strip.gamma32(strip.ColorHSV(pixelHue)));
^
T:\tCode\LEDS_WS\ws2812_leds\ws2812_leds.ino: In function 'void theaterChaseRainbow(int)':
T:\tCode\LEDS_WS\ws2812_leds\ws2812_leds.ino:83:32 : error: 'class Adafruit_NeoPixel' has no member named 'gamma32'
uint32_t color = strip.gamma32(strip.ColorHSV(hue)); // hue -> RGB
^
T:\tCode\LEDS_WS\ws2812_leds\ws2812_leds.ino:83:46 : error: 'class Adafruit_NeoPixel' has no member named 'ColorHSV'
uint32_t color = strip.gamma32(strip.ColorHSV(hue)); // hue -> RGB
^
Using library Adafruit_NeoPixel at version 1.1.7 in folder: T:\arduino-1.8.13_t54\hardware\teensy\avr\libraries\Adafruit_ NeoPixel
exit status 1

Reading the product page it notes:

The program below uses the Adafruit NeoPixel library to exercise the stick. It is a shortened version of the strandtest example program that is installed when the library is downloaded
Using the Strandtest.INO of course works from the library installed with TeensyDuino 1.54b5 - given right pin # and # LEDS

KurtE
12-07-2020, 01:52 PM
I just happen to have an 8 led setup on my desk...

Note: I have not tried the version installed by Teensyduino in awhile but instead have the Adafruit version installed.

I ran the simple strand test with T3.6 and it runs. Note the Strandtest does not appear to play with all 8 of these LEDS when I set it to 8 count, works OK with set to 16...

Next will try with T4.1... Appears to be working.

May next check with Teensy version of library.

EDIT - I removed the Adafruit version from my library folder and loaded up the strand test from the Teensy and it appears to run.

@Paul - I am wondering if you wish for one of us to sync up to the Adafruit current code and/or do like some of the display drivers and no longer install it, but instead allow users to install directly from Adafruit either by github or Library Manager ?

PaulStoffregen
12-07-2020, 02:05 PM
but instead allow users to install directly from Adafruit either by github or Library Manager ?

Yeah, it's probably time to stop including an old copy of Adafruit_NeoPixel if Adafruit's latest is working well.

KurtE
12-07-2020, 02:58 PM
Hi Paul, I probably need to do some double checking. With the 8 pixel thingy I am seeing some semi add results with pixel addressing. But not 100% sure exactly how it is configured ;)

#define LED_PIN 6 // Pin used to address the LEDs
#define LED_COUNT 8 // How many NeoPixels are attached to the Arduino?
// Declare our NeoPixel strip object:
Adafruit_NeoPixel strip(LED_COUNT, LED_PIN, NEO_GRB + NEO_KHZ800);

void step() {
Serial.println("Press any key to continue");
while (Serial.read() == -1);
while (Serial.read() != -1);
}

//================================================== =============================
// Initialization
//================================================== =============================
void setup() {
while (!Serial && millis() < 5000) ;
Serial.begin(115200);
strip.begin(); // INITIALIZE NeoPixel strip object (REQUIRED)
strip.show(); // Turn OFF all pixels ASAP
strip.setBrightness(50); // Set BRIGHTNESS to about 1/5 (max = 255)
step();
for (uint8_t i = 0; i < LED_COUNT; i++) {
strip.setPixelColor(i, strip.Color(127, 0, 0)); // Set pixel's color (in RAM)
strip.show(); // Update strip to match
step();
}

}

22782

And looking at the pictures(left to right top to bottom) first one turns red, second one turns green, then Bright green...
Will rerun with T3.6... Then go back to your version to see if same? Then maybe grab another Neopixel Bar or ring I have sitting around.

EDIT::: My mistake, did not know these were RGBW leds (Cool) , so now back to Adafruit library...

KurtE
12-07-2020, 03:21 PM
Yeah, it's probably time to stop including an old copy of Adafruit_NeoPixel if Adafruit's latest is working well.
Actually I am not sure where you are grabbing the version you are putting into the releases right now? It for sure does not match what is in your github project: https://github.com/PaulStoffregen/Adafruit_NeoPixel

The sources don't match nor the github one does not compile for T4.x...

defragster
12-07-2020, 06:29 PM
See post #64 :: Latest ( update here dated 11/29/2020 ) :: "the raw Adafruit version does not work on Teensy"

Question "what's up with included lib" :: Was because I tried to add the needed Class parts and got bad fails with the quick paste. Didn't go as far as 'CodeCompare' as the diffs looked significant with all the AdaF added boards just paging from the top.

So it either needs:
> Teensy Tweaks into AdaFruit to drop it from TD
> AdaF Tweaks into TeensyDuino
> or just a known deficient library.

About once a month I spend 5 minutes thinking about the Adafruit NRF Sense / CLUE boards for a project - and Library Manager updated a Dozen or more AdaFruit libraries, so they are a moving target

KurtE
12-07-2020, 09:38 PM
Note: I have the Adafruit version installed through the library manager: 1.2.0 - The library manager does not show me any updates available on it...
Also WinMerge of my grab of their github and the released version appear to be the same.

I went to the website you mentioned and downloaded their sketch:

// A basic everyday NeoPixel strip test program.

#define LED_PIN 1 // Pin used to address the LEDs
#define LED_COUNT 8 // How many NeoPixels are attached to the Arduino?
// Declare our NeoPixel strip object:
Adafruit_NeoPixel strip(LED_COUNT, LED_PIN, NEO_GRBW + NEO_KHZ800);

//================================================== =============================
// Initialization
//================================================== =============================
void setup() {
strip.begin(); // INITIALIZE NeoPixel strip object (REQUIRED)
strip.show(); // Turn OFF all pixels ASAP
strip.setBrightness(50); // Set BRIGHTNESS to about 1/5 (max = 255)
}

//================================================== =============================
// Main
//================================================== =============================
void loop() {
// Fill along the length of the strip in various colors...
colorWipe(strip.Color(255, 0, 0), 50); // Red
colorWipe(strip.Color( 0, 255, 0), 50); // Green
colorWipe(strip.Color( 0, 0, 255), 50); // Blue

// Do a theater marquee effect in various colors...
theaterChase(strip.Color(127, 127, 127), 50); // White, half brightness
theaterChase(strip.Color(127, 0, 0), 50); // Red, half brightness
theaterChase(strip.Color( 0, 0, 127), 50); // Blue, half brightness

rainbow(10); // Flowing rainbow cycle along the whole strip
theaterChaseRainbow(50); // Rainbow-enhanced theaterChase variant
}

// Fill strip pixels one after another with a color.
void colorWipe(uint32_t color, int wait) {
for(int i=0; i<strip.numPixels(); i++) { // For each pixel in strip...
strip.setPixelColor(i, color); // Set pixel's color (in RAM)
strip.show(); // Update strip to match
delay(wait); // Pause for a moment
}
}

// Theater-marquee-style chasing lights.
void theaterChase(uint32_t color, int wait) {
for(int a=0; a<10; a++) { // Repeat 10 times...
for(int b=0; b<3; b++) { // 'b' counts from 0 to 2...
strip.clear(); // Set all pixels in RAM to 0 (off)
// 'c' counts up from 'b' to end of strip in steps of 3...
for(int c=b; c<strip.numPixels(); c += 3) {
strip.setPixelColor(c, color); // Set pixel 'c' to value 'color'
}
strip.show(); // Update strip with new contents
delay(wait); // Pause for a moment
}
}
}

// Rainbow cycle along whole strip.
void rainbow(int wait) {
for(long firstPixelHue = 0; firstPixelHue < 5*65536; firstPixelHue += 256) {
for(int i=0; i<strip.numPixels(); i++) {
int pixelHue = firstPixelHue + (i * 65536L / strip.numPixels());
strip.setPixelColor(i, strip.gamma32(strip.ColorHSV(pixelHue)));
}
strip.show(); // Update strip with new contents
delay(wait); // Pause for a moment
}
}

// Rainbow-enhanced theater marquee. Pass delay time (in ms) between frames.
void theaterChaseRainbow(int wait) {
int firstPixelHue = 0; // First pixel starts at red (hue 0)
for(int a=0; a<30; a++) { // Repeat 30 times...
for(int b=0; b<3; b++) { // 'b' counts from 0 to 2...
strip.clear(); // Set all pixels in RAM to 0 (off)
for(int c=b; c<strip.numPixels(); c += 3) {
int hue = firstPixelHue + c * 65536L / strip.numPixels();
uint32_t color = strip.gamma32(strip.ColorHSV(hue)); // hue -> RGB
strip.setPixelColor(c, color); // Set pixel 'c' to value 'color'
}
strip.show(); // Update strip with new contents
delay(wait); // Pause for a moment
firstPixelHue += 65536 / 90; // One cycle of color wheel over 90 frames
}
}
}

Edited it to use pin 1 and RGBW
Build looks like using right libraries:

ultiple libraries were found for "Adafruit_NeoPixel.h"
Not used: C:\arduino-1.8.13\hardware\teensy\avr\libraries\Adafruit_NeoP ixel
Using library Adafruit_NeoPixel at version 1.7.0 in folder: C:\Users\kurte\Documents\Arduino\libraries\Adafrui t_NeoPixel
"C:\\arduino-1.8.13\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_584113/zzz.ino.elf"
Sketch uses 25052 bytes (0%) of program storage space. Maximum is 8126464 bytes.
Global variables use 45748 bytes (8%) of dynamic memory, leaving 478540 bytes for local variables. Maximum is 524288 bytes.
C:\Program Files\TyQt\TyCommanderC.exe upload --autostart --wait --multi C:\Users\kurte\AppData\Local\Temp\arduino_build_58 4113/zzz.ino.TEENSY41.hex
Waiting for user selection

and it appears to be running fine. (I also just verified that it will compile for T3.6 as well)

defragster
12-07-2020, 09:46 PM
Opened IDE and updated Adafruit Neopixel is 1.7.0 here:
22788

Maybe 1.2.0 is a typo as build above shows: Using library Adafruit_NeoPixel at version 1.7.0 in folder: C:\Users\kurte\Documents\Arduino\libraries\Adafrui t_NeoPixel

defragster
12-07-2020, 10:12 PM
More Oddity - with AdaF neopixel in and latest 1.7.0, neither of these compile to T_3.6 ::TD strandtest nor included :: T:\tCode\libraries\Adafruit_NeoPixel\examples\stra ndtest\strandtest.ino

>> Same strip IDE compiles and runs this fine on AdaFruit NRF Bluefruit Sense with latest AdaFruit_NeoPixel lib installed.

<EDIT>:: Doing a T_3.6 BUILD IN IDE WORKS TOO !?!?!?! Building in SubLimeText is where the error is coming from?

This line in both errors - this from AdaFruit build with T_3.6:: starting with this > Adafruit_NeoPixel strip(LED_COUNT, LED_PIN, NEO_GRB + NEO_KHZ800);

T:\TEMP\arduino_build_strandtest.ino\sketch\strand test.ino.cpp.o: In function rainbow(int)':
T:\tCode\libraries\Adafruit_NeoPixel\examples\stra ndtest/strandtest.ino:120: undefined reference to Adafruit_NeoPixel::ColorHSV(unsigned short, unsigned char, unsigned char)'
T:\tCode\libraries\Adafruit_NeoPixel\examples\stra ndtest/strandtest.ino:120: undefined reference to Adafruit_NeoPixel::gamma32(unsigned long)'
T:\TEMP\arduino_build_strandtest.ino\sketch\strand test.ino.cpp.o: In function theaterChaseRainbow(int)':
T:\tCode\libraries\Adafruit_NeoPixel\examples\stra ndtest/strandtest.ino:139: undefined reference to Adafruit_NeoPixel::ColorHSV(unsigned short, unsigned char, unsigned char)'
T:\tCode\libraries\Adafruit_NeoPixel\examples\stra ndtest/strandtest.ino:139: undefined reference to Adafruit_NeoPixel::gamma32(unsigned long)'
T:\TEMP\arduino_build_strandtest.ino\sketch\strand test.ino.cpp.o: In function __static_initialization_and_destruction_0':
T:\tCode\libraries\Adafruit_NeoPixel\examples\stra ndtest/strandtest.ino:26: undefined reference to Adafruit_NeoPixel::Adafruit_NeoPixel(unsigned short, unsigned short, unsigned short)'
collect2.exe: error: ld returned 1 exit status
%
Multiple libraries were found for "Adafruit_NeoPixel.h"
Not used: T:\arduino-1.8.13_t54\hardware\teensy\avr\libraries\Adafruit_ NeoPixel
Using library Adafruit_NeoPixel at version 1.7.0 in folder: T:\tCode\libraries\Adafruit_NeoPixel
exit status 1

The TeensyDuino strandtest doesn't use those new exotic functions and only errors on the constructor as above:

T:\TEMP\arduino_build_strandtest.ino\sketch\strand test.ino.cpp.o: In function __static_initialization_and_destruction_0':
T:\arduino-1.8.13_t54\hardware\teensy\avr\libraries\Adafruit_ NeoPixel\examples\strandtest/strandtest.ino:17: undefined reference to Adafruit_NeoPixel::Adafruit_NeoPixel(unsigned short, unsigned short, unsigned short)'
collect2.exe: error: ld returned 1 exit status
%
Multiple libraries were found for "Adafruit_NeoPixel.h"
Not used: T:\arduino-1.8.13_t54\hardware\teensy\avr\libraries\Adafruit_ NeoPixel
Using library Adafruit_NeoPixel at version 1.7.0 in folder: T:\tCode\libraries\Adafruit_NeoPixel
exit status 1

KurtE
12-07-2020, 10:13 PM
Sorry Typo was/is 1.7.0

The gamma32
Should be defined at:

defragster
12-07-2020, 10:14 PM
Just updated above ... for some reason SublimeText has failed to duplicate and build for first time?

It is working on T_3.6 when built from IDE ????

defragster
12-07-2020, 10:24 PM
Just updated above ... for some reason SublimeText has failed to duplicate and build for first time?

It is working on T_3.6 when built from IDE ????

FIXED with CLEAN build! There was something stuck in TEMP build cache from last try it seems and linking didn't see the new lib?

Indeed - building :: T:\tCode\libraries\Adafruit_NeoPixel\examples\stra ndtest\strandtest.ino

Works on T_3.6 and T_4.1 and T_4.0 ( on FRDM 4236 ) all on Pin #33 AND a T_3.2 on pin #6

>> So the 'deal' is ::
This TeensyDuino library seems to be removable :: T:\arduino-1.8.13_t54\hardware\teensy\avr\libraries\Adafruit_ NeoPixel\

Thanks for followup @KurtE : I wonder if AdaF NeoPixel was update from the NOV update to the version 1.7.0 today? Something put bad 'cached' build files in TEMP :(

tf3cy
12-08-2020, 03:55 PM
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 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

isaacjacobson
12-10-2020, 08:20 PM
I have noticed an issue where using a microSD over SPI is now at reduced speed and performance in Teensyduino 1.54 Beta 5.

While using Teensy 4.0 with Audio Shield Adapter with 1.54 Beta 5, I noticed that some of my sketches had a significantly reduced speed/performance.

After running the "SDCardTest" here were my results (Teensy 4.0 with Audio Shield Adapter):

Teensyduino 1.51

SD Card Test
------------
SD card is connected :-)
Card type is SDHC
File system space is 15466.05 Mbytes.
SD library is able to access the filesystem

Overall speed = 1.67 Mbyte/sec
Worst block time = 0.72 ms
24.78% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV:
Overall speed = 1.51 Mbyte/sec
Worst block time = 1.34 ms
46.15% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV staggered:
Overall speed = 1.51 Mbyte/sec
Worst block time = 1.02 ms
35.02% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV:
Overall speed = 1.49 Mbyte/sec
Worst block time = 1.98 ms
68.35% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV staggered:
Overall speed = 1.50 Mbyte/sec
Worst block time = 1.59 ms
54.80% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV:
Overall speed = 1.49 Mbyte/sec
Worst block time = 2.59 ms
89.17% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV staggered:
Overall speed = 1.49 Mbyte/sec
Worst block time = 1.64 ms
56.42% of audio frame time

Teensyduino 1.53

SD Card Test
------------
File system space is 15466.05 Mbytes.
SD library is able to access the filesystem

Overall speed = 1.63 Mbyte/sec
Worst block time = 0.74 ms
25.33% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV:
Overall speed = 1.48 Mbyte/sec
Worst block time = 1.35 ms
46.67% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV staggered:
Overall speed = 1.48 Mbyte/sec
Worst block time = 1.00 ms
34.33% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV:
Overall speed = 1.46 Mbyte/sec
Worst block time = 1.97 ms
68.04% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV staggered:
Overall speed = 1.46 Mbyte/sec
Worst block time = 1.33 ms
45.84% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV:
Overall speed = 1.46 Mbyte/sec
Worst block time = 2.65 ms
91.41% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV staggered:
Overall speed = 1.46 Mbyte/sec
Worst block time = 1.68 ms
57.87% of audio frame time

Teensyduino 1.54 Beta 5

SD Card Test
------------
SD card is connected :-)
Card type is SDHC
File system space is 15466.05 Mbytes.
SD library is able to access the filesystem

Overall speed = 1.01 Mbyte/sec
Worst block time = 0.99 ms
33.98% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV:
Overall speed = 0.89 Mbyte/sec
Worst block time = 2.59 ms
89.27% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV staggered:
Overall speed = 0.89 Mbyte/sec
Worst block time = 2.14 ms
73.79% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV:
Overall speed = 0.89 Mbyte/sec
Worst block time = 3.57 ms
123.01% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV staggered:
Overall speed = 0.89 Mbyte/sec
Worst block time = 2.74 ms
94.37% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV:
Overall speed = 0.87 Mbyte/sec
Worst block time = 4.84 ms
166.82% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV staggered:
Overall speed = 0.90 Mbyte/sec
Worst block time = 2.97 ms
102.37% of audio frame time

Frank B
12-10-2020, 08:33 PM
Oh, that's a lot slower.

Frank B
12-10-2020, 09:21 PM
An other question:
https://github.com/PaulStoffregen/SPI/blob/master/SPI.h#L1236

uint8_t transfer(uint8_t data) {
// TODO: check for space in fifo?
port().TDR = data;
while (1) {
uint32_t fifo = (port().FSR >> 16) & 0x1F;
if (fifo > 0) return port().RDR;
}
//port().SR = SPI_SR_TCF;
//port().PUSHR = data;
//while (!(port().SR & SPI_SR_TCF)) ; // wait
//return port().POPR;
}

Why is the check for free space in the queue still missing?
From my understanding, this can lead to serious errors, esp with foreign code that does not use the block transfer functions.
Just assume very slow SPI (khz Range).

I'm asking here, because this is so obvious (too obvious) that I must assume I miss something.
Otherwise I'd already done a PR...

Edit:
Oh, it waits for an incomming byte.. so this never fills the fifo... :) think before post..

WMXZ
12-11-2020, 06:00 AM
I have noticed an issue where using a microSD over SPI is now at reduced speed and performance in Teensyduino 1.54 Beta 5.

Did you reformat the SD card before each test? which Filesystem was on Card?

Frank B
12-11-2020, 07:41 AM
Mine is even slower.. 0.82MB/s for a single file (T4 + Audioshield, Sandisk Ultra 16GB, formatted with official tool)
That's a serious regression.
Any Idea what happened?

Frank B
12-11-2020, 07:57 AM
GCC 10 says:

"C:\\Arduino\\hardware\\teensy/../tools/arm10/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fexceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=154 -DLOG_LEVEL=0 -DARDUINO=10813 -DARDUINO_TEENSY40 -DF_CPU=816000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-Ie:\\temp\\arduino_build_966437/pch" "-IC:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy 4" "-IC:\\Arduino\\hardware\\teensy\\avr\\libraries\\SD \\src" "-IC:\\Arduino\\hardware\\teensy\\avr\\libraries\\Sd Fat\\src" "-IC:\\Arduino\\hardware\\teensy\\avr\\libraries\\SP I" "e:\\temp\\arduino_build_966437\\sketch\\SdCardTest .ino.cpp" -o "e:\\temp\\arduino_build_966437\\sketch\\SdCardTest .ino.cpp.o"
In file included from C:\Arduino\hardware\teensy\avr\libraries\SdFat\src/SdCard/SdSpiCard.h:35,
from C:\Arduino\hardware\teensy\avr\libraries\SdFat\src/SdCard/SdCard.h:28,
from C:\Arduino\hardware\teensy\avr\libraries\SdFat\src/SdFat.h:32,
from C:\Arduino\hardware\teensy\avr\libraries\SD\src/SD.h:27,
from C:\Arduino\hardware\teensy\avr\libraries\Audio\exa mples\HardwareTesting\SD_Card\SdCardTest\SdCardTes t.ino:15:
SdCardTest: In function 'void setup()':
c:\arduino\hardware\teensy\avr\libraries\sdfat\src \spidriver\sdspidriver.h:49:38: warning: conversion from 'long unsigned int' to 'uint8_t' {aka 'unsigned char'} changes value from '50000000' to '128' [-Woverflow]
49 | #define SD_SCK_MHZ(maxMhz) (1000000UL*(maxMhz))
| ~~~~~~~~~~^~~~~~~~~~
c:\arduino\hardware\teensy\avr\libraries\sdfat\src \spidriver\sdspidriver.h:52:24: note: in expansion of macro 'SD_SCK_MHZ'
52 | #define SPI_FULL_SPEED SD_SCK_MHZ(50)
| ^~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\Audio\exa mples\HardwareTesting\SD_Card\SdCardTest\SdCardTes t.ino:57:22: note: in expansion of macro 'SPI_FULL_SPEED'
57 | status = card.init(SPI_FULL_SPEED, SDCARD_CS_PIN);
| ^~~~~~~~~~~~~~
Compiling libraries...

WMXZ
12-11-2020, 08:38 AM
One explanation could be that with transition to FS.h and SdFat_V2 the configuration must be (re)considered.

Frank B
12-11-2020, 10:15 AM
One explanation could be that with transition to FS.h and SdFat_V2 the configuration must be (re)considered.

Looks like ist just uses the SPI library.
I have my instruments in the cellar(still) - can you measure the SPI clock?

Frank B
12-11-2020, 11:37 AM
sd.h:

#define SD_CARD_TYPE_SD1 0
#define SD_CARD_TYPE_SD2 1
#define SD_CARD_TYPE_SDHC 3
class Sd2Card
{
public:
bool init(uint8_t speed, uint8_t csPin) {
return SD.begin(csPin);
}

I'd change that to bool init(uint32_t speed, uint8_t csPin)
...and as speed seems to be ignored anyway, i'd mark it deprecated (with the correspronding gcc attribute) and add a new bool init(uint8_t csPin).
This is more tranparent for the user(and me ;) ), too, as it don't makes him think "Oh, I can adjust the speed"

@Paul, do you want a PR?

Frank B
12-11-2020, 11:56 AM
not sure if it is my installation or something else... the GCC-9 linker gets confused by SdCardTest example:

e:\temp\arduino_build_729709\libraries\SD\SD.cpp.o :(.ARM.extab.text._ZN7SDClass4openEPKch[_ZN7SDClass4openEPKch]+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol __gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
e:\temp\arduino_build_729709\libraries\SD\SD.cpp.o :(.ARM.exidx.text._ZN7SDClass4openEPKch[_ZN7SDClass4openEPKch]+0x4): relocation truncated to fit: R_ARM_PREL31 against .ARM.extab.text._ZN7SDClass4openEPKch'
e:\temp\arduino_build_729709\sketch\SdCardTest.ino .cpp.o:(.ARM.extab.text._ZN6SDFile12openNextFileEh[_ZN6SDFile12openNextFileEh]+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol __gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
e:\temp\arduino_build_729709\sketch\SdCardTest.ino .cpp.o:(.ARM.exidx.text._ZN6SDFile12openNextFileEh[_ZN6SDFile12openNextFileEh]+0x4): relocation truncated to fit: R_ARM_PREL31 against .ARM.extab.text._ZN6SDFile12openNextFileEh'
e:\temp\arduino_build_729709\sketch\SdCardTest.ino .cpp.o:(.ARM.extab.text._ZN6SDFileD0Ev[_ZN6SDFileD5Ev]+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol __gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
e:\temp\arduino_build_729709\sketch\SdCardTest.ino .cpp.o:(.ARM.exidx.text._ZN6SDFileD0Ev[_ZN6SDFileD5Ev]+0x4): relocation truncated to fit: R_ARM_PREL31 against .ARM.extab.text._ZN6SDFileD0Ev'
e:\temp\arduino_build_729709\sketch\SdCardTest.ino .cpp.o:(.ARM.extab.text._ZN6SDFileD2Ev[_ZN6SDFileD5Ev]+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol __gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
e:\temp\arduino_build_729709\sketch\SdCardTest.ino .cpp.o:(.ARM.exidx.text._ZN6SDFileD2Ev[_ZN6SDFileD5Ev]+0x4): relocation truncated to fit: R_ARM_PREL31 against .ARM.extab.text._ZN6SDFileD2Ev'
e:\temp\arduino_build_729709\sketch\SdCardTest.ino .cpp.o:(.ARM.extab.text.setup+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol __gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
e:\temp\arduino_build_729709\sketch\SdCardTest.ino .cpp.o:(.ARM.exidx.text.setup+0x4): relocation truncated to fit: R_ARM_PREL31 against .ARM.extab.text.setup'
e:\temp\arduino_build_729709\libraries\SdFat\FatLi b\FatFileLFN.cpp.o:(.ARM.exidx.text._ZN7FatFile4op enEPS_P7fname_ti+0x4): additional relocation overflows omitted from the output
collect2.exe: error: ld returned 1 exit status

WMXZ
12-11-2020, 12:37 PM
can you measure the SPI clock?
running the program (SdCardTest) on T4.0+AudioCard SPI clock is 16 MHz with 0.19 us between bytes

Yes, that is set in SD
BUT you can override this with SD.sdfs.begin(...)
That is why sdfs is public in FS

Frank B
12-11-2020, 12:40 PM
Thank you!
That seems a bit slow to me... and the 190ns do not look perfect, too.

Frank B
12-11-2020, 01:08 PM
Yes, that is set in SD
BUT you can override this with SD.sdfs.begin(...)
That is why sdfs is public in FS

That does not help much...
A) nobody (including me) knows that
B) the examples do not use it
C) the existing libraries do not use it.

It is a bit strange that it does not use a higher Speed by default.
Everything in Arduino is made for beginners-we do not even have the simplest "recompile" or the possibility to set project defines.. and on the other hand this beginner gets a slow SD without any warning or hints how to solve that :) this is not intuitive. we really should change this :)

You just can't give the user a slow SD on the fastest Microcontroller..

Even if this means to wait with this update.

Frank B
12-11-2020, 01:13 PM
...if the 50MHZ is too high, ok, then we have to write a speed-test that tests the max possible, reliable speed (can run on init() ) and uses that for SD.

PaulStoffregen
12-11-2020, 02:41 PM
It is a bit strange that it does not use a higher Speed by default.

I had the default at 24 MHz. Then during testing 16 MHz was suggested, maybe for certain non-PJRC hardware. Maybe we should put it back higher again?

I believe the SD card spec says 25 MHz is the official limit for SPI, though that is from memory.... should probably look it up.

Frank B
12-11-2020, 03:38 PM
I had the default at 24 MHz. Then during testing 16 MHz was suggested, maybe for certain non-PJRC hardware. Maybe we should put it back higher again?

I believe the SD card spec says 25 MHz is the official limit for SPI, though that is from memory.... should probably look it up.

Consequently, you would then have to make it so slow that those awful adapters with level-shifters work.
I don't think that's a good argument.
You shouldn't make your hardware slower to support bad 3rd party adapters.
But that's just my opinion.

In addition you disturb existing programs with it, which depend on higher speed - which did exist. So you introduce a new incompatibility.
I would not do that :)

Frank B
12-11-2020, 03:43 PM
My memory says, all SDHC cards support 50MHz.. but have to look it up, too.. :)

(And now I'll try to find my scope and LA... and try to find the reason for the 190ns gaps)

KurtE
12-11-2020, 03:55 PM
By default I think it should be the same speed as the last Teensyduino release...
Which I believe was:

#define SD_SPI_SPEED SPISettings(25000000, MSBFIRST, SPI_MODE0)

It will be interesting to see how many compatibility issues we run into with the FS.h introduction and differences in things like File Open options.

WMXZ
12-11-2020, 04:31 PM
There is more than speed on SPI performance
here are the three cases as I see them

status = SD.begin(SDCARD_CS_PIN); // 0.92 MB/s - 0.91 Mb/s
// status = SD.sdfs.begin(SdSpiConfig(SDCARD_CS_PIN, SHARED_SPI, 50'000'000)); // 1.36 Mb/s - 1.35 MB/s
// status = SD.sdfs.begin(SdSpiConfig(SDCARD_CS_PIN, DEDICATED_SPI, 50'000'000)); // 5.18 Mb/s - 1.35 MB/s

(first speed number single file access, second number multiple file access)

Apart from the discussion what should be the default speed: speed that works always, or speed someone is used to,
switching from shared_spi to dedicated spi increases speed by a factor of 4,
switching between files may reduce the effective speed significantly.
Anyhow I appreciate the fact that I can bypass SD.begin

Frank B
12-11-2020, 06:08 PM
(And now I'll try to find my scope and LA... and try to find the reason for the 190ns gaps)
The reason for the gaps is this:

_ccr = LPSPI_CCR_SCKDIV(div) | LPSPI_CCR_DBT(div/2) | LPSPI_CCR_PCSSCK(div/2);

I have not enough experience with SPI-Hardware. I guess we can reduce "DBT" and "PCSSCK", or make it const - not "div" dependend - but that should do someone with more experience.
However, it has only a small impact.

Frank B
12-11-2020, 06:12 PM
// status = SD.sdfs.begin(SdSpiConfig(SDCARD_CS_PIN, DEDICATED_SPI, 50'000'000)); // 5.18 Mb/s - 1.35 MB/s

I see the same speedup.
What is different with "DEDICATED_SPI"?

KurtE
12-11-2020, 06:38 PM
I see the same speedup.
What is different with "DEDICATED_SPI"?
I could be wrong, but I only find it in the library SdFs....

If I remember correctly @WMXZ mentioned it recently as a possible extension to one or more of our libraries, where you more or less say that the SD is the only thing on the SPI buss and as such, you can avoid calling beginTransaction and endTransaction.

PaulStoffregen
12-11-2020, 06:55 PM
What is different with "DEDICATED_SPI"?

Bill explained (at least as I recall) that is leaves the card in a state where you're still making a multi-block access even your code isn't really accessing the card. It gives a huge improvement in sequential access for a single file, when that file is stored sequentially on the media.

However, it might negatively impact random access performance or accessing multiple files.

WMXZ
12-11-2020, 07:20 PM
AFAIK, DEDICATED_SPI effectively does not call begin and end transaction.
@FrankB a change from 1.36 MHz to 5.18 MHz is indeed a a major improvement from SHARED_SPI to DEDICATED_SPI

Frank B
12-11-2020, 09:41 PM
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"

vjmuzik
12-12-2020, 11:42 PM
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 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

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.

defragster
12-13-2020, 12:03 AM
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"

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 ???

Frank B
12-15-2020, 09:49 PM
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.

FrankTest
12-16-2020, 10:47 AM
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:

=========================== USB Port3 ===========================

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

========================== Summary =========================
Vendor ID : 0x1FC9 (NXP Semiconductors)
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)#U SB(3), ACPI(_SB_)#ACPI(PCI0)#ACPI(GP17)#ACPI(XHC1)#ACPI(R HUB)#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\Contro l\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)
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 "
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?

Frank B
12-16-2020, 10:48 AM
oops, sorry, that ^^^^^ (Post#105) was me.

KurtE
12-16-2020, 12:49 PM
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

Frank B
12-16-2020, 07:06 PM
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

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.

https://www.nxp.com/docs/en/application-note/AN12852.pdf

mjs513
12-16-2020, 07:47 PM
@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 :).

defragster
12-16-2020, 08:11 PM
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

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?

Frank B
12-16-2020, 08:19 PM
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..

Frank B
12-17-2020, 08:08 AM
@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.

Frank B
12-17-2020, 08:20 AM
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?

PaulStoffregen
12-17-2020, 10:29 AM
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.

The PT8211 constructor should use memset() to zero its buffer memory before it turns on the DMA hardware.

emmanuel63
12-20-2020, 09:24 AM
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.

Thanks for all your work.
Emmanuel

Frank B
12-26-2020, 09:43 AM
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...)

Frank B
12-26-2020, 10:19 AM
@emmanuel63: If you upload the whole project somewhere, including the sound files, I can try to find & fix the bug.

chipaudette
12-26-2020, 03:38 PM
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

emmanuel63
12-26-2020, 05:43 PM
@frankB: installing the 1.54 beta has solved the problem. I can read mono wav files from SD without latency and artefacts.

Frank B
12-26-2020, 06:12 PM
Ah, ok, i thought you used 1.54 before, because you posted the problem here in this thread.

Frank B
12-26-2020, 10:24 PM
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...
Currently, it is used well below its spec...
Or is there something else against it that I am not aware of?

KurtE
12-26-2020, 11:35 PM
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...
Currently, it is used well below its spec...
Or is there something else against it that I am not aware of?

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.

Frank B
12-27-2020, 08:03 AM
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.

defragster
12-27-2020, 09:43 AM
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.

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.

Frank B
12-27-2020, 10:04 AM
Can you point out the needed change?

bootdata.c,
0x00030401, // lutCustomSeqEnable,serialClkFreq,sflashPadType,dev iceType

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.

defragster
12-27-2020, 10:17 AM

bootdata.c,
0x00030401, // lutCustomSeqEnable,serialClkFreq,sflashPadType,dev iceType

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

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.
I'd see it from the other side: Why put on a brake that is not necessary? This makes no sense.

Agreed that it is not quite right to artificially limit it - if testing show it stable at closer to SPEC speeds.
LittleFS will process some megabytes in a matter of seconds.
Test just done on QSPI chip did "Bytes read 219461632, written 49676288" in 3.27 minutes or 1,300,183 I/O Bytes/sec so the 32KB cache will only be of 'some' help, and a quick 'n'o Verify will drop the read back after write so it would almost never be in the same place twice for the cache to help.

So :: 0x00060401, // lutCustomSeqEnable,serialClkFreq,sflashPadType,dev iceType
or :: 0x00080401, // lutCustomSeqEnable,serialClkFreq,sflashPadType,dev iceType

Would change the speed from ? to ?? and ??.
- maybe it is in the link ... but ... time for Z's

Frank B
12-27-2020, 10:54 AM
Good night :)

A benchmark would involve reading some megabytes of random adresses in the the program flash area.
A simple test with coremark running in flash showed 10% improvement - but that was very quick and dirty.

But: A benchmark is not needed if you switch off an artificial brake.

defragster
12-27-2020, 10:05 PM
...

So :: 0x00060401, // lutCustomSeqEnable,serialClkFreq,sflashPadType,dev iceType
or :: 0x00080401, // lutCustomSeqEnable,serialClkFreq,sflashPadType,dev iceType
...

From the linked post ::
0x00030401, // lutCustomSeqEnable,serialClkFreq,sflashPadType,dev iceType << 60 MHz
0x00080401, // lutCustomSeqEnable,serialClkFreq,sflashPadType,dev iceType << 133 MHz

Will do a baseline at 60 MHz then repeat at 133 MHz on LittleFS _Program for 'reference' and see it there is a measurable change worth looking into

chipaudette
12-27-2020, 10:18 PM
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

And, any chance of the non-emulated MTP Serial option (direct from the WMXZ repo) being folded into Teensyduino instead of the emulated serial? There are certain serial interactions that break when using emulated serial.

Chip

defragster
12-27-2020, 11:44 PM
Good night :)

A benchmark would involve reading some megabytes of random adresses in the the program flash area.
A simple test with coremark running in flash showed 10% improvement - but that was very quick and dirty.

But: A benchmark is not needed if you switch off an artificial brake.

@Frank B - just see look for obvious benefit in something somehow testable with the work in progress for LittleFS - results are here : pjrc.com/threads/58033-LittleFS-port-to-Teensy-SPIFlash (https://forum.pjrc.com/threads/58033-LittleFS-port-to-Teensy-SPIFlash?p=264779&viewfull=1#post264779)
Running Program Flash at 133 versus current 60 MHz seems to make no significant/detectable difference.

Run time for both was 2.75 Min doing file create, extend, delete in some pattern across 26 files with writes of ~5K to 310K and reads that big or larger on each write and read again on delete: Bytes read 155,625,472, written 49,676,288

There should have been SOME change ... it almost seems like the QSPI is being held back as similar external FLASH timing changes have little effect and SPI is not always half the speed of QSPI.

KurtE
12-28-2020, 01:08 AM
And, any chance of the non-emulated MTP Serial option (direct from the WMXZ repo) being folded into Teensyduino instead of the emulated serial? There are certain serial interactions that break when using emulated serial.

Chip

Actually I hope it is not directly... i.e. that it has its' own Product ID and not use the all of everything PID...

Hopefully at some point in the near future, would be great if we had the MTP stuff as part of Teensyduino.

PaulStoffregen
12-28-2020, 02:46 AM
There are certain serial interactions that break when using emulated serial.

Could you be more specific about which things don't work?

WMXZ
12-28-2020, 07:24 AM
MTP per se does not need Serial connection, but MTP is usually integrated in other programs that need serial connections.

Seremu without Arduino monitor is a little bit complicated.
Consider headless hosts in embedded remote devices.
AFAIK, there is no standard terminal program on standard hosts that is capable of Seremu. Sure there are work around for Linux (cat / echo), but for me that is not a good replacement of a terminal program.
For USB_MTPDISK_SERIAL it first needs a own PID, then download needs to be aware of this PID.
At that point we could test and eventually generate PR to cores.

Frank B
12-28-2020, 08:47 AM
There should have been SOME change ...

It just says
a) the test is not good and perhaps measures the cache instead or something else.
or
b) There was a additional change that makes something slow, as my test back in march showed a speedup.

I don't care. If you want 60MHz for the flash, just leave it as it it. The reason why I mentioned it here because there was no reaction, back in march. That's all.
Don't want to pollute this thread here with unwanted discussions.

Edit: If you use even higher numbers, you'll see the Teensy crashing. I take this as a proof that the clock changes.
Edit2: Nope, i re-read the manual. The highest allowed number is 9.

Frank B
12-29-2020, 09:25 AM
I'm trying to implement a callstack-print - as a first step, for hardfaults only.
Paul, during the Teensy 4.0 beta phase you said we can have more startup_hooks - would you mind to add one, for this purpose?
( after usb_init() )
I know there is the late hook - but it would be better to add a new one, reserved for this.

My idea is to copy the needed information to OCRAM, which survives a soft reset.
The hardfault just copies some data to OCRAM, then resets.
After reset, when the CPU is in a clean state again and USB is initialized, the hook would check if there is any information and print it.

defragster
12-29-2020, 10:31 AM
That seems like a worthy adventure Frank! You can certainly start with the late hook. I suggested those two spots because the processor arrived at those two spots only to wait in the while( time... ) - so adding short code there for user would have no impact for the parts of the system that are usable.

Having another weak debug_hook() there to do the check for fault_exit would be nice - though not much you can do there - unless UART output or configured for I/O activity - until USB online in setup() given the RAM2 (OCRAM?) will still be safe? It almost seems the startup_late_hook() would be too early? If called just before main() then everything is usable (once serial is online) and you could immediately precede setup() and act before any code there without the user needing to add any setup() code?

Note: Paul already reserved a HAB boot storage area in the .ld for RAM2 for recording a failure in that - you probably saw that though.

Frank B
12-29-2020, 11:38 AM
It detects and prints a mpu nullptr trap already, after reset. So, I think I can get the rest working, too. I'll open a new thread when it is time for it.

Callstack Data found:
Size: 46 CSFR: 0x82 XPSR: 0x0
non usage fault
(DACCVIOL) Data Access Violation
(MMARVALID) MemMange Fault Address Valid: 0x0

Have to pause now, time for a family visit.

Note: Paul already reserved a HAB boot storage area in the .ld for RAM2 for recording a failure in that - you probably saw that though.
Yup!
Can I use that area for my data? I think the HAB boot storage area is useful only after Power-on - is that right? If so, can i overwrite it?

PaulStoffregen
12-29-2020, 11:50 AM
Run time for both was 2.75 Min doing file create, extend, delete in some pattern across 26 files with writes of ~5K to 310K and reads that big or larger on each write and read again on delete: Bytes read 155,625,472, written 49,676,288

There should have been SOME change ... it almost seems like the QSPI is being held back as similar external FLASH timing changes have little effect and SPI is not always half the speed of QSPI.

Your LittleFS benchmarks are measuring the flash chip's page write and sector erase time.

To test this, you would need to write a large file to the chip, then measure the speed of many seek-then-read operations at various locations within the file. Separate those seek positions by at least 2K (the FlexSPI's internal buffer).

Edit: If you use even higher numbers, you'll see the Teensy crashing. I take this as a proof that the clock changes.
Edit2: Nope, i re-read the manual. The highest allowed number is 9.

The original reason for 60 MHz was Table 37 in the electrical specs.

23020

Also, in the early days I had imagined we would use QPI & DTR mode, which only supports about half the maximum clock speed. But I abandoned that plan after I discovered QPI mode confuses NXP's ROM. I considered making the bootloader able to detect & recover, but ultimately decided that would be too risky - and it would utterly stymie people from running their code on boards without the bootloader chip.

But we are indeed running with RXCLKSRC = 01. I double checked just now. And as far as I know, we're using only the features Winbond rates to run at max speed. So it looks like we can go up to 133 MHz.

However, we've been running with less than the recommended value of 3 in the CS signals setup and hold times.

23021

Let's give 133 MHz a try, but with those at the recommended value.

https://github.com/PaulStoffregen/cores/commit/c346fc36ed97dcaed2fa1d70626fbd80cf35586d

And just to be clear, there's no way I will consider making 166 MHz the default, since both Table 38 and Winbond's datasheet say 133 MHz is the maximum. 166 MHz can only be used (safely within spec) on special flash chips providing a dedicated DQS signal.

mjs513
12-29-2020, 01:28 PM
To test this, you would need to write a large file to the chip, then measure the speed of many seek-then-read operations at various locations within the file. Separate those seek positions by at least 2K (the FlexSPI's internal buffer). First thanks for the explanation. Really does help.

Have one question what is your definition of "MANY", have a feeling my definition would be a lot less than yours :)

PaulStoffregen
12-29-2020, 02:15 PM
Even 1 seek+read from the middle of a 16kbybe file might give useful timing if measured with the ARM cycle counter.

My gut feeling is the timing should be pretty consistent, assuming reads are done far enough apart to avoid the FlexSPI buffer and access to PSRAM isn't competing for the QSPI bandwidth.

Like developing any benchmark, experimentation and careful thought is needed when results aren't as expected. But if the timing is consistent, I'd just pick a number of iterations that lets the benchmark complete in a few seconds. No point wasting human time for diminishing returns.

defragster
12-29-2020, 06:34 PM
Your LittleFS benchmarks are measuring the flash chip's page write and sector erase time.

To test this, you would need to write a large file to the chip, then measure the speed of many seek-then-read operations at various locations within the file. Separate those seek positions by at least 2K (the FlexSPI's internal buffer).

...

Let's give 133 MHz a try, but with those at the recommended value.

https://github.com/PaulStoffregen/cores/commit/c346fc36ed97dcaed2fa1d70626fbd80cf35586d

And just to be clear, there's no way I will consider making 166 MHz the default, since both Table 38 and Winbond's datasheet say 133 MHz is the maximum. 166 MHz can only be used (safely within spec) on special flash chips providing a dedicated DQS signal.

Made the linked 133 MHz changes in bootdata.c and it worked for LittleFS test as done before.

That LFSintegrity was designed to assure data integrity, and test the exposed LFS interface - was just easy to run those commands and get a general feel for 'Speed in use' in the LFS case. It does a series of general operations , writing 3MB to formatted media, deleting that, then reFormatted for first use of a series of file I/O - writing 49MB and reading 155 MB in 2.83 M

Posted more on the LittleFS thread (https://forum.pjrc.com/threads/58033-LittleFS-port-to-Teensy-SPIFlash?p=264974#post264974) but in rerunning Post #719 series Summary no speed change (https://forum.pjrc.com/threads/58033-LittleFS-port-to-Teensy-SPIFlash?p=264779&viewfull=1#post264779) for better or worse.

Frank B
12-29-2020, 06:44 PM
And just to be clear, there's no way I will consider making 166 MHz the default
Nobody wanted this. On the contrary, I was thinking of suggesting the next lower speed as well. ;-)

mjs513
12-29-2020, 07:41 PM
Even 1 seek+read from the middle of a 16kbybe file might give useful timing if measured with the ARM cycle counter.

My gut feeling is the timing should be pretty consistent, assuming reads are done far enough apart to avoid the FlexSPI buffer and access to PSRAM isn't competing for the QSPI bandwidth.

Like developing any benchmark, experimentation and careful thought is needed when results aren't as expected. But if the timing is consistent, I'd just pick a number of iterations that lets the benchmark complete in a few seconds. No point wasting human time for diminishing returns.

Did a modification of the Bench sketch but using LittleFS_Program, and added in a random read timing loop. Write/Read blocksizes are 2048bytes and I used random to jump around the file (16k) in 2048 byte increments:

--------------------------------------------
LittleFS Test
Disk Stats:
Bytes Used: 8192, Bytes Total:6291456
Benchmark:
FILE_SIZE = 16384
BUF_SIZE = 2048 bytes

Starting write test, please wait.
write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
496.48,5214,3447,4086
512.00,5006,3446,3987
512.00,4018,3428,3987
496.48,4657,3557,4112
512.00,4554,3357,3987

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
115380.28,30,8,17
303407.41,8,6,6
309132.06,7,6,6
309132.06,7,6,6
309132.06,8,6,6
Done

Number of random reads: 1
Number of blocks: 8

read speed and latency
speed,max,min,avg
Position (bytes), Block: 0, 0
Read Time (ARM Cycle Delata): 3959
KB/Sec,usec,usec,usec
1820444.50,0,0,1
Position (bytes), Block: 8192, 4
Read Time (ARM Cycle Delata): 4223
KB/Sec,usec,usec,usec
1820444.50,0,0,1
Position (bytes), Block: 10240, 5
Read Time (ARM Cycle Delata): 4707
KB/Sec,usec,usec,usec
1638400.00,0,0,1
Position (bytes), Block: 2048, 1
Read Time (ARM Cycle Delata): 3953
KB/Sec,usec,usec,usec
1820444.50,0,0,1
Position (bytes), Block: 6144, 3
Read Time (ARM Cycle Delata): 5068
KB/Sec,usec,usec,usec
1638400.00,0,0,1

Done
Ran it with and without the 133mhz change to core and really no difference. Without is below:

Number of random reads: 1
Number of blocks: 8

read speed and latency
speed,max,min,avg
Position (bytes), Block: 0, 0
Read Time (ARM Cycle Delata): 3959
KB/Sec,usec,usec,usec
1820444.50,0,0,1
Position (bytes), Block: 8192, 4
Read Time (ARM Cycle Delata): 4223
KB/Sec,usec,usec,usec
1638400.00,0,0,1
Position (bytes), Block: 10240, 5
Read Time (ARM Cycle Delata): 4707
KB/Sec,usec,usec,usec
1638400.00,0,0,1
Position (bytes), Block: 2048, 1
Read Time (ARM Cycle Delata): 3953
KB/Sec,usec,usec,usec
1820444.50,0,0,1
Position (bytes), Block: 6144, 3
Read Time (ARM Cycle Delata): 4929
KB/Sec,usec,usec,usec
1489454.50,0,0,1 Just is case I did something wrong heres the modified sketch:

#include <LittleFS.h>
#include <Streaming.h>
LittleFS_Program myfs;

#define cout Serial

char szDiskMem[] = "PRO_DISK";

// File size in bytes.
const uint32_t FILE_SIZE = 16 * 1024;

// Set SKIP_FIRST_LATENCY true if the first read/write to the SD can
// be avoid by writing a file header or reading the first record.
const bool SKIP_FIRST_LATENCY = true;

// Size of read/write.
const size_t BUF_SIZE = 2048;

// Write pass count.
const uint8_t WRITE_COUNT = 5;

// Read pass count.
const uint8_t READ_COUNT = 5;

//Block size for qspi
#define MYBLKSIZE 2048 // 2048

// Insure 4-byte alignment.
uint32_t buf32[(BUF_SIZE + 3)/4];
uint8_t* buf = (uint8_t*)buf32;

//Number of random reads

File file, file1;

void setup() {
while (!Serial) ; // wait
Serial.println("LittleFS Test"); delay(5);
if (!myfs.begin(1024 * 1024 * 6)) {
Serial.printf("Error starting %s\n", szDiskMem);
}

//myfs.lowLevelFormat('.');

float s;
uint32_t t;
uint32_t maxLatency;
uint32_t minLatency;
uint32_t totalLatency;
bool skipLatency;

myfs.remove("bench.dat");
//for(uint8_t cnt=0; cnt < 10; cnt++) {

// fill buf with known data
if (BUF_SIZE > 1) {
for (size_t i = 0; i < (BUF_SIZE - 2); i++) {
buf[i] = 'A' + (i % 26);
}
buf[BUF_SIZE-2] = '\r';
}
buf[BUF_SIZE-1] = '\n';

Serial.println("Disk Stats:");
Serial.printf("Bytes Used: %llu, Bytes Total:%llu\n", myfs.usedSize(), myfs.totalSize());
Serial.printf("Benchmark:\n");
cout << F("FILE_SIZE = ") << FILE_SIZE << endl;
cout << F("BUF_SIZE = ") << BUF_SIZE << F(" bytes\n");
cout << F("Starting write test, please wait.") << endl << endl;

// do write test
uint32_t n = FILE_SIZE/BUF_SIZE;
cout <<F("write speed and latency") << endl;
cout << F("speed,max,min,avg") << endl;
cout << F("KB/Sec,usec,usec,usec") << endl;

// open or create file - truncate existing file.
file = myfs.open("bench.dat", FILE_WRITE);

for (uint8_t nTest = 0; nTest < WRITE_COUNT; nTest++) {
file.seek(0);

maxLatency = 0;
minLatency = 9999999;
totalLatency = 0;
skipLatency = SKIP_FIRST_LATENCY;
t = millis();

for (uint32_t i = 0; i < n; i++) {
uint32_t m = micros();
if (file.write(buf, BUF_SIZE) != BUF_SIZE) {
Serial.println("write failed");
}
m = micros() - m;
totalLatency += m;
if (skipLatency) {
// Wait until first write to SD, not just a copy to the cache.
skipLatency = file.position() < 512;
} else {
if (maxLatency < m) {
maxLatency = m;
}
if (minLatency > m) {
minLatency = m;
}
}
}

t = millis() - t;
s = file.size();
cout << s/t <<',' << maxLatency << ',' << minLatency;
cout << ',' << totalLatency/n << endl;
}
cout << endl << F("Starting sequential read test, please wait.") << endl;
cout << endl <<F("read speed and latency") << endl;
cout << F("speed,max,min,avg") << endl;
cout << F("KB/Sec,usec,usec,usec") << endl;

// do read test
for (uint8_t nTest = 0; nTest < READ_COUNT; nTest++) {
file.seek(0);
maxLatency = 0;
minLatency = 9999999;
totalLatency = 0;
skipLatency = SKIP_FIRST_LATENCY;
t = micros();
for (uint32_t i = 0; i < n; i++) {
buf[BUF_SIZE-1] = 0;
uint32_t m = micros();
int32_t nr = file.read(buf, BUF_SIZE);
if (nr != BUF_SIZE) {
}
m = micros() - m;
totalLatency += m;
if (buf[BUF_SIZE-1] != '\n') {
Serial.println("data check error");
}
if (skipLatency) {
skipLatency = false;
} else {
if (maxLatency < m) {
maxLatency = m;
}
if (minLatency > m) {
minLatency = m;
}
}
}

s = file.size();

t = micros() - t;
cout << s*1000/t <<',' << maxLatency << ',' << minLatency;
cout << ',' << totalLatency/n << endl;
}

cout << endl << F("Done") << endl;

cout << endl << F("Starting random read test, please wait.") << endl;

Serial.printf("Number of blocks: %d\n", n);

cout << endl <<F("read speed and latency") << endl;
cout << F("speed,max,min,avg") << endl;

uint32_t tt;
// do read test
for (uint8_t nTest = 0; nTest < READ_COUNT; nTest++) {
file.seek(0);
maxLatency = 0;
minLatency = 0;
totalLatency = 0;
skipLatency = SKIP_FIRST_LATENCY;
t = micros();
for (uint32_t i = 0; i < randomReads; i++) {
buf[BUF_SIZE-1] = 0;
uint32_t m = micros();
uint32_t block_pos = random(0, (n-1));
uint32_t random_pos = block_pos* MYBLKSIZE;
cout << "Position (bytes), Block: " << random_pos << ", ";
cout << block_pos << endl;
uint32_t startCNT = ARM_DWT_CYCCNT;
file.seek(random_pos);
int32_t nr = file.read(buf, BUF_SIZE);
uint32_t endCNT = ARM_DWT_CYCCNT;
cout << F("Read Time (ARM Cycle Delata): ") << endCNT-startCNT << endl;
if (nr != BUF_SIZE) {
}
m = micros() - m;
totalLatency += m;
if (buf[BUF_SIZE-1] != '\n') {
Serial.println("data check error");
}
if (skipLatency) {
skipLatency = false;
} else {
if (maxLatency < m) {
maxLatency = m;
}
if (minLatency > m) {
minLatency = m;
}
}
}

s = file.size();

t = micros() - t;
cout << F("KB/Sec,usec,usec,usec") << endl;
cout << s*1000/t <<',' << maxLatency << ',' << minLatency;
cout << ',' << totalLatency/n << endl;
}
cout << endl << F("Done") << endl;

file.close();

}

void loop() {
// put your main code here, to run repeatedly:

}

defragster
12-29-2020, 09:41 PM
@mjs513 - will add that ... same question from other thread ... where is : "Streaming.h"

mjs513
12-29-2020, 09:52 PM
@mjs513 - will add that ... same question from other thread ... where is : "Streaming.h"

Sorry didn’t see that yet. Comes from here http://arduiniana.org/libraries/streaming/. I can’t remember if I made changes to it... been awhile. But looks like someone else is maintaining it

https://www.arduinolibraries.info/libraries/streaming

defragster
12-29-2020, 09:54 PM
Sorry didn’t see that yet. Comes from here http://arduiniana.org/libraries/streaming/. I can’t remember if I made changes to it... been awhile. But looks like someone else is maintaining it

https://www.arduinolibraries.info/libraries/streaming

Ick? - maybe will just suffer and change them to prinf()'s - luckily I didn't do that already with RAMDOM'ly updated code :)

mjs513
12-29-2020, 09:57 PM
Actually now that I am thinking about it doesn’t safari have a streaming class. The cout came from the original bench sketch

mjs513
12-29-2020, 10:26 PM
Ick? - maybe will just suffer and change them to prinf()'s - luckily I didn't do that already with RAMDOM'ly updated code :)

Ok. I was right SdFat allows you do cout stuff.

Replace Streaming.h and #define cout with the following 2 lines:

#include <sdios.h>
// Serial output stream
ArduinoOutStream cout(Serial); Now no need for Streaming.h. Its part of the SdFat library.

defragster
12-29-2020, 11:56 PM
Ok. I was right SdFat allows you do cout stuff.

Replace Streaming.h and #define cout with the following 2 lines:

#include <sdios.h>
// Serial output stream
ArduinoOutStream cout(Serial); Now no need for Streaming.h. Its part of the SdFat library.

Seems better but now is wants to do this ... have to kill the adafruit:

Not used: T:\arduino-1.8.13_t54\hardware\teensy\avr\libraries\SdFat

All good and done - see LittleFS thread ...

Frank B
12-30-2020, 02:04 PM
Ok, seems my "hardfault/callstack" project died sooner than i thought.
gcc -unwind tables produces a linker error. So, it is not possible to walk through the stack, because there is no way to identify the location of the return adresses. But even gcc -mpoke function names produces a not-working binary, so I could'nt print the function names even if i could find the addresses..
All I can do is to print the type of the hardfault. Not too useful.. have to stop here.

KurtE
12-30-2020, 05:51 PM
Ok, seems my "hardfault/callstack" project died sooner than i thought.
gcc -unwind tables produces a linker error. So, it is not possible to walk through the stack, because there is no way to identify the location of the return adresses. But even gcc -mpoke function names produces a not-working binary, so I could'nt print the function names even if i could find the addresses..
All I can do is to print the type of the hardfault. Not too useful.. have to stop here.

I wondered how far you could go. I know on some other systems, I would add code in to walk back the stack frame, but did not see any obvious way to get there.

Was maybe at least hoping that one could at least identify the address of the where the fault happened.

Frank B
12-30-2020, 05:57 PM
Was maybe at least hoping that one could at least identify the address of the where the fault happened.
Yes, this is possible. (https://forum.pjrc.com/threads/59125-Is-there-a-hook-to-know-when-the-on-off-pin-on-the-Teensy-4-0-has-been-grounded?p=265401&viewfull=1#post265401)
A walk through, not.

Frank B
12-30-2020, 06:05 PM
Post #719 series Summary no speed change (https://forum.pjrc.com/threads/58033-LittleFS-port-to-Teensy-SPIFlash?p=264779&viewfull=1#post264779) for better or worse.
Try this:

PROGMEM const char lorem[]="Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.";

volatile char x;

void setup() {
while(!Serial);
delay(10);

unsigned long t = ARM_DWT_CYCCNT;
for (int i = 0; i < 20; i+=1) x = lorem[i*8];

t = ARM_DWT_CYCCNT - t;
Serial.println(t);
Serial.println(x);
}

void loop() {}

Not sure if the optimization plays a role - I used "fast". You'll see >250 Cycles difference (60Mhz vs. 133Mhz) for these RANDOM reads ;)
Edit: it is a littly tricky to get around the cache AND the gcc optimization... therefore the funny loop.

KurtE
12-30-2020, 06:37 PM
Not sure if this is the best thread to ask this, but I have been having fun seeing what I can screw up ;)
Or more specifically trying out stuff using some new stuff like FS.h, LittleFS, SD, MTP... And playing around with how one might use some of this stuff, to see where maybe it makes sense to expand some of the stuff for example in FS.h.

Example suppose I wish have an MTP aware sketch, which for example suppose that the sketch maybe generates log files and the like and the program may be controlled by some form of configuration file.
What other things might I want?

a) I might want to know if MTP is connected and that there is an MTP session. Not sure exactly when the best trigger point is? On Start Session? Don't know at what granularity you may wish to know things.
Example if You have two storages installed, maybe you wish to know that the 2nd storage you added, if at least the top level of this storage has been enumerated or not...

b) You might want to know if the host PC updated anything as maybe you wish to reflect this on the Teensy. Example suppose your Teensy is running a sketch and maybe has a larger display like RA8875 running sort of a tablet sketch. Maybe one of the modes that sketch may run is showing your local file system and allow you to locally create new files, delete files... This is where that code needs to notify the host about the changes (some of the stuff I have been playing with). But likewise if the host deletes some files, you would like to know that to update your list on the screen...
Maybe you simply have some notification per storage, of has something changed?

c) Sort of part of b) but suppose you have a configuration file you store in your storage, that somehow controls your sketch, maybe a set of sound files or color for LEDS, or maybe a new python script to run...
How would I detect this? Suppose I have a file at the root of my storage called teensy.ini And I want to know when this file changes? How? On many systems there might be a file change notify you might setup?
But other times, you might at start up time read the file and remember the Modify Date of the file. And then later if you see that date has changed? Then you know you may need to do something...

So then I wondered, does our high level FS.h file know anything about dates? I don't think so. Should it? Obviously Fat File systems support dates, but not sure of our Interface? I do see in some of the SDFat system there are apis to print the date, but not sure if there are any to retrieve it? LittleFS, does it support dates? I did not notice any. Is it worth doing anything? My guess (default answer) Punt.

Thoughts? Maybe main brain is just wondering too much :D

Edit: Note: I mention this in this thread, as to see if we should extend any of the new features before the official 1.54 is released with FS.h, LittleFS, Hopefully MTP...

Frank B
12-30-2020, 07:01 PM
+1
And I like to see a doc and some examples how all this new things work, including the new FS.h

defragster
12-30-2020, 09:50 PM
Try this:
...
Not sure if the optimization plays a role - I used "fast". You'll see >250 Cycles difference (60Mhz vs. 133Mhz) for these RANDOM reads ;)
Edit: it is a littly tricky to get around the cache AND the gcc optimization... therefore the funny loop.

Tried that and saw the change with the clock:

T:\tCode\Memory\FlashMemSpeed\FlashMemSpeed.ino Dec 30 2020 12:56:41
1416
u

T:\tCode\Memory\FlashMemSpeed\FlashMemSpeed.ino Dec 30 2020 13:00:54
1676
u

Then did this:

PROGMEM const char lorem[592] = "Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.";

volatile char x;

void setup() {
while (!Serial && millis() < 4000 );
Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
delay(10);

unsigned long t = ARM_DWT_CYCCNT;
for (int i = 0; i < 20; i += 1) x = lorem[591-(i * 8)];

t = ARM_DWT_CYCCNT - t;
Serial.println(t);
Serial.println(x);
}

void loop() {}

takes even longer but the ~250 offset is the same - though time in loop nearly doubles running backwards through FLASH string:

T:\tCode\Memory\FlashMemSpeed\FlashMemSpeed.ino Dec 30 2020 13:02:47
2986
m

T:\tCode\Memory\FlashMemSpeed\FlashMemSpeed.ino Dec 30 2020 13:03:11
2627
m

Then making the backward index '20' instead of 8 is more significant :: for (int i = 0; i < 20; i += 1) x = lorem[591-(i * 20)];

T:\tCode\Memory\FlashMemSpeed\FlashMemSpeed.ino Dec 30 2020 13:08:11
6026
32

T:\tCode\Memory\FlashMemSpeed\FlashMemSpeed.ino Dec 30 2020 13:08:35
6897
32

It hits a SPACE so printed (BYTE) to see it was indeed '32' {that changes with index [591- ...]}:: Serial.println((byte)x);

Good example : that does easily show diff in time that the faster Program Flash can make. Even if just a 250 cycle wait.

If the loop is changed to just "for (int i = 0; i < 2; i += 1)" the diff of 250 goes away ... down to 3 cycles.

Frank B
12-30-2020, 10:31 PM
If the loop is changed to just "for (int i = 0; i < 2; i += 1)" the diff of 250 goes away ... down to 3 cycles.
Yes, in this case the GCC optimization kicks in, removes the loop, and does not even read the array. It loads "x" with the corresponding values, directly - without reading them from the flash..

Frank B
12-31-2020, 10:20 AM
I've re-run coremark on the new GCC10.2.1 - still slower than GCC5.4.1 -O3 , and it crashes - even with "Blink"

:-(

"opt: faster" CoreMark 1.0 : 2313.57 / GCC5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496] (flags unknown) / STACK
"opt: faster" CoreMark 1.0 : 2431.32 / GCC9.3.1 20200408 (release) (flags unknown) / STACK
"opt: faster" CoreMark 1.0 : 2406.93 / GCC10.2.1 20201103 (release) (flags unknown) / STACK

"opt: fastest" CoreMark 1.0 : 2476.27 / GCC5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496] (flags unknown) / STACK
"opt: fastest" CoreMark 1.0 : 2398.46 / GCC9.3.1 20200408 (release) (flags unknown) / STACK
"opt: fastest" Crashes with GCC10.2.1 20201103

Edit: No, of course the flash-speed has NO influence - it runs in RAM, and even if it would run in flash: it fits into the cache.

I wonder what the GCC folks does... seems to ignore ARM-Cortex Mx somehow, regarding optimizations.. there is a constant regression since GCC 5 (with "-O3")

Edit: added the -O3 flags manually:
-O2 -fgcse-after-reload -fipa-cp-clone -floop-interchange -floop-unroll-and-jam -fpeel-loops -fpredictive-commoning -fsplit-loops -fsplit-paths -ftree-loop-distribution -ftree-loop-vectorize -ftree-partial-pre -ftree-slp-vectorize -funswitch-loops -fvect-cost-model -fvect-cost-model=dynamic -fversion-loops-for-strides

This does not crash (so, the documentation (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) is not complete) - but not worth to use it.., as it is slower than -O2 alone.

CoreMark 1.0 : 2382.09 / GCC10.2.1 20201103 (release) (flags unknown) / STACK

chipaudette
12-31-2020, 03:09 PM
Could you be more specific about which things don't work?

Echo'ing what WMXZ already said, my main issue is that emulated serial doesn't work outside of the Arduino Serial Monitor that is my biggest issue.

Additionally, I also have a problem caused by me having some custom classes holding a pointer to what is assumed to be that Serial connection. I know that I should be assuming that it is simply a "Stream", but I wanted to attempt to use some of the dtr() functionality that is enabled if I keep its type as "usb_serial_class". When I want to use this class along with MTP, the use of emulated serial breaks all of this (because usb_serial_class doesn't exist and is replaced instead with usb_seremu_class).

With some trickier programming on my part, I'm sure that I can make the usb_serial_class / usb_seremu_class problem go away. Therefore, it is only a secondary concern; my primary issue is that emulated serial doesn't work outside of the Arduino Serial Monitor.

Chip

Frank B
01-02-2021, 10:36 AM
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 B
01-11-2021, 03:37 PM
I found a racecondition with the _vector table.
It is not declared volatile, so if a interrupts occurs near writing a new vector to table, it calls the old interrupt.

I'll issue a PR.

KurtE
01-11-2021, 05:39 PM
@Paul @WMXZ @mjs513 @defragster... and all:

As has been mentioned up in the MTP thread, it would probably be a good thing, that when possible MTP would be able to tell the Host the dates and times for the files it is showing.

The MTP protocol does have the ability to give this information to the host in a standard format: YYYYMMDDThhmmsss.s
And does have the ability for the two values:
#define MTP_PROPERTY_DATE_CREATED 0xDC08
#define MTP_PROPERTY_DATE_MODIFIED 0xDC09
Which we are not doing.

But so far I don't see any way to do this currently with our current libraries:

Things like:

a) Does LittleFS have any concept of Date and Time? I have not seen it in my looking through the docs, but maybe it is some how encoded in the data?

b) SDFat - The fat file system does have date/time stamps that are set for the files. There is a callback function, that can be defined that defines the correct dates and times that is called when the file is created, modified...

But: so far the only methods to access these values are by some print methods, like: printModifyDateTime()
There is an issue up on the SDFat project: https://github.com/greiman/SdFat/issues/223
Where someone has raised the issue and provided code that they were doing and appears like there will be a solution:

And @greiman commented on this issue:

greiman commented on Nov 23, 2020 •

I will provide these functions in the next release:

bool getAccessDateTime( uint16_t * pdate, uint16_t * ptime );
bool getCreateDateTime( uint16_t * pdate, uint16_t * ptime );
bool getModifyDateTime( uint16_t * pdate, uint16_t * ptime );

FAT32/FAT16 only has access date so I will return zero for time.

c) Our new FS.h classes FS and FILE do not provide any way to get this information. So maybe we should add these to the FILE class and maybe try to add the implementation to SD class?
As for LittleFS if it has no idea of date/time return 0s...

Thoughts?

Frank B
01-11-2021, 08:03 PM
I've added a PR that adds printing hardfaults, temperature panic and unused interrupts.

It first does as soft reset to put the Teensy in a clean state, then prints the messages.
After 10 seconds, setup() and the rest of the program restarts.

Examples:

uint8_t *p = nullptr;
*p = 5;

prints:

Hardfault.
(DACCVIOL) Data Access Violation
(MMARVALID) Accessed Address: 0x0 (nullptr)

A Stackfault looks like this:

Hardfault.
(DACCVIOL) Data Access Violation
(MMARVALID) Accessed Address: 0x200032C8 (Stack problem)
Check for stack overflows, array bounds, etc.

All other hardfaults are printed, too.

For unused interrupts:

NVIC_ENABLE_IRQ(IRQ_Reserved5);
NVIC_STIR = IRQ_Reserved5;

it prints

Fault.
Unused ISR No. 128 called

In case of a temperature panic, it prints "Temperature Panic." and switches the Teensy off as before (without 10 secs wait)

With other IDEs, you can disable it (use SHOW_HARDFAULTS 0), or use an other Serial:

#ifndef SHOW_HARDFAULTS
#define SHOW_HARDFAULTS 1
#endif

#ifndef HARDFAULTSOUT
#define HARDFAULTSOUT Serial
#endif

Hint:
If you want hardfaults for division by zero, you can add this to your program:
SCB_CCR = 0x10; //Enable "Div By Zero" Hardfaults
(But I think this does not work for floats)

Frank B
01-13-2021, 10:25 AM
Paul, I have done PR for Teensy-LC / Audiolibrary. (https://forum.pjrc.com/threads/65735-Teensy-LC-audio-library-support?p=266499&viewfull=1#post266499)
Would you merge them?

mjs513
01-13-2021, 10:43 AM
I've added a PR that adds printing hardfaults, temperature panic and unused interrupts.

It first does as soft reset to put the Teensy in a clean state, then prints the messages.
After 10 seconds, setup() and the rest of the program restarts.

Examples:

uint8_t *p = nullptr;
*p = 5;

prints:

Hardfault.
(DACCVIOL) Data Access Violation
(MMARVALID) Accessed Address: 0x0 (nullptr)

A Stackfault looks like this:

Hardfault.
(DACCVIOL) Data Access Violation
(MMARVALID) Accessed Address: 0x200032C8 (Stack problem)
Check for stack overflows, array bounds, etc.

All other hardfaults are printed, too.

For unused interrupts:

NVIC_ENABLE_IRQ(IRQ_Reserved5);
NVIC_STIR = IRQ_Reserved5;

it prints

Fault.
Unused ISR No. 128 called

In case of a temperature panic, it prints "Temperature Panic." and switches the Teensy off as before (without 10 secs wait)

With other IDEs, you can disable it (use SHOW_HARDFAULTS 0), or use an other Serial:

#ifndef SHOW_HARDFAULTS
#define SHOW_HARDFAULTS 1
#endif

#ifndef HARDFAULTSOUT
#define HARDFAULTSOUT Serial
#endif

Hint:
If you want hardfaults for division by zero, you can add this to your program:
SCB_CCR = 0x10; //Enable "Div By Zero" Hardfaults
(But I think this does not work for floats)

Very cool Frank - thanks for adding Hardfaults was a nice feature

Frank B
01-13-2021, 01:39 PM
Very cool Frank - thanks for adding Hardfaults was a nice feature
No more silent passing away... (in most cases)

@Paul or others:
In WavFilePlayer we have patches like

#if defined(HAS_KINETIS_SDHC)

I think I(??) have added them a long time ago, to fix something..
I cant' remember what it was good for.. any Ideas? is it still needed?

Edit: Has anyone tested the WavFilePlayer with littleFs?
Edit: Has anyone tested the Teensy LC with littleFs?

mjs513
01-13-2021, 01:47 PM
No more silent passing away... (in most cases)

@Paul or others:
In WavFilePlayer we have patches like

#if defined(HAS_KINETIS_SDHC)

I think I(??) have added them a long time ago, to fix something..
I cant' remember what it was good for.. any Ideas? is it still needed?

Edit: Has anyone tested the WavFilePlayer with littleFs?
Edit: Has anyone tested the Teensy LC with littleFs?

At from me the answer is not to both - I do have a Teensy LC someplace but have to find what I did with it.

Frank B
01-13-2021, 02:36 PM
I found it. It was 2016:
https://github.com/PaulStoffregen/Audio/commit/0b27b37eb8a3ef60860424f5f14a3d146f2de739

As we now have more sources for files, and with the abstractions we need a better fix..
Edit: FS needs a addtion that says if SPI is used or not. bool usesSPI()

The WavFilePlayer has an other problem, at least on LC , too: Sometimes it consumes 2 blocks more than needed.
I couldn't find out why this happens.
You'll see it if you leave the WavFilePlayer example running, and add a print Serial.println(AudioMemoryUsageMax());
It is reproducable. When a new file starts, it jumps von 2 block to 4 blocks.
Sometimes it happens on the first start, too.
Edit: it is for a short time only. Print AudioMemoryUsageMax() always reports 2.

BOBILLIER
01-14-2021, 09:44 AM
Hi. Please, can you explain how we can uninstall Teensyduino 1.54 Beta #5 correctly? I have tried to delete all the Teensy folder in the Arduino folder, but when I try to re-install 1.53 version, I stay lock during the installation process in the chose folder and can't continue anymore. it-will be one good thing if you place this process on the Teensyduino web page.
Another thing, do you plan to add MSC support in Teensyduino like discuss in https://forum.pjrc.com/threads/55821-USBHost_t36-USB-Mass-Storage-Driver-Experiments?p=266492&viewfull=1#post266492?

KurtE
01-14-2021, 12:44 PM
Hi. Please, can you explain how we can uninstall Teensyduino 1.54 Beta #5 correctly? I have tried to delete all the Teensy folder in the Arduino folder, but when I try to re-install 1.53 version, I stay lock during the installation process in the chose folder and can't continue anymore. it-will be one good thing if you place this process on the Teensyduino web page.
Another thing, do you plan to add MSC support in Teensyduino like discuss in https://forum.pjrc.com/threads/55821-USBHost_t36-USB-Mass-Storage-Driver-Experiments?p=266492&viewfull=1#post266492?

As for best way to uininstall a version.

First I reboot to make sure I don't have any Arduino things opened up and running.

I will often just delete the arduino (actually I rename it to some other directory just in case). Then install fresh copy of Arduino. I don't typically install into the standard program files... So I actually have several different versions on my machine. Then I install which ever version of Teensyduino I wish to use.

Don't know what the issue you are running into that stay lock... But that is what I do when things get stuck.

Frank B
01-16-2021, 08:55 PM
I just saw that - if no DMA channel is available, Teensy just hardfaults.
If there was a intention to put the hardfault handling into the core, i'd try to add something like printing an errormessage for problems like this :)

defragster
01-16-2021, 09:47 PM
I just saw that - if no DMA channel is available, Teensy just hardfaults.
If there was a intention to put the hardfault handling into the core, i'd try to add something like printing an errormessage for problems like this :)

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.

mjs513
01-16-2021, 09:55 PM
No more silent passing away... (in most cases)

@Paul or others:
In WavFilePlayer we have patches like

#if defined(HAS_KINETIS_SDHC)

I think I(??) have added them a long time ago, to fix something..
I cant' remember what it was good for.. any Ideas? is it still needed?

Edit: Has anyone tested the WavFilePlayer with littleFs?
Edit: Has anyone tested the Teensy LC with littleFs?

Well I started playing with the wavFilePlayer code but run into a problem how to handle pointing the to constructor for each type of FLASH (QSPI, SPI, FRAM) in the play_sd_xxx files in the audio library.

Right how SD has:

extern SDClass SD; and so you don't have to go digging:

class SDClass : public FS
{
public:
SDClass() { }
bool begin(uint8_t csPin = 10) {
#ifdef BUILTIN_SDCARD
if (csPin == BUILTIN_SDCARD) {
return sdfs.begin(SdioConfig(FIFO_SDIO));
//return sdfs.begin(SdioConfig(DMA_SDIO));
}
#endif
return sdfs.begin(SdSpiConfig(csPin, SHARED_SPI, SD_SCK_MHZ(16)));
//return sdfs.begin(csPin, SD_SCK_MHZ(24));
}
File open(const char *filepath, uint8_t mode = FILE_READ) {
oflag_t flags = O_READ;
if (mode == FILE_WRITE) flags = O_RDWR | O_CREAT | O_AT_END;
else if (mode == FILE_WRITE_BEGIN) flags = O_RDWR | O_CREAT;
SDFAT_FILE file = sdfs.open(filepath, flags);
if (file) return File(new SDFile(file));
return File();
}
bool exists(const char *filepath) {
return sdfs.exists(filepath);
}
bool mkdir(const char *filepath) {
return sdfs.mkdir(filepath);
}
bool rename(const char *oldfilepath, const char *newfilepath) {
return sdfs.rename(oldfilepath, newfilepath);
}
bool remove(const char *filepath) {
return sdfs.remove(filepath);
}
bool rmdir(const char *filepath) {
return sdfs.rmdir(filepath);
}
uint64_t usedSize() {
return (uint64_t)(sdfs.clusterCount() - sdfs.freeClusterCount())
* (uint64_t)sdfs.bytesPerCluster();
}
uint64_t totalSize() {
return (uint64_t)sdfs.clusterCount() * (uint64_t)sdfs.bytesPerCluster();
}
public: // allow access, so users can mix SD & SdFat APIs
SDFAT_BASE sdfs;
};

extern SDClass SD; In littleFS we have something similar:

class LittleFS : public FS
{
public:
LittleFS() {
configured = false;
mounted = false;
config.context = nullptr;
}
bool quickFormat();
bool lowLevelFormat(char progressChar=0);
uint32_t formatUnused(uint32_t blockCnt, uint32_t blockStart);
File open(const char *filepath, uint8_t mode = FILE_READ) {
//Serial.println("LittleFS open");
if (!mounted) return File();
if (mode == FILE_READ) {
struct lfs_info info;
if (lfs_stat(&lfs, filepath, &info) < 0) return File();
//Serial.printf("LittleFS open got info, name=%s\n", info.name);
if (info.type == LFS_TYPE_REG) {
//Serial.println(" regular file");
lfs_file_t *file = (lfs_file_t *)malloc(sizeof(lfs_file_t));
if (!file) return File();
if (lfs_file_open(&lfs, file, filepath, LFS_O_RDONLY) >= 0) {
return File(new LittleFSFile(&lfs, file, filepath));
}
free(file);
} else { // LFS_TYPE_DIR
//Serial.println(" directory");
lfs_dir_t *dir = (lfs_dir_t *)malloc(sizeof(lfs_dir_t));
if (!dir) return File();
if (lfs_dir_open(&lfs, dir, filepath) >= 0) {
return File(new LittleFSFile(&lfs, dir, filepath));
}
free(dir);
}
} else {
lfs_file_t *file = (lfs_file_t *)malloc(sizeof(lfs_file_t));
if (!file) return File();
if (lfs_file_open(&lfs, file, filepath, LFS_O_RDWR | LFS_O_CREAT) >= 0) {
if (mode == FILE_WRITE) {
// FILE_WRITE opens at end of file
lfs_file_seek(&lfs, file, 0, LFS_SEEK_END);
} // else FILE_WRITE_BEGIN
return File(new LittleFSFile(&lfs, file, filepath));
}
}
return File();
}
bool exists(const char *filepath) {
if (!mounted) return false;
struct lfs_info info;
if (lfs_stat(&lfs, filepath, &info) < 0) return false;
return true;
}
bool mkdir(const char *filepath) {
if (!mounted) return false;
if (lfs_mkdir(&lfs, filepath) < 0) return false;
return true;
}
bool rename(const char *oldfilepath, const char *newfilepath) {
if (!mounted) return false;
if (lfs_rename(&lfs, oldfilepath, newfilepath) < 0) return false;
return true;
}
bool remove(const char *filepath) {
if (!mounted) return false;
if (lfs_remove(&lfs, filepath) < 0) return false;
return true;
}
bool rmdir(const char *filepath) {
return remove(filepath);
}
uint64_t usedSize() {
if (!mounted) return 0;
int blocks = lfs_fs_size(&lfs);
if (blocks < 0 || (lfs_size_t)blocks > config.block_count) return totalSize();
return blocks * config.block_size;
}
uint64_t totalSize() {
if (!mounted) return 0;
return config.block_count * config.block_size;
}
protected:
bool configured;
bool mounted;
lfs_t lfs;
lfs_config config;
}; Just adding a extern LittleFS FLASH does not work since we have to do this for each type of FLASH:

LittleFS_SPIFlash FLASH; All that is in the play_sd_xxx files are SD.open(filename)?????

So anyone with how to do this would be appreciated :)

Frank B
01-16-2021, 10:16 PM
Hm i did not read about that, but I thought FS.h was a wrapper for all kinds of FS?
I guess it just needs an info which FS is used.

But I have _no_ knowlage about all this stuff. I wait for someone who writes a "Howto" ;) I don't think this all will be builtin without any information for the users ;)

I was hoping that it is transparent, and old software would be able to use all this automagically.
If not, we have to rewrite a lot of old stuff... ?

Frank B
01-16-2021, 10:26 PM
I guess we need Windows-like drive-letters or devices..or canonical paths... ?

Like "//littlefs/flash0/MyFantasticFile.txt"

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

Edit: With "SD" as default - "Builtin" for teensies with SD Socket, SPI for others..

PaulStoffregen
01-16-2021, 10:38 PM
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
01-16-2021, 10:55 PM
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
01-16-2021, 11:02 PM
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
01-16-2021, 11:17 PM
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
01-16-2021, 11:41 PM
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
01-17-2021, 12:32 AM
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
01-17-2021, 09:37 AM
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
01-17-2021, 11:19 AM
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
01-17-2021, 04:14 PM
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
01-18-2021, 07:44 AM
@Paul,

Frank B
01-22-2021, 02:42 PM
Hi Paul

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

noisymime
01-24-2021, 10:43 PM
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_T4/commit/2b47dd0f6b0291a6d872eaac85304e3c1e65ed57#diff-71c20e2e1d7fa1b20d6b575e4bf8e5e8f2b62aa8dbc3be34dd 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
01-25-2021, 10:34 PM
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
01-25-2021, 10:36 PM
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
01-26-2021, 07:44 PM
5V is not good..

Deleted User
01-28-2021, 12:13 AM
'SNVS_LPGPR0' was not declared in this scope

Deleted User
01-28-2021, 02:03 AM
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
01-28-2021, 02:00 PM
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_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
01-28-2021, 03:57 PM
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
01-28-2021, 04:19 PM
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-Teensy-4-0-code-security

chipaudette
01-28-2021, 04:24 PM
>>> 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
01-28-2021, 04:38 PM
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
01-28-2021, 04:46 PM
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
01-28-2021, 04:56 PM
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
01-28-2021, 05:07 PM
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 (https://forum.pjrc.com/threads/57173...-code-security). Don't think security features are turned on as of yet. I know its on the list of things to get done.

Deleted User
01-28-2021, 05:34 PM
Yes, there need to be certain registers set to allow writing. NDA... But this is not the point.
During reboot the tinker-protection seems to be triggered and the LPGPRs are zeroed. Anyway, I see no possibility to set the GPR_Z_DIS and keep that up for the next power-up, because it always becomes unset at boot.

I am stopping my trials here, because of that. The flash has already a lot of burns on it and the next Teensy 4.1's are on the snail.

It would be super cool to implement a function call to handle all the steps and offer the user an easy way to read and write, without having to deal with SNVS.

KurtE
01-28-2021, 06:08 PM
Asi I mentioned in I believe post #193, if you look at the SNVS_HP register at the NPSWA_EN - mentions

When set, allows non-privileged software to access all SNVS registers, including those that are privileged
software read/write access only.

That would probably be the first one I would try to see what it is set to and if not set can I set it.

Then again probably all of our code runs as privileged?

Don't know if other registers involved? like some CCM? Did not find one.

Frank B
01-28-2021, 06:20 PM
@Deleted User, please open a new thread.

This has nothing to do with a new Teensyduino release.

And please post some sourcecode there that we can copy&paste. That bit worked for me, a year ago.

defragster
01-28-2021, 06:46 PM
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.

There are 16 bytes of USABLE RTC backed NVRAM on the 1062 in T_4.1 and T_4.0.

Just started this THREAD :: Teensy-4-x-s-1062-MCU-has-16-bytes-of-NVRAM-on-RTC-unit (https://forum.pjrc.com/threads/66076-Teensy-4-x-s-1062-MCU-has-16-bytes-of-NVRAM-on-RTC-unit)

It takes a majik undocumented bit change Frank_B found.

That post shows code already - going back to add notes.

This code is from prior code posted on forum months back.

KurtE
01-28-2021, 06:51 PM
@Frank B and Deleted User. So far I have tried simple stuff... Not working:

#define SNVS_LPGPR0 (IMXRT_SNVS.offset100)
#define SNVS_LPGPR1 (IMXRT_SNVS.offset104)
#define SNVS_LPGPR2 (IMXRT_SNVS.offset108)
#define SNVS_LPGPR3 (IMXRT_SNVS.offset10C)

void setup() {
while (!Serial);
Serial.begin(115200);
Serial.println("At startup");
SNVS_HPCOMR |= 0x80000000l;
Serial.printf("%x %x %x %x\n", SNVS_LPGPR0, SNVS_LPGPR1, SNVS_LPGPR2,
SNVS_LPGPR3);
delay(100);
SNVS_LPGPR0 += 1;
SNVS_LPGPR1 += 2;
SNVS_LPGPR2 += 3;
SNVS_LPGPR3 += 4;
Serial.println("After settting");
Serial.printf("%x %x %x %x\n", SNVS_LPGPR0, SNVS_LPGPR1, SNVS_LPGPR2,
SNVS_LPGPR3);
SNVS_LPGPR = 100;
Serial.printf("%x\n", SNVS_LPGPR);
}
void loop() {

}

And everything prints out as 0s...

And I agree should go to new thread

----> Going to new thread

KurtE
01-29-2021, 06:47 PM
@Paul - I just did a sync of the cores project and my simple test program no longer compiles for T4...

"C:\\arduino-1.8.13\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=154 -DARDUINO=10813 -DARDUINO_TEENSY40 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\arduino-1.8.13\\hardware\\teensy\\avr\\cores\\teensy4" "C:\\arduino-1.8.13\\hardware\\teensy\\avr\\cores\\teensy4\\boo tdata.c" -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_697394\\core\\bootdata.c.o"
"C:\\arduino-1.8.13\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=154 -DARDUINO=10813 -DARDUINO_TEENSY40 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\arduino-1.8.13\\hardware\\teensy\\avr\\cores\\teensy4" "C:\\arduino-1.8.13\\hardware\\teensy\\avr\\cores\\teensy4\\dig ital.c" -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_697394\\core\\digital.c.o"
In file included from C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\analog.c: 1:0:
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\analog.c: In function 'analog_init':
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 338:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CCGR1 (IMXRT_CCM.offset06C)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\analog.c: 171:2: note: in expansion of macro 'CCM_CCGR1'
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 338:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CCGR1 (IMXRT_CCM.offset06C)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\analog.c: 172:2: note: in expansion of macro 'CCM_CCGR1'
^
"C:\\arduino-1.8.13\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=154 -DARDUINO=10813 -DARDUINO_TEENSY40 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\arduino-1.8.13\\hardware\\teensy\\avr\\cores\\teensy4" "C:\\arduino-1.8.13\\hardware\\teensy\\avr\\cores\\teensy4\\int errupt.c" -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_697394\\core\\interrupt.c.o"
In file included from C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:2:0:
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c: In function 'set_arm_clock':
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 321:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CBCDR (IMXRT_CCM.offset014)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:32:19: note: in expansion of macro 'CCM_CBCDR'
uint32_t cbcdr = CCM_CBCDR; // pg 1021
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 322:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CBCMR (IMXRT_CCM.offset018)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:33:19: note: in expansion of macro 'CCM_CBCMR'
uint32_t cbcmr = CCM_CBCMR; // pg 1023
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 343:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CCGR6 (IMXRT_CCM.offset080)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:51:2: note: in expansion of macro 'CCM_CCGR6'
CCM_CCGR6 |= CCM_CCGR6_DCDC(CCM_CCGR_ON);
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 321:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CBCDR (IMXRT_CCM.offset014)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:78:4: note: in expansion of macro 'CCM_CBCDR'
CCM_CBCDR = cbcdr;
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 322:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CBCMR (IMXRT_CCM.offset018)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:84:4: note: in expansion of macro 'CCM_CBCMR'
CCM_CBCMR = cbcmr;
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 331:23: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CDHIPR (IMXRT_CCM.offset048)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:85:11: note: in expansion of macro 'CCM_CDHIPR'
while (CCM_CDHIPR & CCM_CDHIPR_PERIPH2_CLK_SEL_BUSY) ; // wait
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 321:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CBCDR (IMXRT_CCM.offset014)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:89:3: note: in expansion of macro 'CCM_CBCDR'
CCM_CBCDR = cbcdr;
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 331:23: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CDHIPR (IMXRT_CCM.offset048)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:90:10: note: in expansion of macro 'CCM_CDHIPR'
while (CCM_CDHIPR & CCM_CDHIPR_PERIPH_CLK_SEL_BUSY) ; // wait
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 320:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CACRR (IMXRT_CCM.offset010)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:135:7: note: in expansion of macro 'CCM_CACRR'
if ((CCM_CACRR & CCM_CACRR_ARM_PODF_MASK) != (div_arm - 1)) {
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 320:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CACRR (IMXRT_CCM.offset010)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:136:3: note: in expansion of macro 'CCM_CACRR'
CCM_CACRR = CCM_CACRR_ARM_PODF(div_arm - 1);
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 331:23: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CDHIPR (IMXRT_CCM.offset048)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:137:10: note: in expansion of macro 'CCM_CDHIPR'
while (CCM_CDHIPR & CCM_CDHIPR_ARM_PODF_BUSY) ; // wait
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 321:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CBCDR (IMXRT_CCM.offset014)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:143:3: note: in expansion of macro 'CCM_CBCDR'
CCM_CBCDR = cbcdr;
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 331:23: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CDHIPR (IMXRT_CCM.offset048)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:144:10: note: in expansion of macro 'CCM_CDHIPR'
while (CCM_CDHIPR & CCM_CDHIPR_AHB_PODF_BUSY); // wait
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 321:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CBCDR (IMXRT_CCM.offset014)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:153:3: note: in expansion of macro 'CCM_CBCDR'
CCM_CBCDR = cbcdr;
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 321:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CBCDR (IMXRT_CCM.offset014)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:158:2: note: in expansion of macro 'CCM_CBCDR'
CCM_CBCDR &= ~CCM_CBCDR_PERIPH_CLK_SEL;
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 331:23: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CDHIPR (IMXRT_CCM.offset048)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\clockspee d.c:159:9: note: in expansion of macro 'CCM_CDHIPR'
while (CCM_CDHIPR & CCM_CDHIPR_PERIPH_CLK_SEL_BUSY) ; // wait
^
Error compiling for board Teensy 4.0.

My guess is it has to do with your reorganizing the order of these defines?

Again nothing special in sketch other than to check the stuff you merged in for the LPGPR registers.

#ifndef SNVS_LPGPR0
#define SNVS_LPGPR0 (IMXRT_SNVS.offset100)
#define SNVS_LPGPR1 (IMXRT_SNVS.offset104)
#define SNVS_LPGPR2 (IMXRT_SNVS.offset108)
#define SNVS_LPGPR3 (IMXRT_SNVS.offset10C)
#endif
void setup() {
while (!Serial);
Serial.begin(115200);
Serial.println("At startup");
// SNVS_HPCOMR |= SNVS_LPCR_GPR_Z_DIS; //0x80000000l;
Serial.printf("%x %x %x %x\n", SNVS_LPGPR0, SNVS_LPGPR1, SNVS_LPGPR2,
SNVS_LPGPR3);
delay(100);
SNVS_LPCR |= (1 << 24);
SNVS_LPGPR0 += 1;
SNVS_LPGPR1 += 2;
SNVS_LPGPR2 += 3;
SNVS_LPGPR3 += 4;
Serial.println("After settting");
Serial.printf("%x %x %x %x\n", SNVS_LPGPR0, SNVS_LPGPR1, SNVS_LPGPR2,
SNVS_LPGPR3);
// SNVS_LPGPR = 100;
// Serial.printf("%x\n", SNVS_LPGPR);
}
void loop() {

}

KurtE
01-29-2021, 06:55 PM
@Paul - I just did a sync of the cores project and my simple test program no longer compiles for T4...

"C:\\arduino-1.8.13\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=154 -DARDUINO=10813 -DARDUINO_TEENSY40 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\arduino-1.8.13\\hardware\\teensy\\avr\\cores\\teensy4" "C:\\arduino-1.8.13\\hardware\\teensy\\avr\\cores\\teensy4\\boo tdata.c" -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_697394\\core\\bootdata.c.o"
"C:\\arduino-1.8.13\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-gcc" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=154 -DARDUINO=10813 -DARDUINO_TEENSY40 -DF_CPU=600000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IC:\\arduino-1.8.13\\hardware\\teensy\\avr\\cores\\teensy4" "C:\\arduino-1.8.13\\hardware\\teensy\\avr\\cores\\teensy4\\dig ital.c" -o "C:\\Users\\kurte\\AppData\\Local\\Temp\\arduino_bu ild_697394\\core\\digital.c.o"
In file included from C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\analog.c: 1:0:
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\analog.c: In function 'analog_init':
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 338:22: note: in expansion of macro 'IMXRT_CCM'
#define CCM_CCGR1 (IMXRT_CCM.offset06C)
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\analog.c: 171:2: note: in expansion of macro 'CCM_CCGR1'
^
C:\arduino-1.8.13\hardware\teensy\avr\cores\teensy4\imxrt.h:1 316:44: error: expected expression before ')' token
#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
...

Found - one liner 1316

-#define IMXRT_CCM (*(IMXRT_REGISTER32_t *))IMXRT_CCM_ADDRESS
+#define IMXRT_CCM (*(IMXRT_REGISTER32_t *)IMXRT_CCM_ADDRESS)

Could PR, although probably quicker for you to move the )...

Did PR: in case that makes it easier... https://github.com/PaulStoffregen/cores/pull/538