FreeRTOS ARM cortex hardfault escalation from systick

Question

Under a special condition I'm experiencing an hardfault exception. The ICSR indicates that it's an escalation from systick (pending exception = 15).

Any ideas how this would happen?

My guess is, that it's some kind of dead-lock.

Any recommendations how to trace this (without Atmel Studio)?

I'm using FreeRTOS 7.5.2.

UPDATE:

I added some more fault register to the output dump. So it's indeed a bus fault with a systick interrupt pending:

EXCEPTION HANDLER
- ICSR active exception: 3
- ICSR pending exception: 15
- ICSR pending interrupt: 0
- Hardfault status: 0x40000000
  - Memory fault status: 0x00
  - Bus fault status: 0x04
  - Usage fault status: 0x0000

I was able to track down the exception to a FreeRTOS call:

vTaskDelay(10/portTICK_RATE_MS);

The application has 2 tasks:

Task with priority 2 (parameter to xTaskCreate)
Task with priority 1

Tasks 1 enters an area locked with a semaphore and hits the line mentioned above. Task 2 should wake up and run until it also wants to enter the locked area.

Just because the bus fault is with the systick pending, it does not mean it has anything to do with the systick. The hardfault status is Forced and the error is an IMPRECISERR (imprecise data error). I strongly recommend you read Richard link below, in particular Handling Imprecise Faults. When vTaskDelay is called the OS goes off elsewhere. I suspect the problem occurs somewhere completely different to you think! — Realtime Rik

Realtime Rik Realtime Rik · Accepted Answer · 2017-01-24T15:32:07

I think you have misunderstood the ICSR. This is not saying the exception has escalated from a SYSTICK and does not have anything to do with the hard fault.

Firstly you need to look in the HFSR (hard fault status register). If forced is set is means it is either escalated from a bus fault, mem man fault or usage fault (I suspect it will be forced). If it is then look in the CFSR to see what kind of error you have.

You can then debug further from here. If it is a type of bus error (again quite likely) then you need to look at the BFARVALID bit in the CFSR. If this is set then you are lucky as the BFAR register will contain the address of the fault. If this is not set then things get a bit more difficult! Bare in mind then CFSR is actually several registers in one so needs decoding correctly, some of the bits are types of bus error and others are mem man faults etc..

FreeRTOS ARM cortex hardfault escalation from systick

2 Answers