Teensyduino 1.54 Beta #7

Status
Not open for further replies.
Paul, is the FlexSPI2 Flash still memory mapped? (Which Address?)
I ask because of MPU. I'm still trying to find the best setting.
 
MPU:
To answer my question, there is no other allowed setting that does not lead to the 1.7 second freezes.
Trying more than 16M results in freezes, *any* other addition within the 0x7 range leads to freezes, regardless of the order - before or after - With the subregion bits set or not. So, the last patch for the MPU is the only allowed config. I've tried them all, I think.
I tried to enable the background region, tried to remove other questionable settings - all does not help.

A minor problem. But perhaps this message helps to save time for others who play with the MPU and the 0x7 region. I'll stop that now, as we have a working config.

For this, I don't need to know if there is flash memorymapping or not.
 
Last edited:
Frank B said:
Paul, is the FlexSPI2 Flash still memory mapped? (Which Address?)
Click to expand...

Today we should only be using FlexSPI2 memory mapping in the range of 70000000 to 70FFFFFF for PSRAM.

LittleFS uses the IP commands to access flash.

@Kurt, Defragster, mjs513 - Is anyone still using the early code which accessed flash chips as memory 71000000 to 7FFFFFFF?
 
I guess this means LittleFS is not cached (by hardware) and thus slower than the program(0x6....) flash.
(And, in this case, the current MPU settings are OK)
Good to know :)
Does LittleFS have it's own caching system? How much memory is used for it?
 
Shall we try to run it memory mapped?
I think its adress should be 0x78.. then. 128MB max size. Perhaps we can use an additonal MPU setting once the memory-mapping is enabled? (The more i try with the MPU the more incomprehensible is it to me. Something is wrong there... )

It would be a small and shared cache for free, and I think the cache does read-ahead for a cache line? That would be a valuable plus.

Edit: I also don't understand why she's only bitchy in the 7x... range. And even if you don't access this range.. mysterious.
 
Last edited:
Hello everyone,
I'm new to this forum and want to say Hello and thanks for the nice device (T 4.1).
I'm working on an application which is sending sensor data to Azure Storage Tables with TLS secured transmission which is now running fine but I had some issues to overcome.
1) To use TLS the NativeEthernet and FNET library had to be substituted by the latest versions of the master branch of the repositories:
-https://github.com/vjmuzik/NativeEthernet
-https://github.com/vjmuzik/FNET

2) Instead of using the TLS implementation of NativeEthernet library I used the the bear ssl implementation of:
https://github.com/khoih-prog/EthernetWebServer_SSL
which worked fine, but needed a little patch for the cores/teensy4/Stream.h file as explained here:
-https://github.com/khoih-prog/EthernetWebServer_SSL/tree/main/Packages_Patches/hardware/teensy/avr/cores/teensy4

It seems that these improvements are not yet included in beta7.
I would be happy if this could be done in the final version.
Kind regards
RoSchmi
 
Frank B said:
...
Does LittleFS have it's own caching system? How much memory is used for it?
Click to expand...

There is some small cache per media entry - it seems to be a bitmap for where the next free block might be. That could be improved as it seems not updated dynamically - but filled for use - and not expected to cover all the disk's blocks as it is in a provided buffer of given size that may be too small for 4K or 32K blocks.

When it comes to storage - directories and files - it is in place across the blocks - not centralized. Doing a directory walk can take 2 or many more seconds (logn times noted in thread) as it has to read "link to link" as provided by the disk data. Then it is read once as needed and ignored.

Not seeing a 32KB cache block having much use as there is no central storage of cluster or dir data - it is all distributed in a fault tolerant way with the design idea to be efficient without having memory overhead.
 
RoSchmi said:
Hello everyone,
I'm new to this forum and want to say Hello and thanks for the nice device (T 4.1).
I'm working on an application which is sending sensor data to Azure Storage Tables with TLS secured transmission which is now running fine but I had some issues to overcome.
1) To use TLS the NativeEthernet and FNET library had to be substituted by the latest versions of the master branch of the repositories:
-https://github.com/vjmuzik/NativeEthernet
-https://github.com/vjmuzik/FNET

2) Instead of using the TLS implementation of NativeEthernet library I used the the bear ssl implementation of:
https://github.com/khoih-prog/EthernetWebServer_SSL
which worked fine, but needed a little patch for the cores/teensy4/Stream.h file as explained here:
-https://github.com/khoih-prog/EthernetWebServer_SSL/tree/main/Packages_Patches/hardware/teensy/avr/cores/teensy4

It seems that these improvements are not yet included in beta7.
I would be happy if this could be done in the final version.
Kind regards
RoSchmi
Click to expand...

Apologies, after a closer look it seems that the needed changes named under 1) are already included in beta 7
 
@Defragster, the prefetches would be useful. I learned now, that there is no automatic prefetch, but I think it prefetches at least the rest of a cache-line.
Remember, accessing a memory location over SPI takes a really long time. Even more if the interface has to tell the chip the address first.
 
