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

Kernel
1

jcandle wrote on Tuesday, January 02, 2018:

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?

2

rtel wrote on Tuesday, January 02, 2018:

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 configCHECK_FOR_STACK_OVERFLOW
set to 2?

3

jcandle wrote on Tuesday, January 02, 2018:

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.

4

jcandle wrote on Thursday, January 04, 2018:

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/v2_05/third_party/rtos/freertos/source/list.c : 192

_general_exception_handler ( XCPT_FRAME* pXFrame = 0xA5A5A5A5 ) at d:/microchip/harmony/v2_05/apps/tcpip/wifi_winc1500_socket/firmware/src/system_config/pic32mz_ef_aloha/filtering_exception_handler.c : 155

prvAddCurrentTaskToDelayedList( xTicksToDelay, pdFALSE ); in the vTaskDelay() call is throwing it.

5

rtel wrote on Thursday, January 04, 2018:

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

6

jcandle wrote on Thursday, January 04, 2018:

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…

7

jcandle wrote on Friday, January 05, 2018:

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 UBaseType_t 0x8000D414 0x00000002
pxList->xListEnd.pxNext xLIST_ITEM* 0x8000D420 0x80015C1C
pxList->xListEnd.pxNext->pxNext 0x80015C20 0x80016C9C
pxList->xListEnd.pxNext->pxNext->pxNext 0x80016CA0 0x8000D41C

(prvAddCurrentTaskToDelayedList calling vListInsertEnd).
WinC1500_task delays and
pxList->uxNumberOfItems UBaseType_t 0x8000D414 0x00000002
pxList->xListEnd MiniListItem_t 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?

8

rtel wrote on Friday, January 05, 2018:

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.