Teensyduino 1.54 Beta #11

Status
Not open for further replies.
defragster said:
:)



Indeed ... See p# 21 and #20


Just confirmed that on T_4 the .print("const char strings data") is stored in Flash like F() ... they do not go into RAM1


RE: SD Warnings :: Also ran listfiles.ino and did not see any warnings.
Click to expand...

I'm sorry I don't understand ".print("const char strings data")".
 
BriComp said:
I'm sorry I don't understand ".print("const char strings data")".
Click to expand...

Was meant for general DEV note:
CrashReport has a large number of strings for output : that snippet was to be self documenting :: ".print("const char strings data")".

Any enclosed string used in a .print() will be linked in from FLASH not stored in RAM1 --- on a T_4.x anyhow --- as they resolve to "const char strings data"

At least in those CrashReport func()'s declared as :: FLASHMEM
 
OK.
The discussion was whether the formatted output should be maintained as it was taking up an awful lot of program space.

I was trying to ascertain what happens when a crash occurs and how it is dealt with.

It would appear to me that the crash data is stored in OCRAM when it occurs and the crash report is linked into the running program which caused the program, taking up a lot of program space.

I was hoping that the crashing program, when it re-booted, simply stored the Crash Data into non-volatile memory and put out a simple message that the crash has occurred, and should be investigated before shutting down.

Another sketch, not the one that caused the problem, can then be executed to display the report with as much formatting and fanfare as is required.

You must remember that a large number of Teensys are used remote with out any display. Writing a formatted report to a display which does not exist is a waste of time and program (memory) resource.
Much easier to be able to take it to somewhere where it can be connected to a computer and a sketch run to display the error report.
 
BriComp,

I think we should explain some things in more detail.
The purpose of the CrahsReport is mainly development. For the production environment, the bugs that lead to a crash should actually - ideally - be fixed.
No display is addressed either. No external hardware. Crashreport would have to know which Display is addressed in which way. It does not even try to know that.
It even knows nothing about the internal devices. It's all about the CPU itself.
No, it is your responsibility what you do with the Crashreport.
You can ignore it, save it somewhere, output it via USB or hardware serial, whatever. E.g. also save the data in the emulated eeprom.
That's up to you.
In general, the Crashreport can only detect very significant errors. Which ones, enough examples were posted in the different threads. They are all related to the CPU. Everything else cannot be covered by the Report, and that is not wanted.

As for your remote thing:
That's a very rare use case. The report does not care about it. It doesn't even know that your Teensy works like that.
It is up to you to save the data. If you really want to output them with another program, you can do that if you store them somewhere readable first.
 
For CrashReport in TD 1.54 - it doesn't expose the crash data. It can be found and maintained and restored - I did it with core edits on this thread : pjrc.com/threads/66403-Re-enable-bootloader-interrupts-after-a-hard-fault-Teensy-4-1

The idea at this time is that TD 1.54 will be wrapped up with this first pass for typical support. Future work would be a new release of TeensyDuino.

As for making immediate use see this post #21 : pjrc.com/threads/67588-Teensyduino-1-54-Beta-11?

crosspost ... there was SD write added to the first example by @mjs513 and later in the thread I posted code to run all the MyFault samples to to SD on that thread ... pjrc.com/threads/66403-Re-enable-bootloader-interrupts-after-a-hard-fault-Teensy-4-1
 
Ok, I just got confused about all mention of so much space being used up by the crash report when it does not matter since it is just an investigative piece of code to determined what had happened.
 
Note, not the report needs much space.
Printf needs some space.
If you use it in your program anyway, the needed additional space is very small.
 
Last edited:
BriComp said:
Ok, I just got confused about all mention of so much space being used up by the crash report when it does not matter since it is just an investigative piece of code to determined what had happened.
Click to expand...

Indeed without a reference to CrashReport there is nothing added to the build, it drops out when not referenced.

This example "Stack_overflow.ino" with this "Serial.print(CrashReport);" line commented reports this on building:
Code: 
teensy_size: Memory Usage on Teensy 4.0:
teensy_size:   [B]FLASH: code:8164, data:376[/B], headers:8864   free for files:2014212
teensy_size:    [B]RAM1: variables:8896[/B], code:6496, padding:26272   free for local variables:482624
teensy_size:    RAM2: variables:12384  free for malloc/new:511904


When that line is restored usage follows, and then it prints the saved data - the data is in 'static' RAM2 as long as power is not removed another sketch can upload to print the CrashReport.
Code: 
teensy_size: Memory Usage on Teensy 4.0:
teensy_size:   [B]FLASH: code:11836, data:2648[/B], headers:9064   free for files:2008068
teensy_size:    [B]RAM1: variables:12992[/B], code:8560, padding:24208   free for local variables:478528
teensy_size:    RAM2: variables:12384  free for malloc/new:511904