The SD library works on my T3.5 but has a serious latency problem so I would like to try sdFAT. This hasn't really worked at all. I was advised to try Teensyduino 1.54 beta 7. This shows some improvement but still doesn't work.

For the moment I am trying to just get the Bench example working, then simply creating a file and writing to it. The Bench example will compile and run if the chipSelect is changed to BUILTIN_SDCARD and the following line is commented out:
// cout << F("Card size: ") << sd.card()->cardSize()*512E-9;

The resulting run, however, is unable to access the card with the following result:

Code: 
Use a freshly formatted SD for best performance.

Type any character to start
chipSelect: 254
FreeStack: 255464
begin() failed
Do not reformat the SD.
No card, wrong chip select pin, or wiring error?
SdError: 0X1,0X0
 
choochoo22 said:
The SD library works on my T3.5 but has a serious latency problem so I would like to try sdFAT. This hasn't really worked at all. I was advised to try Teensyduino 1.54 beta 7. This shows some improvement but still doesn't work.

For the moment I am trying to just get the Bench example working, then simply creating a file and writing to it. The Bench example will compile and run if the chipSelect is changed to BUILTIN_SDCARD and the following line is commented out:
// cout << F("Card size: ") << sd.card()->cardSize()*512E-9;

The resulting run, however, is unable to access the card with the following result:
...
Click to expand...

That example is in the SdFat folder: ...\hardware\teensy\avr\libraries\SdFat\examples\bench\bench.ino

As noted the features and functions of SD.h have been mapped to use the SdFat code as replacements.

There are sample and code in the SdFat examples like that one that directly use the SdFat rules and expectations and won't mix with SD.H usage. Those samples should work in general - but use the requirements of that code base which IIRC does not use BUILTIN_SDCARD the same way.

To upgrade SD.h just use the same code as before with the newer TeensyDuino 1.54 Beta. Going into SdFat\examples uses that and its rules directly - and not SD.h compatible.
 
Frank B said:
@Defragster, the prefetches would be useful. I learned now, that there is no automatic prefetch, but I think it prefetches at least the rest of a cache-line.
Remember, accessing a memory location over SPI takes a really long time. Even more if the interface has to tell the chip the address first.
Click to expand...

I suppose no doubt it could help pre-reading and then not needing wait time for sequential addressing requests. Notes were based on the likely hood it would purge and fill the cache with read once data, voiding the data cache for any other effective usage.

If enabled the LFSIntegrity code might show a difference in some timed operations where the read ahead could help - perhaps doing the DIR Listings or file count verify where it walks the dir tree. It might also cause a wait for requested data while it busies the processor reading beyond the point of interest when the next read is requested?
 
OK, so, gave up on using sdFat as even the examples don't work. Going back to SD and try the newer Teensyduino as below:

defragster said:
...To upgrade SD.h just use the same code as before with the newer TeensyDuino 1.54 Beta....
Click to expand...

Now the application that was working fine before is broken:

Code: 
Arduino: 1.8.13 (Windows 10), TD: 1.54-beta7, Board: "Teensy 3.5, Serial, 120 MHz, Faster, US English"





















C:\Users\Rick\AppData\Local\Temp\arduino_build_365721\sketch\RX_Snoop_V2-1.ino.cpp.o: In function `File::whoami()':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3/FS.h:84: undefined reference to `Serial'

C:\Users\Rick\AppData\Local\Temp\arduino_build_365721\sketch\RX_Snoop_V2-1.ino.cpp.o: In function `SDFile::whoami()':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SD\src/SD.h:71: undefined reference to `Serial'

C:\Users\Rick\AppData\Local\Temp\arduino_build_365721\sketch\RX_Snoop_V2-1.ino.cpp.o: In function `loop':

C:\Users\Rick\Documents\Arduino\RX_Snoop_V2-1/RX_Snoop_V2-1.ino:301: undefined reference to `Serial'

C:\Users\Rick\AppData\Local\Temp\arduino_build_365721\sketch\RX_Snoop_V2-1.ino.cpp.o: In function `setup':

C:\Users\Rick\Documents\Arduino\RX_Snoop_V2-1/RX_Snoop_V2-1.ino:227: undefined reference to `Serial'

C:\Users\Rick\AppData\Local\Temp\arduino_build_365721\libraries\SdFat\SdCard\SdioTeensy.cpp.o: In function `SysCall::yield()':

c:\users\rick\documents\arduino\libraries\sdfat\src\common/syscall.h:90: undefined reference to `yield'

C:\Users\Rick\AppData\Local\Temp\arduino_build_365721/..\arduino_cache_248229\core\core_576b67285ecb01e18963173d351aed2d.a(analog.c.o): In function `analogRead':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3/analog.c:484: undefined reference to `yield'

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3/analog.c:515: undefined reference to `yield'

C:\Users\Rick\AppData\Local\Temp\arduino_build_365721/..\arduino_cache_248229\core\core_576b67285ecb01e18963173d351aed2d.a(pins_teensy.c.o): In function `delay':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3/pins_teensy.c:1228: undefined reference to `yield'

