The interrupt handler vEMACInterrupthandler is triggered normally. While in prvEMACHandlerTask, I comment out: vTask_XXX which are not found in FreeRTOS.
//tbd: vTask_init( &xEmacTask, 15 );
//tbd: vTask_finish( &xEmacTask );
/* No events to process now, wait for the next. */
ulTaskNotifyTake( pdFALSE, ulMaxBlockTime );
//tbd: vTask_start( &xEmacTask );
The Cyclone_V_SoC port was developed for JT Electric, who gave the kind permission to make this driver public.
Can you also upload your FreeRTOSConfig.h please? I will study the files and also I will look up the project sources for which I developed the NetworkInterface.
No problem to comment out the calls to vTask_xxx(). These calls calculate how often a tasks becomes active and for how long. It helped us to optimise the driver.
Thanks for the reply. I will look into your files.
I attached more my files
main.c: which is my main file
int main( void )
{
/* Configure the hardware ready to run the demo. /
prvSetupHardware();
/ Start the tasks that implements the command console on the UART, as
described above. /
vUARTCommandConsoleStart( mainUART_COMMAND_CONSOLE_STACK_SIZE, mainUART_COMMAND_CONSOLE_TASK_PRIORITY );
/ Register the standard CLI commands. */
vRegisterSampleCLICommands(); #ifdef FREERTOS_TCP
/*Initialise the internet interface /
start_tcp(); #endif
/ Start the scheduler. */
vTaskStartScheduler();
for( ;; );
}
Two new files eventLogging.h/UDPLoggingPrintf.h which simply call uart0_prinf (I also tried to set the macro to empty, which doesn’t help)
main.c which is copied from FreeRTOS release FreeRTOS-Plus\Demo\FreeRTOS_Plus_TCP_Minimal_Windows_Simulator\main.c and change main to start_tcp which is called from my main.c
One change I would recommend.
Create in FreeRTOSIPConfig.h: #define ipconfigUSEC_TO_TICKS ( 1000000 / configTICK_RATE_HZ )
Then, in cyclone_phy.c, modify the 3 timeout wait loops to divide by the new definition.
Tout=PHY_LINKUP_TO/ipconfigUSEC_TO_TICKS
Tout=PHY_AUTON_TO/ipconfigUSEC_TO_TICKS
This will scale the time correctly to the defined tick rate.
Hi Manny, thanks a lot for reporting this. You are right that the comments do not correspond with actual behaviour.
The code is waiting 2 ticks in stead of 10 µS:
/* Wait 10 uS. */
vTaskDelay( 2 );
This PHY driver was originally developed by Altera ( Intel ).
I propose to change the time-out definitions to use milliseconds and get the extension _MS:
#define PHY_READ_TO_MS ( 100U ) /* Max wait time (ms) when reading from PHY */
#define PHY_WRITE_TO_MS ( 100U ) /* Max wait time (ms) when reading from PHY */
#define PHY_LINKUP_TO_MS ( 5000U ) /* Max wait time (ms) for link to come up */
#define PHY_AUTON_TO_MS ( 15000U ) /* Max wait time (ms) for auto-ng to succeed*/
( the first 2 macro’s don’t seem to be used. )
And change the loops accordingly:
for( Tout = pdMS_TO_TICKS(PHY_AUTON_TO_MS) ; Tout>0 ; Tout-- )
{
if (gmac_mdio_read( iMacID, iPHYAddress, PHY_BSR_REG) & PHY_AUTO_NEGOTIATION_COMPLETE) {
break; /* Wait for auto-negotiation to complete */
}
/* Wait 1 clock-tick. */
vTaskDelay( 1U );
}
I guess you know that vTaskDelay(1) will wait at most 1 clock-tick, depending on the moment on which it is called.
However, in a loop, in which vTaskDelay(1) is called hundreds of times, the actual delay will get close to one clock-tick.
I am running into a problem.
I managed to get the ethernet up and running using the CycloneV code discussed in this thread, but when the first ARP request comes in, the processor will eventually crash with a data abort error when entering vARPGenerateRequestPacket() in FreeRTOS_ARP.c and trying to execute the memcpy() functions.
I have played around with changing these calls an have verified that it is due to a memory alignment issue on pxARPPacket.
I assume that no one has had to modify this function call, so I am wondering if you ran across this issue in your work and what can be done to correct it.
I am running FreeRTOS v10.2.1, compiling with arm-none-eabi-gcc-8.3.1-1.4. I have the compile setting unaligned-access enabled, but understand that the memcpy function in the library may not be compiled for unaligned access.
P.S. Your delay suggestion does look cleaner. I will give that a try when I get a chance.
FreeRTOS v10.2.1 already has the memcpy for ucSenderProtocolAddress you mentioned.
The crashes were occurring on the following 2 lines: memcpy( ( void * ) pxARPPacket, ( void * ) xDefaultPartARPPacketHeader, sizeof( xDefaultPartARPPacketHeader ) ); memcpy( ( void* )pxARPPacket->xARPHeader.ucSenderProtocolAddress, ( void* )ipLOCAL_IP_ADDRESS_POINTER, sizeof( pxARPPacket->xARPHeader.ucSenderProtocolAddress ) );
Checking the assembler listing, you were correct that the branch to memcpy did not exist in the assembler code. This seems to be primarly due to the output parameter not being 32-bit aligned.
Adding -fno-builtin-memcpy -fno-builtin-memset fixed this problem and vARPGenerateRequestPacket works properly now.
Unfortunately, my ethernet connection is still not working yet, so I have more debugging to do. Hopefully, my next post will be something more successful.
I have one last update.
Hein generously provided me his Cyclone TCP test code and my results were exactly the same as I was getting with my code. The Cyclone would successfully negotiate a link but would never actually communicate any data on the bus (i.e. No traffic as seen from Wireshark).
I have since switched to the Xilinx Zync 7000 SOC, an equivlent chip, and my results have been far better. I was able to get my ethernet up and running with minimal effort on this one and will probably use this chip in my products instead.
Hello colleagues. Did anyone manage to run TCP on Cyclone V. Or is there a project that can be completed? Can someone share an example of a project that works?
