pxCurrentTCB should ALWAYS be pointing to a Task Control Block (never “a stack”). If you use xTaskCreate to make those tasks, they will be allocated in the heap. If you use xTaskCreateStatic (and have enabled static task creation) they will be allocated in the memory that was given, which should be out of “global” memory.
The only way it could point to the “stack” is if you created with xTaskCreateStatic but gave it a memory block from the current function’s stack, which isn’t a good idea, as that memory “goes away” when the function returns, and for the “main” function, many ports reuse the main stack for the ISR stack.
yeah i got your point but as i told you earlier this microprocessor is new one. so, there is no debugger in it.
one more thing, I have put two prints in ethernet send function, one print in prvRegTestTaskEntry3 and one print in vHandlingTask using vSendString api.
void
vHandlingTask (void *pvParameters)
{
//uint32_t ulInterruptStatus = 0;
for (;;)
{
// Wait for notification from ISR (similar to binary semaphore)
vSendString("hands\n\r");
ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
taskENTER_CRITICAL();
prvReceivePacket (NULL, 0);
GPIO_read_pin(7);
taskEXIT_CRITICAL();
//vTaskDelay(50);
}
}
static void
prvRegTestTaskEntry3 (void *pvParameters)
{
xPingReplyQueue = xQueueCreate(10, sizeof(unsigned long));
/*Although the regtest task is written in assembler, its entry point is
written in C for convenience of checking the task parameter is being passed
in correctly.*/
while (1)
{
vSendString("ping\n\r");
vSendPing ("10.176.19.138"); // for dynamic(ipconfigUSE_DHCP=1)
vTaskDelay (100);
/*The following line will only execute if the task parameter is found to
be incorrect. The check task will detect that the regtest loop counter is
not being incremented and flag an error.*/
}
vTaskDelete ( NULL);
}
like above two prints in sending function of ethernet, first at the starting (which is sends) and second at the last (sendl). after this program is working fine so, is there a problem related to delay or something??
If putting prints is resolving your problem, then it is likely that you are just hiding the symptom and the real issue is still there. Any fix without understanding the root cause can not be reliable.
yeah, you are right…can you tell me? how can i check the heap usage in my program.
and where can i check the size of TCB also? so that i can make sure that problem is related to stack size,heap size or not.
Note that you can still get stack overflows even though the overflow hook does not report it. The safest way to positively exclude application stack overflows is to record beginning and size of each task stack when creating your tasks and then look at those memory blocks manually postmortem. printf() and its cousins are notorious stack hogs, so if your app crashes with them and does not without them, it is an indication of a stack overflow. The other option, of course is a formatting error such as “%s” passing in a memory location that is not a string.
hiii…sorry for the late reply…I have checked the free bytes remaining in heap by using xPortGetFreeHeapSize() api so according to this everytime i am getting same value it means memory leakage is not happening.
I also check the amount of stack which is unused in stack by using uxTaskGetStackHighWaterMark function. still there is no indication of stack overflow i have seen value is not even close to zero.
and right now i have decreased the heap size and stack size of task(heap size is 45 *1024 and stack size of all three tasks are 2048), some changes i have done in my external interrupt.
void
vHandlingTask (void *pvParameters)
{
//uint32_t ulInterruptStatus = 0;
while(1)
{
// Wait for notification from ISR (similar to binary semaphore)
ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
//taskENTER_CRITICAL();
GPIO_read_pin(7);
//taskEXIT_CRITICAL();
}
}
/* ISR */
void
EXTI2_IRQHandler (void)
{
GPIO_write_pin (7, 0);
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
if (xTimerPendFunctionCallFromISR( prvReceivePacket,
NULL,
0,
&xHigherPriorityTaskWoken ) == pdFALSE) {
vSendString("PANIC: enc28j60: daemon's queue full\n");
while(1);
}
vTaskNotifyGiveFromISR(pxCreatedTaskISR, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
/* If xHigherPriorityTaskWoken is now set to pdTRUE then a context switch
should be performed to ensure the interrupt returns directly to the highest
priority task. The macro used for this purpose is dependent on the port in
use and may be called portEND_SWITCHING_ISR(). */
}
this time program is running for almost 1 hr but after it would stuck or SHOWING trap
on that TRAP condition i am still working on it.
BTW is there any way to make this ethernet implementation with freeRTOS only not with FreeRTOS plus. if yes then is that reliable?? please share your views…
Right now i am using FreeRTOS plus TCP library for this project. so is it possible to implement the same project by using simple FreeRTOS only.
FreeRTOS plus TCP have additional features, so can i do that with the simple freertos library??
FreeRTOS kernel is a scheduler which provides you multi threading. FreeRTOS-Plus-TCP is a TCP stack. Those two are very different and what you need depends on your need. Do you want a TCP stack? If not, you can just use FreeRTOS kernel.