C:\Users\Rick\AppData\Local\Temp\arduino_build_365721/..\arduino_cache_248229\core\core_576b67285ecb01e18963173d351aed2d.a(usb_serial.c.o): In function `usb_serial_write':

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3/usb_serial.c:218: undefined reference to `yield'

C:\Users\Rick\AppData\Local\Temp\arduino_build_365721/..\arduino_cache_248229\core\core_576b67285ecb01e18963173d351aed2d.a(main.cpp.o):C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3/main.cpp:54: more undefined references to `yield' follow

collect2.exe: error: ld returned 1 exit status

Multiple libraries were found for "SD.h"

 Used: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SD

 Not used: C:\Program Files (x86)\Arduino\libraries\SD

Multiple libraries were found for "SdFat.h"

 Used: C:\Users\Rick\Documents\Arduino\libraries\SdFat

 Not used: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SdFat

 Not used: C:\Users\Rick\Documents\Arduino\libraries\arduino_47876

Error compiling for board Teensy 3.5.



This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

So trying to go back to something that was working. Not sure of the prior Teensyduino version but the only current install option seems to be 1.53. Unfortunately that won't install. It keeps asking for where to install it and no choices seem to be acceptable. The "Next" button is greyed no matter what directory is selected.

Teensyduino install.jpg

To get back to something that works, do I need to uninstall everything and start over?
 
@choochoo22 - installing older versions over newer isn't expected to work. Newer versions know what changed and can accommodate - older versions don't know what newer versions have added/changed.

Best would be to work through issues with SD.H using the SdFat as found in TD 1.54 b7. There may be unfound issues and they need to get resolved before

One thing is that this should be removed because the desired version is installed with beta 7:: Used: C:\Users\Rick\Documents\Arduino\libraries\SdFat

Seeing only the errors doesn't offer much chance to help - though it seems there are fundamental issues in the build and install as Fresh Arduino IDE and TD 1.54b7 would provide - many of those errors seem to be unrelated to anything that the change for SD to use SdFat.
> yield should have no issues
> Serial should have no issues

It may help to do a clean install of IDE 1.8.13 and then TeensyDuino 1.54 b7 if such odd errors aren;t resolved using the correct libraries.
 
defragster said:
...It may help to do a clean install of IDE 1.8.13 and then TeensyDuino 1.54 b7 if such odd errors aren;t resolved using the correct libraries.
Click to expand...
Thanks. I reinstalled IDE and Teensyduino 1.53 and things went back to where they were, the sketch works but with an occasional SD write latency problem.
 
In case an upgrade to a newer toolchain is still considered here an observation which might help debugging:

This

Code: 
#include "Arduino.h"
#include <string>

void setup()
{
    std::string zahlString = std::to_string(42);
}

void loop()
{ 
}

compiles without problems with GCC 9.3 and TD 1.53, but generates the following error with the current core files

Code: 
c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(string-inst.o):(.ARM.exidx.text._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERjj[_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERjj]+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERjj'
c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_catch.o):(.ARM.extab.text.__cxa_begin_catch+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_catch.o):(.ARM.exidx.text.__cxa_begin_catch+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text.__cxa_begin_catch'
c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o):(.ARM.exidx.text._ZL21base_of_encoded_valuehP15_Unwind_Context+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZL21base_of_encoded_valuehP15_Unwind_Context'
c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o):(.ARM.extab.text.__gxx_personality_v0+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o):(.ARM.exidx.text.__gxx_personality_v0+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text.__gxx_personality_v0'
c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_terminate.o):(.ARM.extab.text._ZN10__cxxabiv111__terminateEPFvvE+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_terminate.o):(.ARM.exidx.text._ZN10__cxxabiv111__terminateEPFvvE+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZN10__cxxabiv111__terminateEPFvvE'
c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_terminate.o):(.ARM.exidx.text._ZN10__cxxabiv112__unexpectedEPFvvE+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZN10__cxxabiv112__unexpectedEPFvvE'
c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_terminate.o):(.ARM.exidx.text._ZSt10unexpectedv+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZSt10unexpectedv'
c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(vterminate.o):(.ARM.extab.text._ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x0): additional relocation overflows omitted from the output
collect2.exe: error: ld returned 1 exit status

Looks like it was introduced with commit "dc56788 Changes to support HAB (thanks dresden-fx)" from 2020-10-18 see https://github.com/PaulStoffregen/cores/commit/dc567880488dc53ba2e71eb07e04356bda7e2a7e
 
Is there a notional schedule for releasing 1.54? It's been brewing since October...

The switch to the Greiman SD is such a game changer. It's so much better than the kludge that I (and my users) have been living with. Because it's so much better/cleaner, I quickly updated my libraries to use the new SD implementation in these beta Teensyduino(s). But, I've been holding off releasing my updated libraries until 1.54 comes out of beta. Is there a vision for when 1.54 might be released?

If it's still going to be months-and-months, I'll have to go and re-insert my kludged SD code so that I can release other unrelated updates. Ick.

Chip
 
Status
Not open for further replies.
Back
Top