Eclipse / GDB / J-Link crash diagnosis

Kernel
1

eduardo1966 wrote on Wednesday, May 01, 2019:

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 ( GNSS_Buffer_counter_semaphore, &xHigherPriorityTaskWoken ) != pdTRUE )
                                    /* Fatal error but we are inside an interrupt routine */
                                    SP_Printf_nmh ( "ERROR - GNSS_process_character() - Couldn't Give semaphore GNSS_Buffer_counter_semaphore" );

                                portYIELD_FROM_ISR ( xHigherPriorityTaskWoken );

The semaphore has been created with:

    GNSS_Buffer_counter_semaphore = xSemaphoreCreateCounting ( MAX_NMEA_SENTENCES_IN_GNSS_BUFFER/*uxMaxCount*/, 0/*uxInitialCount*/ );
    if ( GNSS_Buffer_counter_semaphore == NULL )
        SP_Printf_h ( "ERROR - GNSS_init() - GNSS_Buffer_counter_semaphore not created" );

thanks

2

eduardo1966 wrote on Wednesday, May 01, 2019:

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 :slight_smile: :slight_smile:

3

eduardo1966 wrote on Wednesday, May 01, 2019:

Once the priority was set to a lower level all went well.

    NVIC_SetPriority ( USART0_IRQn, 7 );
4

rtel wrote on Wednesday, May 01, 2019:

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

5

rtel wrote on Wednesday, May 01, 2019:

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.