The ONLY area used is some 128 Bytes at the end of RAM2/DMAMEM where it will be overwritten if a fault occures - that is part of the TD 1.54 code at this point.

>> Some minimal amount of code was added in startup.c in unused_interrupt_vector() to capture system state to the RAM2 area.
 
BriComp said:
Ok, so how do I access the crash data to save it elsewhere?
Click to expand...

If you want the raw data, don't use CrashReport. The raw format is a struct defined at the end of imxrt.h. But you might use CrashReport.cpp as example code, rather than having to start writing your own from scratch. Most of those field names match ARM SCB registers, which are documented in the ARM Architecture V7M Reference Manual. Google for "DDI0403E" to find it. This part isn't in the NXP reference manual. It's the Cortex M7 processor which NXP licenses from ARM, so the documentation of these registers is published by ARM. You might also consider the Definitive Guide... book by Josheph Yiu. If you're not already familiar with ARM architecture, ARM's documentation can be quite difficult to understand. That book explains ARM architecture details which is pretty much essential background knowledge to make use of these features.

If you want to save the text output that CrashReport gives, it can be used with classes which derive from Print & Stream. SD, EthernetClient, etc. Or if none of those suit your needs, but you still want to grab the text output, you could create your own simple class which derives from Print & Stream and fill in a write() function which sends the text to the location you desire.
 
Frank B said:
So, sorry for the "false" alarm - but maybe someone (you, Bill) wants to fix it anyway now?:
Click to expand...

Please open a SdFar issue on github for Bill.

My desire is to keep the copy of SdFat we're shipping in Teensyduino as close to Bill's original code as possible. I did make a couple tiny edits, but only things that were really necessary.
 
BriComp said:
I was hoping that the crashing program, when it re-booted, simply stored the Crash Data into non-volatile memory and put out a simple message that the crash has occurred, and should be investigated before shutting down.
Click to expand...

The overall design is only very minimal data collection is built into all programs. Because this code is build automatically built into all programs, it is meant to kept as small as possible. Because it runs after a problem has occurred, it is meant to be as simple as possible.

The always-built code does several things, more than just data collection.

1: Store processor state & other useful info to RAM
2: Reduce CPU speed to 198 MHz
3: Complete USB transmission, so all Serial.print() before the problem arrives at the Arduino serial monitor
4: Try to remain USB responsive to Arduino's upload button
5: Automatically reboot after 8 seconds


Another sketch, not the one that caused the problem, can then be executed to display the report with as much formatting and fanfare as is required.
Click to expand...

You can do this, but as I tried to explain a few days ago when you brought this up on another thread, the fault handler and CrashReport are lightweight tools meant to give you a way to build this yourself. They aren't meant to do everything for you.

Don't be unhappy that it's not logging data to EEPROM. It's not supposed to do that. It only makes the data available for you to do with as you wish. If you want the data logged somewhere, that's your job.


You must remember that a large number of Teensys are used remote with out any display.
Click to expand...

Indeed, that's the reason it's designed this way. Only you know how your actual application works. That's why this system is designed to give you tools to build your own solution.

The unused interrupt function performs those 5 low-level tasks using simple & minimal code. Then it up to you to use CrashReport and/or your own code to inspect (or save & inspect) the data in the way which works for your application.

If you don't use CrashReport or anything else in your code to view the data from step #1, you're still getting those 5 steps built into every program. Today with 1.53 and earlier versions, nearly all crashes result in a hung board which needs a power cycle to recover or a physical button press to get back into programming mode. Data logging for common problems (but not all types of crashes) is just one of the features.
 
Installed on Win10 Laptop over IDE 1.8.13 no trouble - working with a T_4.1

Using laptop in the cool part of the house with Beta 11 - realizing with jump to CrashReport (and other the diversions) LFSIntegrity cleanup and rename didn't happen.
 
bicycleguy said:
The CrashReport feature is awesome! But I think there will be a huge number of questions, (from me alone!) Is there a thread for these besides the not so obviously named https://forum.pjrc.com/threads/6640...nterrupts-after-a-hard-fault-Teensy-4-1/page1 and https://github.com/PaulStoffregen/MyFault/tree/main/examples?
Click to expand...

That Thread : pjrc.com/threads/66403-Re-enable-bootloader-interrupts-after-a-hard-fault-Teensy-4-1 it where it was announced and developed. Though a special new thread with a new Name might evolve with release and use or updates.

