hard fault on _nx_tcp_socket_packet_process about netxduo HOT 6 CLOSED

the last few packets look like:

88	16.902087	192.168.1.1	192.168.1.146	DNS	156	Standard query response 0xb7ff A testhubti.azure-devices.net CNAME ihsu-eastus-2.eastus.cloudapp.azure.com A 20.49.109.129
89	16.903396	192.168.1.146	20.49.109.129	TCP	62	54335 → 8883 [SYN] Seq=0 Win=8192 Len=0 MSS=1460
90	16.947130	20.49.109.129	192.168.1.146	TCP	60	8883 → 54335 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1440

after this I just get a retransmission, I assume because of the failure

No.	Time	Source	Destination	Protocol	Length	Info
99	19.950324	20.49.109.129	192.168.1.146	TCP	60	[TCP Retransmission] 8883 → 54335 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1440

from netxduo.

a bit more information. I was able to correct the hard fault issue by doing this:

    /* Copy the TCP header, since the actual packet can be delivered to
       a waiting socket/thread during this routine and before we are done
       using the header.  */
    /*lint -e{927} -e{826} suppress cast of pointer to pointer, since it is necessary  */

//    tcp_header_copy =  *((NX_TCP_HEADER *)packet_ptr -> nx_packet_prepend_ptr);
    memcpy((void *)&tcp_header_copy, (void *)packet_ptr -> nx_packet_prepend_ptr, sizeof(NX_TCP_HEADER));

not sure this is a good long term solution but after this modification everything seems to work and the device fully registers with Azure and I am receiving telemetering temperature info.
Any more insight?

from netxduo.

Could you check the value of packet_ptr -> nx_packet_prepend_ptr? It is required to be 4 bytes aligned for IP header. From your last description, it looks like the fix is related to unaligned access.

from netxduo.

Thank you for the help. Yes, it looks like that is the issue.
Even though this is an M4F which I understand supports unaligned access (if the SCB_CCR_UNALIGN_TRP_Msk bit in the SBC->CCR register is clear ... which it is) it is still faulting.
I can see the nx_prepend_ptr is at 0x200037d6 which is indeed in RAM space but not 4 byte aligned.
So what is the answer? do all the buffer allocations need to be fixed up so prepend_ptr end up 4 byte aligned? how do you do that?

from netxduo.

Hi @dvescovi1 - typically, we use the hardware features of the MAC to insert two bytes of padding between the 14-byte MAC header and the payload. This aligns the payload on a 4-byte boundary.

from netxduo.

Feel free to reopen the issue if you have further questions.

from netxduo.