getting Hard Fault when using fast interrupts

[Coreglider]

So, I made a test project for f4discovery with tim1 interrupt and two threads: main and other one. Now I don't have a hard fault handler, now system just stuck in the idle thread after a second, and there are no context switching is performed. (PS: now I have the handler) But if I disable timer interrupt or set priority 4 for it, all works fine.
And I made a test project based on the ChibiOS demo for f4discovery: two LEDs blinkning threads and tim1 high priority interrupt. And all's working. So, problem is definitely in the system-related initializations. Interrupt priorities and priority grouping bits are exactly the same. Unfortunately I don't have a clear undertandig of low-level core processes, so I have no idea where exactly can be the problem.

[Giovanni]

Why don't you try using the HAL for initialization on your board? then you can add your TIM code.

It will at least help understanding if the problem is with initialization or something else, if the NVIC is OK I wonder what else could affect the kernel, the dual stack is setup in the startup. May be something related to the FPU?

Giovanni

[Coreglider]

I don't want to use HAL in my project, it's not quite clear for me. I'll try to use stm32_clock_init() from HAL, to determine whether problem in SystemInit() or not.

[Giovanni]

I don't want to use HAL in my project, it's not quite clear for me. I'll try to use stm32_clock_init() from HAL, to determine whether problem in SystemInit() or not.

This is what you do when you import the HAL and all drivers are disabled.

Giovanni

[Coreglider]

I give up. If I modify ALMOST ANYTHING in the demo project, it crashes.
I tried to use stm32_clock_init() instead of SystemInit() in my project, but it has no effect.
Here's modified main.c from http://svn.code.sf.net/p/chibios/svn/ta ... -DISCOVERY, and I modified no files except it.
With standard chconf.h this test project is working, but it crashes if you made any changes in config or disable compiler optimization. Please, if you have enough time, check it on your hardware, compiled with keil 4 without optimization.

[Coreglider]

It seems, problem is related not to interrupts, but to FPU. It somehow is not initialized. Sorry for wasting your time.

[Giovanni]

Could you mention a single option that makes the demo crash?

Disabling optimizations could cause stack overflows, unoptimized code uses a lot more stack.

Giovanni

[Giovanni]

It seems, problem is related not to interrupts, but to FPU. It somehow is not initialized. Sorry for wasting your time.

Note that enabling/disabling FPU in compiler options is not sufficient. There is also a port option to define in chconf.h:

#define CORTEX_USE_FPU 0/1

Stack frames are different if FPU is disabled.

Giovanni

[Coreglider]

Yes, compiler option and ChibiOS CORTEX_USE_FPU must be the same value. I've encountered this problem earlier. The problem was in define checks in my project

Code: Select all

 
  #if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
    SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2));  /* set CP10 and CP11 Full Access */
  #endif

and compiler Use FPU option enabled with

Code: Select all

#define CORTEX_USE_FPU                  FALSE

in the demo project.
Thank you for support!
PS: please, fix this options in demo projects, it's really confusing, when project crashes if optimization is disabled.

[Coreglider]

And here I again. The problem seems to be here, when both FPU(compiler and chconf.h) options are enabled. After some amount of time program stucks at the chthd.c

Code: Select all

 do {
    cp = cp->p_next;
  } while (cp->p_prio >= tp->p_prio);

Tested on 2.6.8 discovery demo without optimization enabled, and with FPU enabled. Please, test it. Without FPU enabled all is working.
And here's screenshot with debug checking enabled.