Page 3 of 4

Re: getting Hard Fault when using fast interrupts

Posted: Sun Apr 19, 2015 7:04 pm
by Giovanni
This is strange and I don't like what it could mean, it seems that fast IRQ interacts badly with the rescheduling code.

I will try to reproduce the problem on my side.

Giovanni

Re: getting Hard Fault when using fast interrupts

Posted: Sun Apr 19, 2015 7:25 pm
by Giovanni
Hi,

I tried on an STM32F3 and failed to reproduce the error using both GCC and Keil.

This is the main() I used:

Code: Select all

/*
    ChibiOS - Copyright (C) 2006..2015 Giovanni Di Sirio

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.
*/

#include "ch.h"
#include "hal.h"
#include "test.h"

/*
 * Blinker thread #1.
 */
static THD_WORKING_AREA(waThread1, 128);
static THD_FUNCTION(Thread1, arg) {

  (void)arg;

  chRegSetThreadName("blinker");
  while (true) {
    palSetPad(GPIOE, GPIOE_LED3_RED);
    chThdSleepMilliseconds(125);
    palClearPad(GPIOE, GPIOE_LED3_RED);
    chThdSleepMilliseconds(125);
    palSetPad(GPIOE, GPIOE_LED7_GREEN);
    chThdSleepMilliseconds(125);
    palClearPad(GPIOE, GPIOE_LED7_GREEN);
    chThdSleepMilliseconds(125);
    palSetPad(GPIOE, GPIOE_LED10_RED);
    chThdSleepMilliseconds(125);
    palClearPad(GPIOE, GPIOE_LED10_RED);
    chThdSleepMilliseconds(125);
    palSetPad(GPIOE, GPIOE_LED6_GREEN);
    chThdSleepMilliseconds(125);
    palClearPad(GPIOE, GPIOE_LED6_GREEN);
    chThdSleepMilliseconds(125);
  }
}

/*
 * Blinker thread #2.
 */
static THD_WORKING_AREA(waThread2, 128);
static THD_FUNCTION(Thread2, arg) {

  (void)arg;

  chRegSetThreadName("blinker");
  while (true) {
    chThdSleepMilliseconds(125);
    palSetPad(GPIOE, GPIOE_LED5_ORANGE);
    chThdSleepMilliseconds(125);
    palClearPad(GPIOE, GPIOE_LED5_ORANGE);
    chThdSleepMilliseconds(125);
    palSetPad(GPIOE, GPIOE_LED9_BLUE);
    chThdSleepMilliseconds(125);
    palClearPad(GPIOE, GPIOE_LED9_BLUE);
    chThdSleepMilliseconds(125);
    palSetPad(GPIOE, GPIOE_LED8_ORANGE);
    chThdSleepMilliseconds(125);
    palClearPad(GPIOE, GPIOE_LED8_ORANGE);
    chThdSleepMilliseconds(125);
    palSetPad(GPIOE, GPIOE_LED4_BLUE);
    chThdSleepMilliseconds(125);
    palClearPad(GPIOE, GPIOE_LED4_BLUE);
  }
}

CH_FAST_IRQ_HANDLER(VectorA4)
{
uint8_t i;
GPIOD->BSRR.H.set=1<<15;
for(i=0;i<10;i++);
TIM1->SR=0;
 GPIOD->BSRR.H.clear=1<<15;
   (void) __get_FPSCR();
}

/*
 * Application entry point.
 */
