I am seeing a Random NX_ASSERT occurring in nx_ip_header_add.c (SSP 1.7.8, File version 5.12 using netx Duo and netx mqtt) on line 140. It appears to be failing some packet pointer check. This assert spins in sleep forever and it has the IP stack protection mutex, so everything network related ultimately gets hung up.You can see in the attached TraceX screenshot that the mqtt publisher thread starts sending up through "SS" (Socket Send) and is then interrupted by the Ethernet Receive IRQ, which process a receive packet and causes some form of return packet to be sent (I guess but don't know for sure that this is a MQTT keep alive?); following this MQTT Publisher starts running again, and you can see at time just after 270730, a DS (Data Send) call by the MQTT publish thread and then it goes TZ (thread sleep) due to the NX_ASSERT failure. As can be seen by this call stack in the debugger: slack-files.com/TVANCBVPX-F01KS9H0VSL-3411a429b4
Has anyone else ever seen this, or have any ideas how to address/further debug this?
Thank You, Josh Patterson
let us know if you still have questions. I will mark this as solved for now. Feel free to reopen the post if you still need some answers.
So interestingly this behavior seems to be associated with a broker setting limiting max_inflight_packets to 1. If I bump that up to even 2 it stops hanging. Its unclear to me why these two things should be at all related!!
Hi Josh P-
Yes, this is a bit difficult to understand. Perhaps there is a timing issue when only one inflight packet is allowed...
When you bump max_inflight_packets to 2, what difference in execution do you see from the version with it set to 1? Do you still get the Ethernet IRQ and the packet reply sent, etc?
So definitely not solved. The max inflight thing is just a red hearing the adjusts the frequency of the failure.
Does the netx packet pool cross the SRAM boundary at 0x20000000? You could try turning off unaligned access and built in memcpy ( -mno-unaligned-access for the project (gcc.gnu.org/.../ARM-Options.html. To stop the use of the built in memcpy specify -fno-builtin or -fno-builtin-memcpy) add the memcpy code from this project (src\memcpy-armv7m.S). This causes memcpy to be built from source so it does aligned accesses to memory.
Good timing, this is what we are looking into right now, There is testing underway with that file and no builtin memcp. I will update once I have some results.
So we added the memcpy to the project and are now using no builtin-memcpy flag, but we are still seeing this.
Any update on this? Do you already have a solution? If not, what are your current issues?
One more try to see if you still have an issue. If we don't hear back we will assume Jeremy's post pointed you in the right direction.