I have configASSERT enabled, stack checking enabled, calling vPortValidateInterruptPriority from all interrupts to verify priorities, and only calling from ISR API functions inside interrupts. However, intermittent faults continue to exist, mainly while in idle task it appears. I am using the SAM4L tickles port, IAR compiler, and the ATMEL ASF. Looking at the FAQ: 1. The application I created compiles, but does not run – it runs for a while… 2. Stacks – overflow detection is on, calls to uxTaskGetStackHighWaterMark() show over 1000 bytes of stack available to all stacks including cstack 3. I added a simple task to a demo, and now the demo crashes! – few thousands bytes of heap left after allocating all stacks 4. Using API functions within interrupts – not calling non ISR API from interrupt doing… 5. The RTOS scheduler crashes when attempting to start the first task – getting past this point 6. The interrupt enable flag gets set incorrectly – hmmm. See below. 7. My application crashes before the RTOS scheduler is even started – I may be allowing posting to queues prior to RTOS starting… 8. Suspending the RTOS scheduler (calling vTaskSuspendAll()) causes me problems – my application never suspends the scheduler. 9. I have created a new application – but it will not compile – my application compiles 10. I get stuck on the line that starts – not having this problem I don’t believe my application disables interrupts, however, I am using the ASF which does. There are so many interrupt disabling functions, it is unclear to me what I can and cannot be using. Should I be changing the Atmel ASF to replace the interrupt disabling with portENTER_CRITICAL? cpuirqdisable/ Disableglobalinterrupt —same as Disableglobalinterrupt / used by ASF and WDT taskENTERCRITICAL – used in freeRTOS and SAM4Llowpowertick_management __disable_interrupt – used by port.c __disable_irq- used by ASF (interrupt_sam_nvic) portDISABLE_INTERRUPTS –used by freertos vPortEnterCritical / portENTER_CRITICAL – used by port.c portDISABLE_INTERRUPTS / ulPortSetInterruptMask – used by port.c and FreeRTOS
Thank you for providing such detailed information. What happens when the application crashes – do you end up in a hard fault, data abort, etc? Did you attempt to debug that. Not always possible, but sometimes very helpful – I suspect you have seen this page already: http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html Does the issue occur when configUSETICKLESSIDLE is set to 0? Regarding the interrupt enabling/disabling: FreeRTOS never completely disables interrupts – its critical regions are implemented by setting the BASEPRI register to mask a subset of interrupt priorities, rather than setting the i bit in the CPSR to globally disable interrupts. The only way you should disable or enable interrupts yourself is by calling taskENTERCRITICAL and taskEXITCRITICAL if in a task, or portSETINTERRUPTMASKFROMISR and portCLEARINTERRUPTMASKFROMISR if in an interrupt (the latter two there are actually intended for internal use, and you will see them being used in xQueueGenericSendFromISR() in queue.c, but there is nothing to stop you using them yourself). The big exception to this is when implementing the ‘suppress ticks and sleep’ function – where an global disable must be used for the reasons explained in the source code comments – that is kernel code rather than user code though. I believe the ASF on the other hand effects critical sections by globally disabling interrupts using the i bit in the CPSR. So provided it always enables it again there should be no conflict between its critical sections and FreeRTOS’s. Regards.
Concerning the interrupts – it looks like there are ~14 different disable interrupt functions – some work by globally disabling interrupts, while others work by setting BASEPRI as you said. //works by setting basepri, no nesting support – ok for ISR portSETINTERRUPTMASKFROMISR/taskDISABLEINTERRUPTS/portDISABLEINTERRUPTS/ulPortSetInterruptMask – used in freeRTOS and SAM4Llowpowertickmanagement //works by setting basepri, with nesting support – ok for tasks taskENTERCRITICAL/portENTERCRITICAL/portENTERCRITICAL/vPortEnterCritical – used in freeRTOS and SAM4Llowpowertick_management //global disable with DMB with nesting depth cpuirqenter_critical — not used //global disable – returns flags cpuirqsave — used by ASF and SAM4Llowpowertickmanagment //global disable with DMB – is DMB needed? cpuirqdisable/Disableglobalinterrupt — used by ASF and WDT //global disable without DMB – is DMB needed? disable_irq/disable_interrupt – used by port.c Should the port.c usage of a global disable without DMB be changed to a call with DBM? We tried using the file provided on this forum (see link below) and that seemed to help somewhat with several issues we have been seeing: http://sourceforge.net/p/freertos/discussion/382005/thread/72d095e3/ Something else we did was decrease the clock speed from max (48 MHz) and there may be a correlation between slowing down the clock rate and seeing less hard faults. There is a really sketchy remark in the atmel asf: // These defines for homogeneity with other SAM header files.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.