Quality RTOS & Embedded Software

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


Loading

Solution (?): FreeRTOS+PIC32MZEF-Harmony floating point crash

Posted by andrewgt on February 8, 2019

Recently I encountered a problem with a math and interrupts-intensive application running under FreeRTOS: it appears that at least one thread somehow crash the floating-point processing after some (normally few hours) operation, long double variables, both local and once-written globals, became corrupted on-the-fly. Unfortunately, I have no time to produce a stripped barebone application to reproduce the situation for your reference, but the problem exist for sure. The problem reveals mostly after 4-5 hours of (200 MHz) operation, however, increasing the external hardware baudrate sometimes helps to encounter the crash (unfortunately, not reboot ) in a few munites.

The debugging tools at hand (ICD4, RealIce) hardly helped to locate the error, in particular, the h/w debugger data access breakpoint for some reason don't fire (it fires quite good in initialisation phase, but when someone writing the wrong value - no [BTW, it might be noone writes the wrong values, may be the stack pointer itself points the wrong way?, hardly - neighbouring variables where quite normal]). Stopping and inspecting the suspect variable after the problem reveals at debugging output (to debug I use RS-232 port with my own printf-like routines) confirms the wrong values:

x = y = 2.0; z = x * y; next statement; was quite normal.

I should state that all threads: 1) Are equipped with generous stack (increasing it+doubling the interrupt stack was the first attempt to cure). 2) Call portTASKUSESFLOATING_POINT(); as the first statement (I am afraid that at the end all threads, even not using FPU, do so).

In the meantime I upgraded the entire toolchain to the latest releases: MPLAB-X 5.1, FreeRTOS 10.1.1, XC32 2.15, - no help. Manupulation with interrupt priorities (all h/w interrupts (UARTx, SPIx, CANx, ETH) where initialised to priotiy 1, subprio 1) - no help.

Suspecting a problem wth stack manupulation being done by FreeRTOS scheduler, I came to a solution which, at least, will bear no harm to anybody, but apparentely cures the issue:

I propose to cease using heap allocation for any thread stack, declare stack storage static and align to 8-byte boundary (ISR stack follows this in FreeRTOS source). It is accomplished in the following manner:

StaticTaskt UDPServTCB; attribute ((aligned(8))) StackTypet UDPServSTK[DISIZE]; ...

h = xTaskCreateStatic(UDPServer,"UDPS",DISIZE,NULL,5,UDPServSTK,&UDPServTCB); configASSERT(h);

Yours Andy


Solution (?): FreeRTOS+PIC32MZEF-Harmony floating point crash

Posted by rtel on February 8, 2019

Thanks for the information.

Checking the PIC32MZ port I notice that portBYTE_ALIGNMENT is already set to 8 for the PIC32MZ port, and the alignment is checked with an assert within the kernel code. Could your problem be something to do with where in memory the stack is being placed? Allocating statically would move the stack some way away from the FreeRTOS heap where perhaps the characteristics of the memory is different, or perhaps something that was clobbering the memory now just missing anything vital.


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


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

Latest News

FreeRTOS v10.2.0 is available for immediate download. MIT licensed, and including RISC-V and ARMv8-M (Cortex-M33) demos.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

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

Cadence Tensilica Cortes

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Mediatek

Renesas

RISC-V

SiFIve RISC-V

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