The github for MyFault shows the known ways it will/won't works. The TypicalUse was hoped to be a generic DEMO of ... TypicalUse - with enough notes to explain - and as written is uploaded when CrashReport data is stored from a prior run it will present them:
Code: 
// Typical Usage Example : when a sketch is leaving the Teensy non-responsive
// Compile this sketch with USB Serial
// With Serial Monitor attaching it will restart and show the CrashReport
// If Serial Monitor is not active it will continue to Crash and restart

void setup() {
  Serial.begin(9600); // With TeensyDuino 1.54 Serial.begin() may return connected
  if ( Serial && CrashReport ) { // Make sure Serial is alive and there is a CrashReport stored.
    Serial.print(CrashReport); // Once called any crash data is cleared
    // In this case USB Serial is used - but any Stream capable output will work : SD Card or other UART Serial
  }
  else {
    // Following code will cause a Fault of the processor from writing to a NULL pointer
    // Don't run it again until the next restart showing normal after a fault
    uint32_t *y = 0;
    y[0] = 5;
  }
  pinMode( LED_BUILTIN, OUTPUT );
}

elapsedMillis blinkTime;
void loop() {
  if ( blinkTime > 1000 ) {
    digitalToggle( LED_BUILTIN );
    blinkTime = 0;
  }
}

It was written before the current text response was added to CrashReport and could be tweeked to use that and demo that as well.
 
PaulStoffregen said:
Please open a SdFar issue on github for Bill.
Click to expand...
Done: https://github.com/greiman/SdFat-beta/issues/72

Edit: Bill fixed it.

Please note there is a newer Version: 2.1.0-beta.2 - but trying to use it gives errors - not only warnings.
Code: 
C:\Arduino\hardware\teensy\avr\libraries\SdFat\src\ExFatLib\upcase.h:31:25: error: 'ExChar16_t' does not name a type; did you mean 'char16_t'?
   31 |                   const ExChar16_t* name, size_t offset, size_t n);
I have not informed Bill about this because I don't know if this is part of the changes that you are making.
If Bill needs to be informed about it, it would be better if you did.
 
Last edited:
The always-built code does several things, more than just data collection.

1: Store processor state & other useful info to RAM
2: Reduce CPU speed to 198 MHz
3: Complete USB transmission, so all Serial.print() before the problem arrives at the Arduino serial monitor
4: Try to remain USB responsive to Arduino's upload button
5: Automatically reboot after 8 seconds
Click to expand...

I am afraid I got confused, I thought the above happened after the Teensy Re-booted rather than upon crashing.
 
Frank B said:
I have not informed Bill about this because I don't know if this is part of the changes that you are making.
If Bill needs to be informed about it, it would be better if you did.
Click to expand...

Let's talk of this in a couple weeks, after 1.54 is released and after Teensy 4.1 is back in stock.

For 1.54, we're definitely going with the copy of SdFat that's been pretty well tested over the last few months.
 
regarding cleanup LittleFS/.../LFSIntegrity.

Not seeing a clean way to do this::
> First thought was just pull out SETUP() and LOOP() unique to each FS Media type. Then have a second file with the MANY common utility func()'s

Seeing an issue where "myfs" in one file will be constructed of 'some' type - then in second file - it can't 'extern "generic" myfs' but will need the specific type declared ?

Ending up with Redefine of CLASS is placed in .cpp and again including :: #include <LittleFS_NAND.h>
Code: 
T:\arduino-1.8.15\hardware\teensy\avr\libraries\LittleFS\src/LittleFS_NAND.h:71:7: error: redefinition of 'class LittleFS_SPINAND'
 class LittleFS_SPINAND : public LittleFS
       ^

Second file of .CPP as second .INO and then get:
Code: 
T:\arduino-1.8.15\hardware\teensy\avr\cores\teensy4/FS.h:37:0: warning: "FILE_READ" redefined
 #define FILE_READ  0
 ^
In file included from t:\arduino-1.8.15\hardware\teensy\avr\libraries\sdfat\src\fatlib\FatFile.h:994:0,
                 from t:\arduino-1.8.15\hardware\teensy\avr\libraries\sdfat\src\fatlib\FatVolume.h:28,
                 from t:\arduino-1.8.15\hardware\teensy\avr\libraries\sdfat\src\fatlib\fatlib.h:27,
                 from t:\arduino-1.8.15\hardware\teensy\avr\libraries\sdfat\src\fslib\FsVolume.h:32,
                 from t:\arduino-1.8.15\hardware\teensy\avr\libraries\sdfat\src\fslib\fslib.h:31,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\SdFat\src/iostream/ios.h:27,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\SdFat\src/iostream/istream.h:31,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\SdFat\src/iostream/iostream.h:31,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\SdFat\src/iostream/bufstream.h:32,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\SdFat\src/iostream/ArduinoStream.h:32,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\SdFat\src/sdios.h:31,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\LittleFS\examples\Integrity\ALL\functions.ino:771:
