Hi I have been facing several crashes on the program I’m developping mainly due to uninitialised pointers and such. Being in a multitasking system does not make bug-hunting easier since things tend to happen in an asynchronously way. I’m using Eclipse with GDB and J-Link, I wonder if in the many windows and menu options provided by Eclipse I can get a better diagnostic of the reasons for a crash. At the moment I’m facing a crash in mallocr() at 0x436a82 (see attachment) It seems quite obvious taht the stack pointer register has a bad value (0xffffffac) but how can I find where this came from? The code that seems problematic is when inside an ISR a Give semaphore operation is done: ~~~ if ( xSemaphoreGiveFromISR ( GNSSBuffercountersemaphore, &xHigherPriorityTaskWoken ) != pdTRUE ) /* Fatal error but we are inside an interrupt routine */ SPPrintfnmh ( “ERROR – GNSSprocesscharacter() – Couldn’t Give semaphore GNSSBuffercountersemaphore” );

                            portYIELD_FROM_ISR ( xHigherPriorityTaskWoken );

~~~ The semaphore has been created with: ~~~ GNSSBuffercountersemaphore = xSemaphoreCreateCounting ( MAXNMEASENTENCESINGNSSBUFFER/uxMaxCount/, 0/uxInitialCount/ ); if ( GNSSBuffercountersemaphore == NULL ) SPPrintfh ( “ERROR – GNSSinit() – GNSSBuffercounter_semaphore not created” ); ~~~ thanks

I’ve increased the stack from 8K to 16K (although that should be too much) but now the program stops in an ASSERT (see below) in file port.c ~~~ configASSERT( ucCurrentPriority >= ucMaxSysCallPriority ); ~~~ where ucCurrentPriority is 0 and ucMaxSysCallPriority is 160 (A0h). There is a very interesting big comment above the ASSERT:

  Interrupts that use the FreeRTOS API must not be left at their
        default priority of zero as that is the highest possible priority,
        which is guaranteed to be above configMAX_SYSCALL_INTERRUPT_PRIORITY,
        and therefore also guaranteed to be invalid.

Time to learn about Interrupt Priorities 🙂 🙂

Once the priority was set to a lower level all went well. ~~~ NVICSetPriority ( USART0IRQn, 7 ); ~~~

Yes – there is a very long comment above that assert which basically says you have the interrupt priorities misconfigured ;o)

There are some Eclipse tools, such as Atollic, that will give you a stack trace back to the offending instruction from inside of a fault handler – although it is possible to do that manually to – there is code on the FreeRTOS.org site that shows you how. https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html Additionally there are premium hardware tools that will enable you to put watchpoints on data so you can set a breakpoint if data you know is getting corrupted changes.