int main(void) {

  /*
   * System initializations.
   * - HAL initialization, this also initializes the configured device drivers
   *   and performs the board-specific initializations.
   * - Kernel initialization, the main() function becomes a thread and the
   *   RTOS is active.
   */
  halInit();
  chSysInit();

  /*
   * Activates the serial driver 1 using the driver default configuration.
   * PA9(TX) and PA10(RX) are routed to USART1.
   */
  sdStart(&SD1, NULL);
  palSetPadMode(GPIOA, 9, PAL_MODE_ALTERNATE(7));
  palSetPadMode(GPIOA, 10, PAL_MODE_ALTERNATE(7));
  RCC->APB2ENR|=RCC_APB2ENR_TIM1EN;

  /*
   * Creates the example threads.
   */
  chThdCreateStatic(waThread1, sizeof(waThread1), NORMALPRIO+1, Thread1, NULL);
  chThdCreateStatic(waThread2, sizeof(waThread2), NORMALPRIO+1, Thread2, NULL);

  TIM1->ARR=2000;
  TIM1->PSC=0;
  TIM1->DIER=1;
  NVIC_SetPriority(TIM1_UP_TIM16_IRQn, 1);
  NVIC_ClearPendingIRQ(TIM1_UP_TIM16_IRQn);
  NVIC_EnableIRQ(TIM1_UP_TIM16_IRQn);
  TIM1->CR1=1;

  /*
   * Normal main() thread activity, in this demo it does nothing except
   * sleeping in a loop and check the button state, when the button is
   * pressed the test procedure is launched.
   */
  while (true) {
    if (palReadPad(GPIOA, GPIOA_BUTTON))
      TestThread(&SD1);
    chThdSleepMilliseconds(500);
  }
}


I also added an FPU operation in the timer ISR in order to trigger a state save, but it also worked. I used ChibiOS 3.0, if nothing changes tomorrow I will try on 2.6.8 but the port code is the same.

In the meanwhile, could you try to enable assertions, checks and "state checker" in chconf.h?

Giovanni

Re: getting Hard Fault when using fast interrupts

Posted: Sun Apr 19, 2015 8:21 pm
by Coreglider
In the meanwhile, could you try to enable assertions, checks and "state checker" in chconf.h?

I already enabled them and posted a screenshot with a result of debug check.
Ok, I'll try your code tomorrow on f4.

Re: getting Hard Fault when using fast interrupts

Posted: Sun Apr 19, 2015 8:27 pm
by Giovanni
The messages was only partially visible: "S". Next time could you get the whole string pointed by panic_dbg_msg?

Giovanni

Re: getting Hard Fault when using fast interrupts

Posted: Sun Apr 19, 2015 8:31 pm
by Coreglider
"SV#4" it can be seen on screenshot

Re: getting Hard Fault when using fast interrupts

Posted: Sun Apr 19, 2015 8:39 pm
by Giovanni
SV#4 can happen in two cases:

Code: Select all

 *            - SV#4, misplaced @p chSysLock().
 *              - Called from an ISR.
 *              - Called from a critical zone.


If chSysLock() is called from an ISR or callback or if it is called from a critical zone: two consecutive chSysLock(). Something I don't see in your code.

Giovanni

Re: getting Hard Fault when using fast interrupts

Posted: Mon Apr 20, 2015 1:08 pm
by Coreglider
You code with some modifications to run it under 2.6.8 get the same result - stuck in the context switching or in idle thread. But I didn't get chDbgPainic event, despite all checks are enabled. When I edited thread code (just added more led switching commands), I get chDbgPainic with "stack overflow" message.

Re: getting Hard Fault when using fast interrupts

Posted: Mon Apr 20, 2015 4:42 pm
by Giovanni
Please try compiling with -O2, stack overflows should go.

I will post more details later.

Giovanni

Re: getting Hard Fault when using fast interrupts

Posted: Mon Apr 20, 2015 6:01 pm
by Giovanni
Hi,

You may try to define:

Code: Select all

#define PORT_INT_REQUIRED_STACK         128


in chconf.h, this will increase the stack area of all threads, including the idle one. The default is 32 and maybe it is not sufficient under your conditions.

Giovanni

Re: getting Hard Fault when using fast interrupts

Posted: Tue Apr 21, 2015 1:38 pm
by Coreglider
Do you found any interactions between fast interrupts and context switching code (with FPU enabled)?