Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unaligned access #17

Closed
dipsie84 opened this issue Dec 22, 2020 · 5 comments
Closed

unaligned access #17

dipsie84 opened this issue Dec 22, 2020 · 5 comments
Labels
help wanted Extra attention is needed

Comments

@dipsie84
Copy link

The line
https://github.com/azure-rtos/netxduo/blob/f66451ca193a96b5734e9a99d6d0ed9de44c9ac5/common/src/nx_tcp_socket_packet_process.c#L109
might trigger an Hard fault because of "Unaligned access to memory" on some processors (eg. STM32H7 family).

Suggested workaround:
memcpy(&tcp_header_copy, packet_ptr -> nx_packet_prepend_ptr, sizeof(tcp_header_copy));

@TiejunMS
Copy link
Contributor

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?

@dipsie84
Copy link
Author

dipsie84 commented Dec 23, 2020

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.

@TiejunMS
Copy link
Contributor

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!

@dipsie84
Copy link
Author

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

@yuxin-azrtos yuxin-azrtos added the help wanted Extra attention is needed label Feb 8, 2021
@stanley-lei
Copy link

@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:
image
But the packet_ptr is kind of messy:
image

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:

image

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants