Hi, There is a bug in eARPProcessPacket() in FreeRTOS_ARP.c. In FreeRTOS v10.1.1 it is on line 117: ~~~ memcpy( ( void *)&( ulSenderProtocolAddress ), ( void * )pxARPHeader->ucSenderProtocolAddress, sizeof( ulSenderProtocolAddress ) ); ~~~ …which should be… ~~~ memcpy( ( void *)&( ulSenderProtocolAddress ), ( void * )&pxARPHeader->ucSenderProtocolAddress, sizeof( ulSenderProtocolAddress ) ); ~~~ For a while I thought the resulting exception was due to alignment. This has been around for the previous two FreeRTOS versions at least, but I’ve only now got around to pointing it out. Cheers, Murray

Hi Murray, thanks for reporting, but you haven’t convinced me yet. The field ucSenderProtocolAddress[ 4 ] is an array of bytes. In earlier versions of +TCP, this field was called uint32_t ulSenderProtocolAddress. The problem was that this field is only 2-byte aligned. On most platforms, access to an uint32_t must be 32-bit aligned. Note that there are 4 occurrences of ucSenderProtocolAddressin FreeRTOS_ARP.c, and none of them has an ampersand to take the address of the array.

Oops – I beg your pardon. I discovered that bug in the FreeRTOS Labs some time ago in my journey to get my STM32F4 Discovery board working with all the FreeRTOS Plus goodies. It took me a while to realise that the program was sitting in a tight loop in a fault handler. I’m actually grateful to it for forcing me to learn to make fuller use of GDB. Since then I’ve been adding those ampersands to the FreeRTOS releases, not noticing the change from pxARPHeader->ulSenderProtocolAddress to pxARPHeader->ucSenderProtocolAddress . Another lesson for me in the difference between fact and belief! Thanks, Murray