Teensyduino 1.59 Beta #2
- Thread starter Paul
- Start date
PaulStoffregen
Well-known member
Looks like PlatformIO is still using the old compiler options for 1.58.
sbfreddie
Well-known member
Luni:
Yes this is PIO on Mac. Here is my platformio.ini file:
I followed the instructions from your post to use the latest beta, using the Teensyduino.app from the beta2 test build. Perhaps I missed an important step?
Thanks,
Ed
Yes this is PIO on Mac. Here is my platformio.ini file:
Code:
; PlatformIO Project Configuration File
;
; Build options: build flags, source filter
; Upload options: custom upload port, speed and extra flags
; Library options: dependencies, extra library storages
; Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; https://docs.platformio.org/page/projectconf.html
;[env:stable]
;platform = https://github.com/platformio/platform-teensy.git
;
;board = teensy41
;
;framework = arduino
;
[env:teensy41]
platform = teensy
board = teensy41
framework = arduino
;
platform_packages =
toolchain-gccarmnoneeabi@file:///Users/freddie/pio/teensy_1.59-beta2/toolchain-gccarmnoneeabi
framework-arduinoteensy@file:///Users/freddie/pio/teensy_1.59-beta2/framework-arduinoteensy
tool-teensy@file:///Users/freddie/pio/teensy_1.59-beta2/tool-teensy
;platform_packages =
;toolchain-gccarmnoneeabi@file:///Users/freddie/pio/teensy_1.58-beta3/toolchain-gccarmnoneeabi
;framework-arduinoteensy@file:///Users/freddie/pio/teensy_1.58-beta3/framework-arduinoteensy
;tool-teensy@file:///Users/freddie/pio/teensy_1.58-beta3/tool-teensy
;
;
build_flags =
-Wl,--print-memory-usage
-g
-D USB_MTPDISK_SERIAL
;build_type = release
;
#lib_extra_dirs = ~/Documents/Arduino/libraries
;
check_tool = cppcheck
check_flags = --enable=all
extra_scripts =
pre:version_increment_pre.py
post:version_increment_post.py
;I followed the instructions from your post to use the latest beta, using the Teensyduino.app from the beta2 test build. Perhaps I missed an important step?
Thanks,
Ed
sbfreddie
Well-known member
Luni:
My platformio.ini file now looks like:
No change still the exact same errors!!!
Thanks,
Ed
My platformio.ini file now looks like:
Code:
; PlatformIO Project Configuration File
;
; Build options: build flags, source filter
; Upload options: custom upload port, speed and extra flags
; Library options: dependencies, extra library storages
; Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; https://docs.platformio.org/page/projectconf.html
;[env:stable]
;platform = https://github.com/platformio/platform-teensy.git
;
;board = teensy41
;
;framework = arduino
;
[env:teensy41]
platform = teensy
board = teensy41
framework = arduino
;
platform_packages =
toolchain-gccarmnoneeabi@file:///Users/freddie/pio/teensy_1.59-beta2/toolchain-gccarmnoneeabi
framework-arduinoteensy@file:///Users/freddie/pio/teensy_1.59-beta2/framework-arduinoteensy
tool-teensy@file:///Users/freddie/pio/teensy_1.59-beta2/tool-teensy
;platform_packages =
;toolchain-gccarmnoneeabi@file:///Users/freddie/pio/teensy_1.58-beta3/toolchain-gccarmnoneeabi
;framework-arduinoteensy@file:///Users/freddie/pio/teensy_1.58-beta3/framework-arduinoteensy
;tool-teensy@file:///Users/freddie/pio/teensy_1.58-beta3/tool-teensy
;
;
build_flags =
-Wl,--print-memory-usage
-g
-D USB_MTPDISK_SERIAL
-std=gnu++17
-std=gnu++14
;build_type = release
;
#lib_extra_dirs = ~/Documents/Arduino/libraries
;
check_tool = cppcheck
check_flags = --enable=all
extra_scripts =
pre:version_increment_pre.py
post:version_increment_post.py
;No change still the exact same errors!!!
Thanks,
Ed
luni
Well-known member
The TD1.59beta uses a newer c++ language standard (gnu++17). The compiler (or some implicit PIO options) default to gnu++14 which was the language standard used until TD1.58. The given options disable the gnu++14 setting and enable the gnu++17 setting. I assume that PIO will set that by default as soon as the beta gets released. Might be worth posting that at the PlatformIO forum.
The default mode for the 11.3.1 compiler is C++17. Thus, only the `build_unflags = -std=gnu++14` is needed, not the `build_flags = -std=gnu++17` line. (More on why "gnu++17" as opposed to "c++17" below.)
(Personally, I've been using `build_unflags = -std=gnu++14 -std=c++14` to catch all potential cases, but only un-setting gnu++14 is needed.)
This happens because Teensyduino 1.58 still uses C++14 via the `-std=gnu++14` build flag. PlatformIO copied this. You can see it in _boards.txt_. On a Mac, you'll find this file in one of these places:
1. (Arduino IDE v1.8.19, Teensyduino 1.58 download): /Applications/Teensyduino.app/Contents/Java/hardware/teensy/avr/boards.txt
2. (Teensyduino 1.58 for Arduino IDE v2.1.0): ~/Library/Arduino15/packages/teensy/hardware/avr/1.58.1/boards.txt
Look for the `teensy41.build.flags.cpp` line (for Teensy 4.1, `teensy40` for Teensy 4.0, etc.).
The GNU compiler supports either the c++17/c++14 or gnu++17/gnu++14 `-std` flags. The "gnu++" versions add a few GNU compiler-specific things, and the "c++" versions disallow those extensions. Teensyduino has chosen to use the version with the GNU-specific extensions.
Summary
In summary, for PlatformIO to use C++17 with Teensyduino 1.58, it is sufficient to add only:
(Personally, I've been using `build_unflags = -std=gnu++14 -std=c++14` to catch all potential cases, but only un-setting gnu++14 is needed.)
This happens because Teensyduino 1.58 still uses C++14 via the `-std=gnu++14` build flag. PlatformIO copied this. You can see it in _boards.txt_. On a Mac, you'll find this file in one of these places:
1. (Arduino IDE v1.8.19, Teensyduino 1.58 download): /Applications/Teensyduino.app/Contents/Java/hardware/teensy/avr/boards.txt
2. (Teensyduino 1.58 for Arduino IDE v2.1.0): ~/Library/Arduino15/packages/teensy/hardware/avr/1.58.1/boards.txt
Look for the `teensy41.build.flags.cpp` line (for Teensy 4.1, `teensy40` for Teensy 4.0, etc.).
The GNU compiler supports either the c++17/c++14 or gnu++17/gnu++14 `-std` flags. The "gnu++" versions add a few GNU compiler-specific things, and the "c++" versions disallow those extensions. Teensyduino has chosen to use the version with the GNU-specific extensions.
Summary
In summary, for PlatformIO to use C++17 with Teensyduino 1.58, it is sufficient to add only:
Code:
build_unflags = -std=gnu++14
Last edited:
I find that the PlatformIO team is pretty good at correctly copying what's in the Teensyduino releases, so if v1.59 removes the `-std=gnu++14` flag, I'm pretty confident that they'll follow this change.
Useful link for whipping up a PlatformIO release based on a pre-release version of Teensyduino:
https://forum.pjrc.com/threads/71730-How-to-add-a-Teensyduino-(beta)-release-to-PlatformIO
Three features I use from C++17:
1. Deduction guides for std::array. This makes it so you don't need some form of `make_array` (your own or what's in `std::experimental`) to deduce the count. This is my favourite so far.
2. `if constexpr` (https://en.cppreference.com/w/cpp/language/if)
3. The ability to specify a namespace all at once, eg. `namespace a::b { ...stuff... }` (https://en.cppreference.com/w/cpp/language/namespace)
1. Deduction guides for std::array. This makes it so you don't need some form of `make_array` (your own or what's in `std::experimental`) to deduce the count. This is my favourite so far.
2. `if constexpr` (https://en.cppreference.com/w/cpp/language/if)
3. The ability to specify a namespace all at once, eg. `namespace a::b { ...stuff... }` (https://en.cppreference.com/w/cpp/language/namespace)
defragster
Senior Member+
Just had the PJRC teensy41_psram_memtest.ino sketch open. Made edit for PR #708 in startup.c.
It completes with no errors on T_4.1 with 8MB PSRAM:
Code:
...
testing with fixed pattern 00000000
test ran for 29.94 seconds
All memory tests passed :-)Instead of "36.43 seconds" seen here: Teensy-4-1-EXTMEM-and-USB-UART-not-responsive-anymore
Running with that code and 1,000 ISR's doing Print Speed test with some SENT usb data from PC:
Code:
...
test ran for 30.44 seconds
All memory tests passed :-)Not exhaustive test, but it was at hand and here is that code with _isr() print and receive on T_4.1 w/16MB PSRAM:
Code:
EXTMEM Memory Test, 16 Mbyte
CCM_CBCMR=B5AE8304 (88.0 MHz)
...
test ran for 60.87 seconds
All memory tests passed :-)aBOVE WAS BUILT IN ide 2 W/td 1.59 BETA 2 EDIT {sry caplocks}
<edit> see next post re issue of hang ...
Going back to unedited IDE 1.8.19 copy with TD 1.58 - where it was developed and tested.
Now when PC send USB text it HANGS both T_4.1's?
With no input it completes to:
> 8 MB :: test ran for 37.28 seconds ... All memory tests passed
> 16 MB :: test ran for 74.54 seconds ... All memory tests passed
It works sending a short 'HELLO' - but hangs passed the sketch path (maybe 2nd time) "T:\T_Drive\tCode\FORUM\teensy41_psram_SerSpeed\teensy41_psram_SerSpeed.ino"
> 77 chars plus terminator less than stack buffer of "char b[256];"
Power off T_4.1's some ~minute and power on with Button to flash the 'now' failing IDE 1 TD 1.59.b2 - and it fails on both again.
One T_4.1 is 'locked' so no 15sec Restore - did on the other and same result?
Also fails both with this truncated {"T:\T_Drive\tCode\FORUM\teensy41_psram_SerSpeed} shorter string, between braces.
Return to IDE 2 build with CORES edit and it completes faster and accepts numerous sends of that file path?
Linked post code test string shown was: {Arduino code using PJRC TeensyDuino 1.59 beta 2 on IDE 1.8.19:}
It never failed before with unaltered code used or having been run. Now returning to that string and IDE 1 that string can make both fail with repeats as likely done before?
And neither string has shown failure on either on IDE 2 with edit to startup.c from the PR on either T_4.1 ????
<EDIT>: Clearly odd ... restored C:\Users\Tim\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.58.1\cores\teensy4\startup.c to original under IDE 2 and built and ran fine on both T_4.1 - just slower - when sending that 'path' repeatedly?
Last edited:
defragster
Senior Member+
RE Prior p#113 - hanging T_4.1's when it seemed to work before ...
Picked up another T_4.1 with PSRAM - Had never run the PR Edit for 'PreFetch' : It also fails so nothing to do with that edit. Also Added CrashReport - and there is NO CrashReport captured - Seems USB just dies but only using TD 1.59.b2 - no repro with TD 1.58.
For Fun the Code noted is now: github.com/Defragster/TeensySketches/blob/main/teensy41_psram_SerSpeed/teensy41_psram_SerSpeed.ino
Just UPDATED and FIXED. No repro on three T_4.1's that it did before. For some reason the '\n' was not received in this loop and it was not exiting? - added the break case:
That code was from other 'RTOS' thread posted code and it had issues ... ODD though that TD 1.58 didn't trigger when TD 1.59.b2 does where '\n' doesn't terminate incoming Serial data?
As noted on that thread - this code is wrong to be using Serial.print in setup() and the _isr() - it proved a point but is not KOSHER as seen in this string where a '.' is interjected in the received text string print (Rare but it happens) at "GitH.ub":
Made change to CORES for IDE 1 TD 1.59.b2 and it works properly to test PSRAM and completes in expected/noted shorter time. Prior edit was IDE 2 1.58.1.
If the PreFetch [Post #99] PR - this sketch doesn't show problems with data integrity - but runs faster as it does the bulk read back testing.
Picked up another T_4.1 with PSRAM - Had never run the PR Edit for 'PreFetch' : It also fails so nothing to do with that edit. Also Added CrashReport - and there is NO CrashReport captured - Seems USB just dies but only using TD 1.59.b2 - no repro with TD 1.58.
For Fun the Code noted is now: github.com/Defragster/TeensySketches/blob/main/teensy41_psram_SerSpeed/teensy41_psram_SerSpeed.ino
Just UPDATED and FIXED. No repro on three T_4.1's that it did before. For some reason the '\n' was not received in this loop and it was not exiting? - added the break case:
Code:
void loop_ISR() {
...
do {
if (Serial.available()) {
b[ii++] = c = Serial.read();
}
[B] else
break;
[/B] } while (c != '\n');That code was from other 'RTOS' thread posted code and it had issues ... ODD though that TD 1.58 didn't trigger when TD 1.59.b2 does where '\n' doesn't terminate incoming Serial data?
As noted on that thread - this code is wrong to be using Serial.print in setup() and the _isr() - it proved a point but is not KOSHER as seen in this string where a '.' is interjected in the received text string print (Rare but it happens) at "GitH.ub":
Made change to CORES for IDE 1 TD 1.59.b2 and it works properly to test PSRAM and completes in expected/noted shorter time. Prior edit was IDE 2 1.58.1.
If the PreFetch [Post #99] PR - this sketch doesn't show problems with data integrity - but runs faster as it does the bulk read back testing.
defragster
Senior Member+
Regarding this and github.com/PaulStoffregen/cores/pull/708 to enable PreFetch on PSRAM:
Noted the speed up with psram_memtest - and saw that safe with abusive print _isr.
Other simple test that came to mind was: "...\LittleFS\examples\Test_Integrity\PSRAM\PSRAM.ino"
> that runs a series of LittleFS File Add/extend/delete tests and verifies file integrity across the changes
Ran that on 3 T_4.1's and no errors without or with PreFetch PR in place on 1.59.b2.
That code doesn't look to optimize speed - but integrity of reads/writes for LittleFS management. Though with PreFetch enabled a hundred/'K' series of loops the time did drop from: 186 down to 176 seconds.
> Not significant but consistent improvement. Writes are read back and files read before delete.
> The I/O changes are in 2KB to 7KB range across multiple files so Cache and PreFetch data won't always be useful.
Upped to larger and more files the thousand pass took 446 seconds before the PR 708 and 417 seconds with the PR and no corruption detected.
<EDIT> Ran LittleFS again with alt file file params to better use more disk space:
Code:
// Adjust these for amount of disk space used in iterations
#define MAXNUM 15 // Number of files : ALPHA A-Z is MAX of 26, less for fewer files
#define NUMDIRS 12 // Number of Directories to use 0 is Rootonly
#define BIGADD 2*2024 // bytes added each pass - bigger will quickly consume more space
#define SUBADD 4*512 // bytes added each pass (*times file number)
#define MAXFILL 66000 // ZERO to disable :: Prevent iterations from over filling - require this much free
[B]GAVE[/B] this after 1000 loops with 'k':
Bytes Used: 5707776, Bytes Total:8388608
Loop Count: 1001 (#fileCycle=64235), Bytes read 2118896944, written 810482800, #Files=157Both run the same test with same file sizes and order as the Integrity test did for Repro.
Larger files result in some faster reads up to 200KB/sec - some writes got that too.
Net overall - 10 to 11% improvement [Total I/O R+W=2,929,379,744 Bytes:
27.99M (1679 secs) without PreFetch Total I/O in time 1.744 MilB/sec
25.15M (1509 secs) with PreFetch : Total I/O in time 1.941 MilB/sec
Last edited:
defragster
Senior Member+
Made this PR: github.com/PaulStoffregen/cores/pull/707
> anyone else ever notice when they get their first crash and print CrashReport it spits out a List of BreadCrumbs that were never passed to be saved?
There were TODO provisions for checksum storage to verify when BC's were saved - a simple update making short use of that checksum field helps.
Placed a test note on PR 708 linking above - didn't see issues with prefetch enable in those two tests. Without errata having it fail - seems the issue might be doing quick reads all over and having some cycles wasted fetching data that will be flushed from the cache before it is used and reread later.
> anyone else ever notice when they get their first crash and print CrashReport it spits out a List of BreadCrumbs that were never passed to be saved?
There were TODO provisions for checksum storage to verify when BC's were saved - a simple update making short use of that checksum field helps.
Placed a test note on PR 708 linking above - didn't see issues with prefetch enable in those two tests. Without errata having it fail - seems the issue might be doing quick reads all over and having some cycles wasted fetching data that will be flushed from the cache before it is used and reread later.
PaulStoffregen
Well-known member
Has this been tested with NOR or NAND flash on the other QSPI pads?
I believe LittleFS should be using only IP bus. Earlier experimental code did access flash chips by AHB. This change will probably break that old code, but maybe that's ok as we really only support Flash by LittleFS now.
I believe LittleFS should be using only IP bus. Earlier experimental code did access flash chips by AHB. This change will probably break that old code, but maybe that's ok as we really only support Flash by LittleFS now.
defragster
Senior Member+
No, didn't go that deep - just read it as PSRAM.
Seems like there may be one of each on the desk ... test started with no PR
Code:
printDirectory QSPI_NAND
--------------
0 dirs with 0 files of Size 0 Bytes
Total 0 files of Size 0 Bytes
Bytes Used: 262144, Bytes Total:265289728
// started and quickly stopped:
[B] == == == DELETE PASS START == == == =
:: /1_dir/B_file.txt <Bad Byte! b! = a [0x61] @1
0[ 1.58 M](0.49145 M elap) Awaiting input 0123456789RdDwcghkFqvplmusSBbyYxfan+-? loops left 0 >[/B]
Code:
printDirectory QSPI_DISK
--------------
5 dirs with 0 files of Size 0 Bytes
Total 0 files of Size 0 Bytes
Bytes Used: 786432, Bytes Total:16777216Saw this twice after 'q'uick format?
WARNING: DISK FULL >>>>> Bytes Used: 265289728, Bytes Total:265289728
Not sure if it was on NAND both times?
Seems this NAND gone bad?
Code:
Formatting Low Level:
...............................................................................................................................
Done Formatting Low Level in 11330598 us.
Updated filecount 0
F
[ 6.48 M](0.18885 M elap) Awaiting input 0123456789RdDwcghkFqvplmusSBbyYxfan+-? loops left 0 >m
Making Root Dirs
d
printDirectory QSPI_NAND
--------------
DIR 1_dir /
0 dirs with 0 files of Size 0 Bytes
DIR 2_dir /
0 dirs with 0 files of Size 0 Bytes
DIR 3_dir /
0 dirs with 0 files of Size 0 Bytes
DIR 4_dir /
0 dirs with 0 files of Size 0 Bytes
DIR 5_dir /
0 dirs with 0 files of Size 0 Bytes
5 dirs with 0 files of Size 0 Bytes
Total 0 files of Size 0 Bytes
Bytes Used: 265289728, Bytes Total:265289728
WARNING: DISK FULL >>>>> Bytes Used: 265289728, Bytes Total:265289728More after Zzzz's
In theory wasted prefetching can't negatively affect performance; any in-progress prefetching is suspended when a new AHB transaction arrives for FlexSPI.
defragster
Senior Member+
Found a working T_4.1 with QSPI NAND - not sure why the other faulting - but it isn't the software since this one works.
Made a pass through NOR and NAND - NO ERRORS - Speed results are unclear. Need to incorporate low level "F"ormat and "R"estart before running ## loops.
What shows as 13 minutes NOR is 60 minutes NAND and the NAND media usage is 2X (format block sizes math) with default Integrity\QSPI settings
> NAND: Bytes Used: 5242880, Bytes Total:131596288 :: Total 28 files of Size 192944 Bytes
> NOR: Bytes Used: 2621440, Bytes Total:16777216
Times are similar if not faster without the PR708? So time spent reformatting on the fly from prior use could make some difference.
NAND Using 5MB of Media for 192 K of files/dirs - but lots of Media unused. May change file/dir counts and size and only run 'h'undred loops to complete sooner.
Made a pass through NOR and NAND - NO ERRORS - Speed results are unclear. Need to incorporate low level "F"ormat and "R"estart before running ## loops.
What shows as 13 minutes NOR is 60 minutes NAND and the NAND media usage is 2X (format block sizes math) with default Integrity\QSPI settings
> NAND: Bytes Used: 5242880, Bytes Total:131596288 :: Total 28 files of Size 192944 Bytes
> NOR: Bytes Used: 2621440, Bytes Total:16777216
Times are similar if not faster without the PR708? So time spent reformatting on the fly from prior use could make some difference.
NAND Using 5MB of Media for 192 K of files/dirs - but lots of Media unused. May change file/dir counts and size and only run 'h'undred loops to complete sooner.
That makes sense they'd do that.
What about making the checksum the inverse value of the bitmask rather than a direct copy? I think that would be a little bit safer since it's common for memory to be filled with repeated values, causing bitmask and checksum to unintentionally match.
defragster
Senior Member+
Yes, that is a simple change that was considered and could be done - but the values observed (as in the PR) didn't suggest that would be needed.
Not seen anyone else complain about errant breadcrumbs - but they have been showing and it just isn't right so that was done. Waiting feedback from Paul - as noted the PR has BUGBUG debug code to demo the problem that would otherwise now be hidden.
defragster
Senior Member+
Raw Results: Little FS NOR and NAND running with and without the PR 708 edit :: NO ERRORS
Elapsed times for these tests are remarkably similar showing no improvement like PSRAM case did when PR 708 change was made. Though the NOR is 2.66 minutes faster for the same process than NAND.
NAND::
Code:
[U]QSPI_NAND 4:54 PM 7/13/2023 NON-PR ## 9600[/U]
[ 18.81 M]([B]18.47611 M elap[/B]) Awaiting input 0123456789RdDwcghkFqvplmusSBbyYxfan+-? loops left 0 >
Walk all Files verify Read Size:
D1 CDEGHIJKLMNO
D2 ABCDEFGHIJKLMNO
D3 ABCDEFGHIJKLMNO
D4 ABCDEFGHIJKMNO
D5 ABCDEFGHIJKLMO
D6 CDEFGHIJKMNO
ABCDEFGHIJKLMN 0 Errors found
Bytes Used: 14680064, Bytes Total:131596288
Loop Count: 102 (#fileCycle=4025), Bytes read 174110000, written 56138384, #Files=96
Code:
[B]QSPI_NAND 3:03 PM 7/13/2023 PR 708 ## 9600[/B]
[ 20.25 M]([B]18.47911 M elap[/B]) Awaiting input 0123456789RdDwcghkFqvplmusSBbyYxfan+-? loops left 0 >
Walk all Files verify Read Size:
D1 CDEGHIJKLMNO
D2 ABCDEFGHIJKLMNO
D3 ABCDEFGHIJKLMNO
D4 ABCDEFGHIJKMNO
D5 ABCDEFGHIJKLMO
D6 CDEFGHIJKMNO
ABCDEFGHIJKLMN 0 Errors found
Bytes Used: 14680064, Bytes Total:131596288
Loop Count: 102 (#fileCycle=4025), Bytes read 174110000, written 56138384, #Files=96NOR::
Code:
[U]QSPI_DISK 4:53 PM 7/13/2023 NON-PR ## 8860[/U]
[ 16.18 M]([B]15.71656 M elap[/B]) Awaiting input 0123456789RdDwcghkFqvplmusSBbyYxfan+-? loops left 0 >
Walk all Files verify Read Size:
D1 CDEGHIJKLMNO
D2 ABCDEFGHIJKLMNO
D3 ABCDEFGHIJKLMNO
D4 ABCDEFGHIJKMNO
D5 ABCDEFGHIJKLMO
D6 CDEFGHIJKMNO
ABCDEFGHIJKLMN 0 Errors found
Bytes Used: 8912896, Bytes Total:16777216
Loop Count: 102 (#fileCycle=4025), Bytes read 174110000, written 56138384, #Files=96
Code:
[B]QSPI_DISK 3:05 PM 7/13/2023 PR 708 ## 8860[/B]
[ 16.62 M]([B]15.71530 M elap[/B]) Awaiting input 0123456789RdDwcghkFqvplmusSBbyYxfan+-? loops left 0 >
Walk all Files verify Read Size:
D1 CDEGHIJKLMNO
D2 ABCDEFGHIJKLMNO
D3 ABCDEFGHIJKLMNO
D4 ABCDEFGHIJKMNO
D5 ABCDEFGHIJKLMO
D6 CDEFGHIJKMNO
ABCDEFGHIJKLMN 0 Errors found
Bytes Used: 8912896, Bytes Total:16777216
Loop Count: 102 (#fileCycle=4025), Bytes read 174110000, written 56138384, #Files=96Process used notes:
Code:
LittleFS Test : File Integrity
printDirectory QSPI_DISK
// Adjust these for amount of disk space used in iterations
#define MAXNUM 15 // Number of files : ALPHA A-Z is MAX of 26, less for fewer files
#define NUMDIRS 6 // Number of Directories to use 0 is Rootonly
#define BIGADD 2*2024 // bytes added each pass - bigger will quickly consume more space
#define SUBADD 4*512 // bytes added each pass (*times file number)
#define MAXFILL 66000 // ZERO to disable :: Prevent iterations from over filling - require this much free
--------------
>> "F", NEW CODE, hI've been aware of them, but you only see them if your program has already crashed so you know if they're relevant or not...
Something I would like to see is the breadcrumb/crashreport address dynamically calculated based on the size of the DMAMEM region, since it's possible to make it bigger than 256KB / end beyond address 0x20280000.
defragster
Senior Member+
Good to know it wasn't just me. Yes, obvious they are garbage when never used - but not confidence inspiring for correctness.
Not sure what the DMAMEM region size and 'dynamic calc' refers to? DMAMEM is a fixed 512KB aka RAM2 starting at 0x20200000. CrashReport and BreadCrumbs reside at a fixed location at the top of that 512KB region - up 524,160 bytes.
Code:
struct arm_fault_info_struct *info = (struct arm_fault_info_struct *)0x2027FF80;
struct crashreport_breadcrumbs_struct *bc = (struct crashreport_breadcrumbs_struct *)0x2027FFC0;