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
Eclipse / GDB / J-Link crash diagnosis
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” );
Eclipse / GDB / J-Link crash diagnosis
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:
Time to learn about Interrupt Priorities 🙂 🙂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.
Eclipse / GDB / J-Link crash diagnosis
Once the priority was set to a lower level all went well.
~~~
NVICSetPriority ( USART0IRQn, 7 );
~~~
Eclipse / GDB / J-Link crash diagnosis
Yes – there is a very long comment above that assert which basically
says you have the interrupt priorities misconfigured ;o)
Eclipse / GDB / J-Link crash diagnosis
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.