wire shark, but I have no experience with it
Just start it up and make sure that you choose the correct ( LAN ) adapter.
Here is an example of 3 types of ARP messages:
Note the filter on the top, I filled in the protocol name “arp”.
The big question is: can you device send and can it receive packets? The first thing to check is the PHY Link Status: does it get up?
I did notice one thing though, there is no phyHandling.h/.c in your or the Amazon repo.
You find the latest in my Github repo: phyHandling.c and phyHandling.h
This PHY handler can be used for any 100 Mbps PHY on any platform.
I’m using one that I found somewhere but could the problem be in this file?
There could be a small extension but nothing essential.
there were two compilation errors for missing declarations from
xApplicationGetRandomNumber()
Yes, please look at PR #1494. The global function ulRand32()
returns zero when it fails. But zero is a valid random number.
This is the implementation that I used for the STM32Fx platform:
BaseType_t xApplicationGetRandomNumber( uint32_t *pulValue )
{
HAL_StatusTypeDef xResult;
BaseType_t xReturn;
uint32_t ulValue;
xResult = HAL_RNG_GenerateRandomNumber( &hrng, &ulValue );
if( xResult == HAL_OK )
{
xReturn = pdPASS;
*pulValue = ulValue;
}
else
{
xReturn = pdFAIL;
}
return xReturn;
}
and
xCheckLoopback()
That is an idea that hasn’t made it to becoming a pull-request yet: it adds a “loop-back device”. If the target IP address is the address of the adapter, the packet will be bounced back to the IP-task. Good for self-testing without physical network.
You see it implemented in FreeRTOS_ARP.c but the code is disabled with a #if 0
.