Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

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

Posted by jcandle on January 2, 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?


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

Posted by rtel on January 2, 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 configCHECKFORSTACK_OVERFLOW set to 2?

Attachments


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

Posted by jcandle on January 2, 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.

Attachments


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

Posted by jcandle on January 4, 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/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.

Attachments


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

Posted by rtel on January 4, 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.

Attachments


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

Posted by jcandle on January 4, 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...

Attachments


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

Posted by jcandle on January 5, 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 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 xLISTITEM* 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?

Attachments


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

Posted by rtel on January 5, 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.

Attachments


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner