Thank you very much. it compiled! Just a last question: is there a way to set the MAC address directly from the xNetworkInterfaceInitialise function of the interface?
Moreover: I tried to run it, but I get an assert on FreeRTOS_IP.c:
ssert failed in file …/src/FreeRTOS-Plus-TCP/FreeRTOS_IP.c, line 1243
Do I have to take care of some specific configuration?
Is it this assert - FreeRTOS-Plus-TCP/FreeRTOS_IP.c at main · FreeRTOS/FreeRTOS-Plus-TCP · GitHub
Can you check whether xSize is wrong or ipconfigBUFFER_PADDING?
It seems to be ipcobfig_BUFFER_PADDING the trouble. Looking deeper I found it is set to 0 (default).
What is the value of xSize. If it is 8, you can set ipconfigBUFFER_PADDING to 14 in your FreeRTOSIPConfig.h.
Yes, xSize is 8, setting it that way solved that problem.
Is there a way to set the MAC address directly from the xNetworkInterfaceInitialise function of the interface?
Yes, that should be possible. Here is an example - https://github.com/FreeRTOS/FreeRTOS-Plus-TCP/blob/main/portable/NetworkInterface/esp32/NetworkInterface.c#L58
Thanks,
I’m debugging the interface since I get an error in the deferredRXHandleTask that I realized following this guide that you suggested before.
However, when I call the xSendEventStructToIPTask I get an assert: Assert failed in file port.c, line 522
This is a snipped of code of such task:
static void defferredRxHandlerTask(void *pvParameters){
int r;
unsigned char tmp[1539];
u32 bytes = 0;
u16 pktBytes;
NetworkBufferDescriptor_t *pxBufferDescriptor; //Pointer to a network buffer descriptor
/* Used to indicate that xSendEventStructToIPTask() is being called because
of an Ethernet receive event. */
IPStackEvent_t xRxEvent;
const TickType_t xBlockTime = pdMS_TO_TICKS( 100UL );
for( ;; ){
// Wait for an interrupt notification to resume looking for packets to receive
ulTaskNotifyTake(pdFALSE, portMAX_DELAY);
// Receive all the packets in the RX queue
do{
r = get_next_packet_size(&pktBytes, &rxBuf); // Get size of next packet to receive
if(r == FALSE){
break; // No packets to receive
}
/*
* Allocate a network buffer descriptor.
* The second parameter (0) specifies that if no descriptor available, the function will return immediately
*/
pxBufferDescriptor = pxGetNetworkBufferWithDescriptor(pktBytes, xBlockTime);
if(pxBufferDescriptor == NULL){
// No network buffer descriptors available, track this event
iptraceETHERNET_RX_EVENT_LOST();
break;
}
r = copyData((unsigned char *)pxBufferDescriptor->pucEthernetBuffer, (uint16_t)&pxBufferDescriptor->xDataLength); //retrieve packet
if(r == TRUE){
// Check if the received data needs to be processed
if(eConsiderFrameForProcessing(pxBufferDescriptor->pucEthernetBuffer) == eProcessBuffer){
//Frame needs to be processed
xRxEvent.eEventType = eNetworkRxEvent; // It's an RX event
xRxEvent.pvData = (void *) pxBufferDescriptor; // Pointer to the RX buffer descriptor
// Send data to TCP/IP stack
if(xSendEventStructToIPTask(&xRxEvent, xBlockTime) == pdFALSE){
// Buffer could not be sent to the IP stack
vReleaseNetworkBufferAndDescriptor(pxBufferDescriptor); // Release buffer descriptor
iptraceETHERNET_RX_EVENT_LOST(); // Trace this event
break;
}else{
// Message successfully forwarded
iptraceNETWORK_INTERFACE_RECEIVE(); // Trace this event
}
}
}
}while(r == TRUE);
}
}
What I’m wrong? I have followed all the instructions
It looks like you declare a large stack variable “tmp” but don’t use it.
Also, it doesn’t look like you free the network buffer if eConsiderFrameForProcessing() returns anything other than eProcessBuffer.
Please link to the port.c file line 522 in github so I can see which assert fails. If you go to the source file (like this, source file chosen at random FreeRTOS/FreeRTOSConfig.h at main · FreeRTOS/FreeRTOS · GitHub) you can click the line number then past the resultant URL into your post.
Thanks for the hints about the variable, I forgot it there.
I searched deeply online on github, but I cannot find the port.c file that is included in my BSP (is generated by the Xilinx SDK 2019.1), I’m attaching here the port.c file
port.c (24.2 KB)
From what I can see from the debugger what happens is the following:
- my task calls the xSendEventStructToIPTask with the packet received
- such function calls xQueueSendToBack()
- such function enters in a critical section and calls taskENTER_CRITICAL()
- this function calls the vPortEnterCritical() function defined in port.c and the above mentioned assert is triggered.
There are lots of asserts in the code - please at least post the code in the forum so we can see which assert is hit. That will give us context.
Thanks barry, the assert is the one at row 522 of the file I posted in my previous post.
However, here is the code of the mentioned function in port.c:
void vPortEnterCritical( void )
{
/* Mask interrupts up to the max syscall interrupt priority. */
uxPortSetInterruptMask();
/* Now interrupts are disabled ullCriticalNesting can be accessed
directly. Increment ullCriticalNesting to keep a count of how many times
portENTER_CRITICAL() has been called. */
ullCriticalNesting++;
/* This is not the interrupt safe version of the enter critical function so
assert() if it is being called from an interrupt context. Only API
functions that end in "FromISR" can be used in an interrupt. Only assert if
the critical nesting count is 1 to protect against recursive calls if the
assert function also uses a critical section. */
if( ullCriticalNesting == 1ULL )
{
configASSERT( ullPortInterruptNesting == 0 );
}
}
So either ullPortInterruptNesting has been corrupted (overwritten), or your code is calling an API function that doesn’t end in “FromISR” from an interrupt service routine. FreeRTOS FAQ - FreeRTOS API - FreeRTOS - maybe its the xQueueSendToBack() mentioned in a previous post. If that is in an ISR it should call xQueueSendToBackFromISR() (or xQueueSendFromISR()).
What could be the reasons for which the ullPortInterruptNesting could be corrupted?
The function is not called from an ISR since the root of the nested function calls ending in vPortEnterCritical starts from my task (which is unlocked using a notification by the interrupt on packet reception).