t:\arduino-1.8.15\hardware\teensy\avr\libraries\sdfat\src\common\arduinofiles.h:31:0: note: this is the location of the previous definition
 #define FILE_READ O_RDONLY
 ^
 
defragster said:
regarding cleanup LittleFS/.../LFSIntegrity.

Not seeing a clean way to do this::
> First thought was just pull out SETUP() and LOOP() unique to each FS Media type. Then have a second file with the MANY common utility func()'s

Seeing an issue where "myfs" in one file will be constructed of 'some' type - then in second file - it can't 'extern "generic" myfs' but will need the specific type declared ?

Ending up with Redefine of CLASS is placed in .cpp and again including :: #include <LittleFS_NAND.h>
Code: 
T:\arduino-1.8.15\hardware\teensy\avr\libraries\LittleFS\src/LittleFS_NAND.h:71:7: error: redefinition of 'class LittleFS_SPINAND'
 class LittleFS_SPINAND : public LittleFS
       ^

Second file of .CPP as second .INO and then get:
Code: 
T:\arduino-1.8.15\hardware\teensy\avr\cores\teensy4/FS.h:37:0: warning: "FILE_READ" redefined
 #define FILE_READ  0
 ^
In file included from t:\arduino-1.8.15\hardware\teensy\avr\libraries\sdfat\src\fatlib\FatFile.h:994:0,
                 from t:\arduino-1.8.15\hardware\teensy\avr\libraries\sdfat\src\fatlib\FatVolume.h:28,
                 from t:\arduino-1.8.15\hardware\teensy\avr\libraries\sdfat\src\fatlib\fatlib.h:27,
                 from t:\arduino-1.8.15\hardware\teensy\avr\libraries\sdfat\src\fslib\FsVolume.h:32,
                 from t:\arduino-1.8.15\hardware\teensy\avr\libraries\sdfat\src\fslib\fslib.h:31,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\SdFat\src/iostream/ios.h:27,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\SdFat\src/iostream/istream.h:31,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\SdFat\src/iostream/iostream.h:31,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\SdFat\src/iostream/bufstream.h:32,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\SdFat\src/iostream/ArduinoStream.h:32,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\SdFat\src/sdios.h:31,
                 from T:\arduino-1.8.15\hardware\teensy\avr\libraries\LittleFS\examples\Integrity\ALL\functions.ino:771:
t:\arduino-1.8.15\hardware\teensy\avr\libraries\sdfat\src\common\arduinofiles.h:31:0: note: this is the location of the previous definition
 #define FILE_READ O_RDONLY
 ^
Click to expand...

@defragster
With the combined .h files now you don't use #include <LittleFS_NAND.h>. As a matter of fact it has been deleted in beta11. Wonder if you have an extra copy of LittleFS floating around..
 
Indeed I've found my install failed to go to the right place on this machine. And even after re-install that xxNAND.h was there.
> Now removed and hopefully that clears that up.
.. > But do need to : #include "LittleFS.h"

Still stuck on a generic :: extern LittleFS myfs;
> If the .INO does the .begin for a specific MEDIA - how is that shared to a second file?
--> the second file just needs to refer to whatever the chosen .begin() created?
> This : LittleFS *p_myfs = myfs;
Code: 
T:\arduino-1.8.15\hardware\teensy\avr\libraries\LittleFS\examples\Integrity\ALL\ALL.ino:168:20: error: cannot convert 'LittleFS_QSPIFlash' to 'LittleFS*' in initialization
 LittleFS *p_myfs = myfs;
                    ^

This isn't something any of the single type at a time in a single file gave as examples. And the split have many other things in the way forst - sharing globals and func prototypes I can deal with ...
 
This isn't something any of the single type at a time in a single file gave as examples. And the split have many other things in the way forst - sharing globals and func prototypes I can deal with ...
Click to expand...
Think you are going to make it way more complicated doing it this way.
 
mjs513 said:
Think you are going to make it way more complicated doing it this way.
Click to expand...

So it seems ... but was looking for a way to move 900+ lines form the main.INO so they Setup and Loop would be apparent and the only changing thing needed for the various Media types.

So that was first thought ... seeing it is problematic I can go to a MONO file, But then wondering if any of this would e a problem for larger projects ... I suppose not as they won't have multiple media type randomly selected but rather known ...

Just wanted to know I wasn't missing something easy/generic for a CLASS * that would let this work.
 
Status
Not open for further replies.
Back
Top