PIC32MZ Harmony 2.05 wifi_winc1500_socket on custom board,,, TLB exception in xTaskIncrementTick( void )

I am sure this is not a FreeRTOS issue, per se, but I am hoping someone here can shed some light on it. Harmony is creating SYSTasks, SYSTMRTasks, and my APPTasks. APPTasks starts winc1500task(void arg) and the init for it uses a couple vTaskDelay() calls. At the end of the 100 tick delay, I was getting an unhandled exception on: xItemValue = listGETLISTITEMVALUE( &(** pxTCB**->xStateListItem ) ); Adding simple tlbrefillexceptionhandler(void) identified the exception was “TLB” and some reading suggested it was really dereferencing an invalid pointer. Optimization (previously pointed out by the FreeRTOS authors for a related issue) was showing a “value” for pxTCB. Removing optimizations shows NULL pointers to TCD for two fo the four items on the pxDelayedTaskList list. http://www.microchip.com/forums/m1031801.aspx has more history and a word file with screen shots as the vTaskDelay was about to expire. I am not sure where to look next. It looks like tasks are taken off the delayed list whether their time is up or not?

PIC32MZ Harmony 2.05 wifi_winc1500_socket on custom board,,, TLB exception in xTaskIncrementTick( void )

Could this just be memory corruption – in that something is writing over the kernel’s data structures? Or maybe a task is overflowing its stack. Do you have configASSERT() and configCHECKFORSTACK_OVERFLOW set to 2?

PIC32MZ Harmony 2.05 wifi_winc1500_socket on custom board,,, TLB exception in xTaskIncrementTick( void )

yes. I have to assume it is an overwrite and specifically assume a Harmony flaw in trying to change the default project to my board. In 7 years I have not had an issue in your code that wasn’t “me”… This time it is code I ddin’t write. I have plenty of RAM, so i could make the stacks stupidly big for now. I think MPLabx supports breakpoint on memory access… time to see if it does and how to use it. Am I correct in reading the code as taking all tasks off the delayed list and placing them on the ready list?? Looks like it does that even if their time is not up, until the delayed list is empty.

PIC32MZ Harmony 2.05 wifi_winc1500_socket on custom board,,, TLB exception in xTaskIncrementTick( void )

so I prevented the WINC1500 task from running and attempted to perform the chip select and vTaskDelay sequence in another task… Runtime exception @ PC address 0x9d0367c8 in function: vListInsert ( ) at d:/microchip/harmony/v205/thirdparty/rtos/freertos/source/list.c : 192 generalexceptionhandler ( XCPTFRAME* pXFrame = 0xA5A5A5A5 ) at d:/microchip/harmony/v205/apps/tcpip/wifiwinc1500socket/firmware/src/systemconfig/pic32mzefaloha/filteringexceptionhandler.c : 155 prvAddCurrentTaskToDelayedList( xTicksToDelay, pdFALSE ); in the vTaskDelay() call is throwing it.

PIC32MZ Harmony 2.05 wifi_winc1500_socket on custom board,,, TLB exception in xTaskIncrementTick( void )

0xA5A5A5A5 is the value used to fill the task stack when the task is created. Looks like something has popped an invalid stack item.

PIC32MZ Harmony 2.05 wifi_winc1500_socket on custom board,,, TLB exception in xTaskIncrementTick( void )

If I completely remove winc1500 driver calls and perform the same gpio and task delay in the app task, no issues. Looks like a Microchip support ticket…

PIC32MZ Harmony 2.05 wifi_winc1500_socket on custom board,,, TLB exception in xTaskIncrementTick( void )

the pointers in the delayed task list are getting corrupted the first time that winc1500_task delays… SysTasks delays and is the only item on the list… Harmony TMRTasks delays and the pointers look right. IE next:next is valid pxList->uxNumberOfItems UBaseTypet 0x8000D414 0x00000002 pxList->xListEnd.pxNext xLISTITEM* 0x8000D420 0x80015C1C
pxList->xListEnd.pxNext->pxNext 0x80015C20 0x80016C9C
pxList->xListEnd.pxNext->pxNext->pxNext 0x80016CA0 0x8000D41C (prvAddCurrentTaskToDelayedList calling vListInsertEnd). WinC1500task delays and pxList->uxNumberOfItems UBaseTypet 0x8000D414 0x00000002 pxList->xListEnd MiniListItemt 0x8000D41C
pxList->xListEnd.pxNext xLIST
ITEM* 0x8000D420 0x80015C1C
pxList->xListEnd.pxNext->pxNext 0x80015C20 0x00000002 Any ideas where to trace to find why/where the pointer to next from SysTasks is corrupted?

PIC32MZ Harmony 2.05 wifi_winc1500_socket on custom board,,, TLB exception in xTaskIncrementTick( void )

If the WinC1500 task is just calling vTaskDelay() then the function call itself will not use much stack, but the task context will also get saved to the stack – and on a PIC32 the context is quite large. Who creates the WinC1500 task, and when it is created, how is its stack allocated. If the stack is allocated dynamically, is there a check to ensure the stack was allocated correctly? If the allocation fails completely the task just wouldn’t get created.