This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hello,
I am building an application using C++ and C++ wrapped FreeRTOS. Everything is working fine, however after some time of execution MCU is going into dabort routine (rarely prefetch abort). I successfully tracked which task is creating problems, disabled it and the rest is working just fine. The problem is that this task needs to work, because its functionality is the core of my application - it is microsecond task scheduler. I don't know why the task is failing after some time, I observed the stack growth and for all tasks it remains the same from beginning of execution to the end. I am not using dynamic allocation, everything is statically allocated. I am tracking bugs using SEGGER Ozone - please find attached register dumps after various aborts.
I will be grateful for any hints in bug tracking.
Greetings,
Bartosz
Ozone_Registers_1_Dabort.csvOzone_Registers_1_Dabort2.csvOzone_Registers_1_Dabort_Alignment.csvOzone_Registers_1_Dabort3.csvOzone_Registers_1_Prefetch.csv
Hi,
From the registers' value, the status and fault address for each data abort is different. The ECC values for all of the ATCM program memory space (flash banks 0 and bank 1) must be programmed into the flash before SECDED is enabled. This cab be done by using the linker script.
https://software-dl.ti.com/hercules/hercules_docs/latest/hercules/How_to_Guides/index.html
I've changed my sys_link.cmd file according to the example, it didn't help - I have got another two examples of prefetch and data abort. What is interesting is that sometimes MCU falls into _c_int00 for a few times and then data abort happens. Please find my sys_link.cmd and two register dumps attached.
Ozone_Registers_1_220819_Dabort.csvOzone_Registers_1_220819_PrefetchAbort.csv
/*----------------------------------------------------------------------------*/ /* sys_link.cmd */ /* */ /* * Copyright (C) 2009-2018 Texas Instruments Incorporated - www.ti.com * * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the * distribution. * * Neither the name of Texas Instruments Incorporated nor the names of * its contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * */ /* */ /*----------------------------------------------------------------------------*/ /* USER CODE BEGIN (0) */ /* USER CODE END */ /*----------------------------------------------------------------------------*/ /* Linker Settings */ --retain="*(.intvecs)" /* USER CODE BEGIN (1) */ /* USER CODE END */ /*----------------------------------------------------------------------------*/ /* Memory Map */ MEMORY { VECTORS (X) : origin=0x00000000 length=0x00000020 fill=0xFFFFFFFF KERNEL (RX) : origin=0x00000020 length=0x00008000 vfill=0xFFFFFFFF FLASH0 (RX) : origin=0x00008020 length=0x00177FE0 vfill=0xFFFFFFFF FLASH1 (RX) : origin=0x00180000 length=0x00180000 vfill=0xFFFFFFFF STACKS (RW) : origin=0x08000000 length=0x00002000 KRAM (RW) : origin=0x08002000 length=0x00000800 SHAREDRAM (RW) : origin=0x0803C000 length=0x00004000 RAM (RW) : origin=(0x08000000+0x00002000+0x00000800) length=(0x00040000-0x00004000-0x00000800-0x00002000) /* USER CODE BEGIN (2) */ /* Bank 0 ECC */ ECC_VEC (R) : origin=(0xF0400000 + (start(VECTORS) >> 3)) length=(size(VECTORS) >> 3) ECC={algorithm=algoL2R4F021, input_range=VECTORS} ECC_KER (R) : origin=(0xF0400000 + (start(KERNEL) >> 3)) length=(size(KERNEL) >> 3) ECC={algorithm=algoL2R4F021, input_range=KERNEL} ECC_FLA0 (R) : origin=(0xF0400000 + (start(FLASH0) >> 3)) length=(size(FLASH0) >> 3) ECC={algorithm=algoL2R4F021, input_range=FLASH0 } /* Bank 1 ECC */ ECC_FLA1 (R) : origin=(0xF0400000 + (start(FLASH1) >> 3)) length=(size(FLASH1) >> 3) ECC={algorithm=algoL2R4F021, input_range=FLASH1 } /* USER CODE END */ } /* USER CODE BEGIN (3) */ ECC { algoL2R4F021 : address_mask = 0xFFFFFFF8 hamming_mask = R4 parity_mask = 0x0C mirroring = F021 } /* USER CODE END */ /*----------------------------------------------------------------------------*/ /* Section Configuration */ SECTIONS { .intvecs : {} > VECTORS /* FreeRTOS Kernel in protected region of Flash */ .kernelTEXT : {} > KERNEL .cinit : {} > KERNEL .pinit : {} > KERNEL /* Rest of code to user mode flash region */ .text : {} > FLASH0 | FLASH1 .const : {} > FLASH0 | FLASH1 /* FreeRTOS Kernel data in protected region of RAM */ .kernelBSS : {} > KRAM .kernelHEAP : {} > RAM .bss : {} > RAM .data : {} > RAM .sysmem : {} > RAM .sharedram : {} > SHAREDRAM .preinit_array : {} > FLASH0 | FLASH1 .init_array : {} > FLASH0 | FLASH1 .fini_array : {} > FLASH0 | FLASH1 FEE_TEXT_SECTION : {} > FLASH0 | FLASH1 FEE_CONST_SECTION : {} > FLASH0 | FLASH1 FEE_DATA_SECTION : {} > RAM /* USER CODE BEGIN (4) */ /* USER CODE END */ } /* USER CODE BEGIN (5) */ /* USER CODE END */ /*----------------------------------------------------------------------------*/ /* Misc */ /* USER CODE BEGIN (6) */ /* USER CODE END */ /*----------------------------------------------------------------------------*/
I forgot to mention that the ECC generation should be turned on. Otherwise the ECC will not be generated.
CCS project property --> Build --> ARM Linker --> Advance Options --> Linker Output
In the Linker Output panel, select "on" for "Control whether ECC generation is on or off"
When loading the code, please uncheck the "Auto ECC Generation"
Hi,
I am not using CCS for development, but I've added --ecc=on flag for linker and now I can see that ECC regions are indeed flashed.The problem is still present, but behavior is totally different - program works for 34 seconds and then resets (debugger is stopping on _c_int00), after releasing from breakpoint it works for 34 seconds and resets, and so on. Is there anything I can share with you to help me resolve this issue?
The STC generates a CPU reset after completion of CPU self-test or STC self-check. Are you performing CPU self-test and STC self-check?
Do you enable the watchdog? The PLL slip or oscillator failure can also trigger the device reset.
Hi,
I am not using watchdog for now, please find all the tests enabled attached. Still, I don't understand where might be the connection between CPU selftests and described behavior? When I comment out my periodic task there is no reset, application works normally.
The CPU self-test and STC self-check are not enabled in your config.
When I comment out my periodic task there is no reset, application works normally.
What does the periodic task do?
First of all, it it working in FreeRTOS Timer Task (Tmr Svc) context, which has priority set to 31 (max priority is 32). It is firing each 500 ms to check if there has been any scheduled actions fired recently - let's call it a software watchdog.
Before this timer is started, on microsecond timer (based on RTI) init, there is a callback method invoked, which adds another action with same callback to event scheduler, this method is invoked each 200 ms, which satisfies the watchdog. Scheduler is written on the linked list basis.
So, assuming, there is a cyclic callback fired from interrupt context (RTI Compare) and a software watchdog fired from FreeRTOS timer task context. If I disable those, everything is working like a charm.
You can use two timers: one for freeRTOS timer, another for your application task. To enable the 2nd RTI compare, you need to modify the code of functin prvSetupTimerInterrupt(void) manually:
static void prvSetupTimerInterrupt(void) is in os_port.c
I already did that, my RTI Compare interface is working perfectly. The problem is that it's probably causing system crash after those ~30 seconds, but I see no reason why. Will excerpts from my source code be helpful?
Will excerpts from my source code be helpful?
The excerpts would be helpful.
Ok, so from the beginning:
This is main routine, nothing special, HAL init, then logging task (priority 22) and user idle task (priority 1) are spawned. Logging task does nothing but writing to buffer and initiating DMA transfers via SCI.
User idle task init (main loop does nothing for now):
Line by line, at first, microsecond timer is initialized (more details later, as this is the "failing" one), then engine configuration is read from FEE, ADC periodic task is spawned (priority 30, it works with 500 Hz frequency doing nothing but polling internal ADC for conversion results and converting values to volts) and started, then two sensors are initialized.
Microsecond timer:
Here is everything interesting. On timer init (line 58) there is low level init performed (nothing but RTI settings), then hardware timer is validated if it is really working (an event is scheduled into future, task is paused for some time and then a test action executed flag is checked). The next two lines are those which cause failure, if I comment them out, everything is working (lines 66-68). Firstly, the callback is executed - this callback schedules another event into future, a skeleton of scheduler can be found at the bottom of this file. This periodically executed event satisfies watchdog spawned in line 68 - if no events happened for 1200 ms it means something is terribly wrong.
That's it, if you'll need something else, let me know.