Teensyduino 1.54 Beta #9

Status
Not open for further replies.
On obvious serious errors like this, it should not warn but refuse to compile. The warnings I find not useful at all, super difficult to read with the long paths included.
 
Garug said:
On obvious serious errors like this, it should not warn but refuse to compile. The warnings I find not useful at all, super difficult to read with the long paths included.
Click to expand...

Because of the 'enum' usage it sneaks past the compiler detection, so no warning.
Using #defines for x,y,z,t would cause warnings.

gcc compiler options can be added to call all warnings errors, but generally that is ugly as the various pieces of code from libs or other can make warnings on one build toolchain and not another. PJRC works to have few or no warnings in included libraries.

This is more a non-PJRC 'religious' topic subject to preference and use cases, for instance see embeddedartistry.com/blog/2017/05/22/werror-is-not-your-friend/
 
NativeEthernet / FNET dns issue

beermat said:
NativeEthernet for now appears unsupported (no activity on the forum or in the codebase for several months), which is a shame, because it's super useful, apart from a couple of minor issues like this.
Click to expand...


I aggree with @beermat and I'm astonished that so few people using @vjmuzik NativeEthernet are interested in this (as I think) important dns-client issue.
RoSchmi
 
RoSchmi said:
I aggree with @beermat and I'm astonished that so few people using @vjmuzik NativeEthernet are interested in this (as I think) important dns-client issue.
RoSchmi
Click to expand...

I'm certainly interested. Ethernet is a huge win on the T4.1 The chip actually supports 2 PHYs, would love to see a dual 10/100 teensy 4.2, but NativeEthernet needs some fixes.
 
I'm also interested in any improvements to @vjmuzik NativeEthernet and the eventual merging of native ethernet support into TeensyDuino.
 
SDFat issue

So I have a sketch that compiles in fine in Arduino 1.8.13/Teensyduino 1.53. So I just downloaded a clean copy of Arduino 1.8.15Teensyduino 1.54 beta #9 and I get compile errors.

One was the FlexCAN_T4. I updated the library and the problem went away.

Now I have one with SDFat. Again the Teensyduino library is out of date so I updated it to 2.0.6 which is the latest release.

Still I get a compile error:
'File' does not name a type
File file;
^
4_SDFuntions.h:33: error: 'File' does not name a type
File wfile;//define write file to write header.
^
Click to expand...

I am including the same files as before:
Code: 
#include <SdFat.h>
#include <sdios.h>

...

SdFat sd;
File file;
File wfile;//define write file to write header.

This is really perplexing as to what would have changed between the two IDE sets to cause this error.

Any thoughts?

PS The SDFat example "ReadCsvFile" does not compile either and give me the same error.

PSS So apparently
Code: 
SdFat32 sd;
File32 file;
File32 wfile;
does name a type.

Thanks

Bruce
 
Last edited:
bvernham said:
So I have a sketch that compiles in fine in Arduino 1.8.13/Teensyduino 1.53. So I just downloaded a clean copy of Arduino 1.8.15Teensyduino 1.54 beta #9 and I get compile errors.
...
Now I have one with SDFat. Again the Teensyduino library is out of date so I updated it to 2.0.6 which is the latest release.

Still I get a compile error:

I am including the same files as before:
Code: 
#include <SdFat.h>
...

Thanks

Bruce
Click to expand...

When using TD 1.54 b9, or after, SdFat is included with the TeensyInstaller.

Remove local copies of that library from build paths.

SD.h has been reworked to map into SdFat.

But the full SdFat library is included.
 
Actually the included SDFat library seem to be 1 step behind the github release.

The issue is that all of a sudden "File" is not recognized but "File32" is so it sees the library but why is it ignoring "File"? Both the latest github release and the the packaged version of SDFat in 1.54 beta 9 have the same issue.

If I specify Fat32 then there is no issue.

Like I said with the present SDFat release and Arduino 1.8.13/Teensyduino 1.53 I did not have this issue?

Also as I said above the packaged FlexCAN_T4 was also behind the latest release and needed update.

Thanks

Bruce
 
On platformio, after upgrading to framework-arduinoteensy 1.154.0, I can no longer set a HardFault handler.

Minimal example:

Code: 
FASTRUN
static void hardfault_handler_isr(void) {
    Serial.println("Hardfault");
    Serial.flush();
    while (true);
}

void setup() {
    Serial.begin(9600);
    while (!Serial);
    _VectorsRam[3] = hardfault_handler_isr;
    Serial.println("Hello!");
    int *p = NULL;
    *p = 3;
    Serial.println(*p);
}

With platformio.ini:
Code: 
[env:teensy41]
platform = teensy@4.13.0
Nothing gets printed.

With platformio.ini:
Code: 
[env:teensy41]
platform = teensy@4.12.0
I get "Hardfault" on the console.
 
was an 8 second pause after the caused fault and then a restart seen?

TD 1.54 added : if ( CrashReport ) Serial.print( CrashReport );

That comes from info saved in unused_interrupt_vector()

BUT TD 1.54 has been released - this is an OLD BETA thread at this point ...
 
Ah yes, I posted in the wrong thread!
Correct. I get the 8 second pause and restart. How do I get my custom fault handler running again?
 
There is now "CrashReport" - as defragster mentioned.
I'll close here. Perhaps ask again in a new thread or "Technical support."
 
You'd have to look at the unused_interrupt_vector() code in startup.c - and what leads to it.

To get CrashReport the fault handling was altered for TD 1.54 - not sure but seems that might be behind any change
 
Temporarily reopening this thread, to answer this question

damiend said:
I can no longer set a HardFault handler.

Minimal example:
Click to expand...

This minimal example generates a memory fault, not a hard fault.

It works fine with Teensyduino 1.54 if you simple write the function address to _VectorsRam 4 rather than 3.

Code: 
FASTRUN
static void hardfault_handler_isr(void) {
    Serial.println("Hardfault");
    Serial.flush();
    while (true);
}

void setup() {
    Serial.begin(9600);
    while (!Serial);
    _VectorsRam[4] = hardfault_handler_isr;
    Serial.println("Hello!");
    int *p = NULL;
    *p = 3;
    Serial.println(*p);
}

void loop() {
}

screenshot.png
 
Just to further demonstrate, you can generate a hard fault by causing any sort of fault inside the memory fault handler.

Here's your minimal example extended to cause a memory fault, and then another memory access violation inside the memory fault handler, which then causes a hard fault.

Code: 
FASTRUN
static void hardfault_handler_isr(void) {
    Serial.println("Hardfault");
    Serial.flush();
    while (true);
}

FASTRUN
static void memoryfault_handler_isr(void) {
    Serial.println("Memoryfault");
    Serial.flush();
    int *p = NULL;
    *p = 3;
    while (true);
}

void setup() {
    Serial.begin(9600);
    while (!Serial);
    _VectorsRam[3] = hardfault_handler_isr;
    _VectorsRam[4] = memoryfault_handler_isr;
    Serial.println("Hello!");
    int *p = NULL;
    *p = 3;
    Serial.println(*p);
}

void loop() {
}

Works as it should with Teensyduino 1.54.

screenshot.png
 
Status
Not open for further replies.
Back
Top