Hi,
I am using Traveo II microcontroller. I created one basic task of blinking Led in CM0+ application which is working fine. In that task, when I try to trigger an interrupt IRQ0 which has priority 1 and in IRQ0 handler trigger IRQ1 (which has priority 0) it is going to hardfault.
It is working fine if I don’t use FreeRTOS.
I am using only one task in the application.
Can you please check what can go wrong?
I guess your are using FreeRTOS API calls in your ISR(s), right ? Could you show the code ?
Did you verify that the priority and FreeRTOS are configured correctly ?
Did you enable configASSERT for development ? There are also assert checks in FreeRTOS catching wrong interrupt prios.
See the FreeRTOS docs (in case you’re using a Cortex-M MCU as I suppose) RTOS for ARM Cortex-M and mabe also this post Understanding priority levels of ISR and FreeRTOS APIs - #16 by aggarg containing a good and easy to understand explanation using interrupts/ISRs with FreeRTOS.
Hi,
Please find the below code.
void blinky(void * arg)
{
(void)arg;
/* Initialize the LED GPIO pin */
Cy_GPIO_Pin_Init(USER_LED_PORT, USER_LED_PIN, &user_led_port_pin_cfg);
/* Toggle the LED periodically */
Cy_GPIO_Inv(USER_LED_PORT, USER_LED_PIN); **//It is coming here//**
Cy_FlashInit(true /*blocking*/);
Cy_FlashSectorErase(0x1000f000, CY_FLASH_DRIVER_BLOCKING);**//Here the IRQ0 is //triggered and here only it leads to hardfault**}
int main(void)
{
SystemInit();
__enable_irq();
NVIC_EnableIRQ(irq_cfg.intIdx);
BaseType_t retval = xTaskCreate(blinky, "blinky", configMINIMAL_STACK_SIZE, NULL, 0, NULL);
vTaskStartScheduler();
}
Did you properly register your isr in the ivt? Will a bp on the isr entry be reached?
Yes the isr is in the Vector table. It is getting into the handler. I kept breakpoint in the handler.
Show us your isr code. Where exactly does it fault in that code? If you were able to break into the isr, you should certainly be able to step through the isr to better localize the fault cause?
yes, we already cleared that. Would you mind answering my questions?
Hi @ShivaSai,
Here you talk about two IRQs (IRQ0 and IRQ1), but in the in main there is only one call to NVIC_EnableIRQ(irq_cfg.intIdx);.
Is it the case that, IRQ0 which has priority 1 is triggering an IRQ0 which has priority 0 (higher priority), but is not enabled, leading to hardfault?
Also as @RAc said, it’d be helpful if you could share the ISR code for both IRQs.
Do you have configASSERT enabled along with recommended stack checking ? See FreeRTOS - stacks and stack overflow checking .
Maybe the bare minimum configMINIMAL_STACK_SIZE is not sufficient for the flash functions you’re using.
Again are there any FreeRTOS calls in your ISR ? Mind to show the ISR code, too ?
Hi,
The IRQ 0 and IRQ 1 handlers are there in ROM boot code which I can’t see. I see only the Disassembly. Please check the actual implementation done in below screenshot.
That does not make sense. If the ISRs are in ROM, they are very likely not OS aware. How is application code expected to interact with the ISR if its code is neither disclosed nor modifyable?
The API talks about “Polling” so definitely not RTOS aware.
One thing that comes to mind is that your pend svc irq may have a higher priority than your UART which is not allowed. pend svc MUST have lowest irq priority and thus MUST NEVER interrupt other irqs.
The Case 1 in 33.1 Functional Description talks about software triggering system calls only when CM0+ is in Handler mode. However, blinky task is running in Thread mode where the system call API (Flash sector erase) is called. Are there other cases described in the document?
After I gave equal priorities for IRQ0 and IRQ1, I am able to execute the System calls successfully
without no hardfault.
@ShivaSai Thanks for reporting back. Glad to hear that hardfault issue is resolved. Please note that by setting same priority to both IRQ0 and IRQ1, IRQ1 won’t be able to pre-empt IRQ0.
