T4.1 NativeEthernet Data Access Violations (Nullpointer Exceptions)

Hi!

I'm running a simple TCP-Webserver on the T4.1 with the NativeEthernet Library.
From time to time i encounter this weird Exception (using CrashReport):

A problem occurred at (system time) 9:4:43
Code was executing from address 0xAAE0
CFSR: 82
(DACCVIOL) Data Access Violation
(MMARVALID) Accessed Address: 0x14 (nullptr)
Check code at 0xAAE0 - very likely a bug!
Run "addr2line -e mysketch.ino.elf 0xAAE0" for filename & line number.
Temperature inside the chip was 53.82 °C
Startup CPU clock speed is 600MHz
Reboot was caused by auto reboot after fault or bad interrupt detected

Has anyone of you encountered this problem too?

I was able to pin down the corresponding lines, which cause these issues:
error2.PNG

&

error.PNG

I initialize my Server with the following lines of code... the rest of the code is pretty much just the usual stuff, like in the examples...

Code:
setMAC(mac); Ethernet.setStackHeap(1024 * 64); Ethernet.setSocketSize(1024 * 32); Ethernet.setSocketNum(6);
Ethernet.setRetransmissionTimeout(10); Ethernet.setRetransmissionCount(2); Ethernet.begin(mac, ip, dns, gateway, subnet);
server.begin();

Does anyone have the same problem, with memory caused lockups from time to time?

Anyways, thanks for anyone who could have a clue on that topic.
 
Do you experience the same problem using the QNEthernet library? Note: the initialization is simpler than what you have in your demo code. See the examples for a few ways to initialize.
 
Haven't tried that yet because besides the issues described above the NativeEthernetLib works just fine.

I'm now discarding all the data that is coming out of order in the function:

Code:
static fnet_bool_t _fnet_tcp_add_inpbuf( fnet_socket_if_t *sk, fnet_netbuf_t *insegment, fnet_flag_t *ackparam )
{
    fnet_tcp_control_t  *cb = (fnet_tcp_control_t *)sk->protocol_control;
    fnet_uint32_t       tcp_length = (fnet_uint32_t)FNET_TCP_LENGTH(insegment);
    fnet_uint32_t       tcp_flags = (fnet_uint32_t)FNET_TCP_FLAGS(insegment);
    fnet_bool_t         result = FNET_FALSE; ...

Ran just fine without any exceptions... but after 17hours there was no data coming to my socket buffers anymore / No available clients were detected?...

Because of a network change, or because FNET internal buffers weren't cleared? I have no clue...

Does anybody know if NativeEthernet is still maintained?

Anyways thanks for your time! :)
 
Does anybody know if NativeEthernet is still maintained?

Seems like it's kind of in a gray area. The author (@vjmuzik) has been supportive of QNEthernet, I think because of the relative lack of support for FNET (base of NativeEthernet) versus LWIP (base of QNEthernet).
 
The problem doesn’t have to do with the TCP code itself as far as I’ve been able to find, but most of the time it ends up happening there. It’s a more complicated issue involving the interrupt that’s triggered when data is received, it seems on rare occasion the interrupt corrupts a pointer variable causing it to have the wrong address stored that’s outside of normal memory area.

I’m supportive of QNEthernet because I don’t have the time to dedicate to mine and it doesn’t arguably make a difference which library is used to the people who are familiar with the API. NativeEthernet was just to jumpstart people who wanted to work with Ethernet when the Teensy 4.1 came out without having to relearn things or rewrite previous sketches to some extent. It was thrown together pretty quickly and has its issues, but I myself don’t make much use of it. By the time I made it I was already using FNET by itself on the Teensy 3.6 and 4.0 with USB Ethernet and focusing on it’s multithreading capabilities. It didn’t make much sense for me to switch back by that point, but I was one of the people really pushing for a dedicated Ethernet port on the 4.1 so I felt a little obligated to write it so more people could easily make use of it.
 
Okay, so I finally tried QNEthernet... and it's running flawlessly since more than 29 hours... Thanks for the hint @shawn... could it be that this is your library?
Anyways thanks to vjmuzik and ssilverman for your great work and efforts.

Really great stuff!
 
@MartyBrown yes, this is my library :) I wrote it because I needed something that didn’t use a timer. Also, I figured that providing a library that used a different underlying stack (I also thought lwIP was simpler) would give people more options and that having several choices would ultimately make both libraries better.

I’ve been keeping QNEthernet up-to-date because I use it in my own projects. Any changes and improvements I make are because I need those changes and improvements. My goal is to make a stellar library independent of what’s already out there. Partly because I wanted to learn how it all works, and partly because I enjoy fine tuning things.

I’m really glad it works well for you. As you use it, please don’t hesitate to file any issues on the GitHub repository. I’m almost at v0.14.0 (latest incarnation of the current snapshot is on GitHub). My wish is to get to v1.0.0 once more people use it.
 
Keep up the good work! I really hope that more people find your library! Perhaps Paul Stoffregen can link your repository on the pjrc-homepage?! Or include it in the Teensyduino installer? ;)
 
Thanks! It’s also accessible from the Arduino library manager, plus via PlatformIO using the GitHub URL. I do think it’s Teensyduino installer-worthy, but that’s up to Paul, I suppose (I haven’t asked).
 
Back
Top