unaligned access about netxduo HOT 5 CLOSED

Hi @dipsie84 . The address of nx_packet_prepend_ptr is required to be 4 bytes aligned for both IP and TCP header. Did you encounter real issue for unaligned access?

from netxduo.

Yes. I ported the "getting started" example from B-L475E-IOT01A to NUCLEO-H723ZG board.
Basically I've switched cortex_m4 ports to cortex_m7 and replaced wifi networking with onboard Ethernet.

Connection to Azure IoT Hub fails with Hard fault on that line since nx_packet_prepend_ptr is 2B- aligned but not 4B-.
Replacing with memcpy() solves the connection issue.

from netxduo.

There might be something not configured correctly. Please check the followings.

1. Assume you are using NetXDuo but not NetX. Please double check. If you are using NetX, please check the starting address of pool_area used to create packet pool. It needs to be 4 bytes aligned. Skip this if you are using NetXDuo.
2. The driver is responsible to align the incoming IP header to ULONG boundary. See https://docs.microsoft.com/en-us/azure/rtos/netx-duo/chapter5#driver-input. For an Ethernet driver, the size of Ethernet header is 14. So a common solution is to set the RX BD with nx_packet_data_start + 2 for incoming data. See https://github.com/STMicroelectronics/x-cube-azrtos-h7/blob/33d13302a3d58ec4c86091a6e81185996f3f75c8/Middlewares/ST/netxduo/common/drivers/nx_stm32_eth_driver.c#L1754

If the problem still exists, could you please dump the memory between nx_packet_data_start and nx_packet_prepend_ptr when the system crashes. Thanks!

from netxduo.

Ok, I missed the nx_packet_data_start + 2 instruction.
After adding that in the driver the system doesn't crash anymore.
Thanks!

from netxduo.

@TiejunMS @yuxin-azrtos

I got some weird issue when I tried to port the netxduo service to my STM32H743 reference board: the NX driver failed to process the ARP message correctly.
When the APR message is received, I can see it's saved into memory 0x3004024A:

But the packet_ptr is kind of messy:

You can see the nx_packet_prepend_ptr is set as 0x30040248, but it should be already set to 4A when it's allocated (The above screen shot is taken in the function call _nx_driver_transfer_to_netx(). Because of the 2-byte offset, the packet is invalid and released. I manually added 2 in this function, but when NX is trying to send back packet, the system crashes at "SCB_CleanDCache_by_Addr((uint32_t*)(pktIdx -> nx_packet_data_start), pktIdx -> nx_packet_data_end - pktIdx -> nx_packet_data_start);" in function "_nx_driver_hardware_packet_send". I did some check, and found the nx_packet_end in all packets was set to 0 as below:

And the field "nx_packet_next" of the last valid packet is set to some invalid address.

Do you have any idea about this issue?

from netxduo.