How to find the cause of a hard fault [edit: it was stack overflow]

[Sauraen]

Hi TK,

 

Just wrote a function to save some data to a file on the SD card, and once I got past the initial problems with my naming convention and the function actually ran, I get "!! HARD FAULT !! at PC=0x0001b6fe". Looking in project.lss, this is a line of assembler from the function void xPortPendSVHandler( void ), which I am assuming is part of FreeRTOS.

 

So assuming that it is my code that has a null pointer or something, and not an undocumented problem with FreeRTOS :smile:, how do I find where my mistake is? MiosStudio didn't print a stack trace, just this one line.

 

Thanks,

Sauraen

 

Edit: This is bizarre. It's crashing 0.8 seconds after not only the function I just wrote returns, but everything else I'm running has returned (the "Finished drawing screen").

 

Edited February 2, 2014 by Sauraen

[TK.]

This is the typical result of a stack overflow, you've to reserve more memory for the task which accesses the SD Card.

 

Examples, how to do this, can be found in the mios32_config.h and task.c resp. app.c of applications like MIDIbox SEQ, MIDIbox NG, MIDIO128.

 

MIDIO128 has probably the most simple solution in app.c, it just reserves twice the memory of standard tasks for the 1mS_LP and 1mS_SD task:

  xTaskCreate(TASK_Period_1mS, (signed portCHAR *)"1mS", configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_PERIOD_1mS, NULL);
  xTaskCreate(TASK_Period_1mS_LP, (signed portCHAR *)"1mS_LP", 2*configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_PERIOD_1mS_LP, NULL);
  xTaskCreate(TASK_Period_1mS_SD, (signed portCHAR *)"1mS_SD", 2*configMINIMAL_STACK_SIZE, NULL, PRIORITY_TASK_PERIOD_1mS_SD, NULL);

and it reserves more heap memory:

 

// reserved memory for FreeRTOS pvPortMalloc function

#define MIOS32_HEAP_SIZE 14*1024

 

 

configMINIMAL_STACK_SIZE is declared in programming_models/traditional/FreeRTOSConfig.h

If you need more memory for all tasks, then don't change this define, but MIOS32_MINIMAL_STACK_SIZE in your mios32_config.h file.

 

The standard settings are:

 

 

#ifndef MIOS32_MINIMAL_STACK_SIZE

#define MIOS32_MINIMAL_STACK_SIZE 1024

#endif

 

#ifndef MIOS32_HEAP_SIZE

#define MIOS32_HEAP_SIZE 10*1024

#endif

 

How to find out the best stack size value?

 

Call:

  umm_info( NULL, 1 );

e.g. from a terminal command after you application was running (and especially executed the most memory hungry functions)

It will dump all memory blocks.

Memory areas which haven't been overwritten during runtime are marked with the value A5

 

Best Regards, Thorsten.

[Sauraen]

It's strange, I see this in all the files as you've described it, but no matter what I change MIOS32_MINIMAL_STACK_SIZE to in mios32_config.h, the application still compiles using the same amount of RAM. I changed it to 1000000 and it still works--it shouldn't be able to allocate 1 MB of RAM to hold the stack, if the core only has 64 kB! (In case it matters, this is a modified MIDIbox NG.) Is there any way it's reading FreeRTOSConfig.h before mios32_config.h?

Edited February 1, 2014 by Sauraen

[TK.]

Just have a look into the mios32_config.h file of MIDIbox NG - it uses a different way for the stack size configuration:

// reserved memory for FreeRTOS pvPortMalloc function
#define MIOS32_HEAP_SIZE 10*1024
// UMM heap located in default section (means for LPC17: not in AHB memory, because we are using it for the event pool)
#define UMM_HEAP_SECTION

// stack sizes which are used by various tasks (see APP_Init() in app.c)
#define APP_BIG_STACK_SIZE     (2048)
#define APP_REDUCED_STACK_SIZE (1024)
// for the MIOS32 hooks in main.c
#define MIOS32_MINIMAL_STACK_SIZE APP_BIG_STACK_SIZE
// for the UIP task
#define UIP_TASK_STACK_SIZE       APP_BIG_STACK_SIZE

 

 

Is there any way it's reading FreeRTOSConfig.h before mios32_config.h?

 

 no...

 

You have to mention more details about your modifications - with some luck it triggers a deja-vu at my side, otherwise either try to work out the problematic change by disabling the added sections until the crash doesn't happen anymore.

 

Best Regards, Thorsten.

[Sauraen]

I'm pretty sure I didn't modify anything that would have disrupted that, and I checked, the same thing happens with an untouched copy of MIDIbox NG. Try it yourself, go into your current working copy, change APP_BIG_STACK_SIZE to 1000000, and see if it compiles.

 

Edit: Don't worry about it, I came up with a workaround that was better than my original attempt. Originally, that function was called when you press a softkey labeled "Go!", which means the function was being called from the stackful of functions dealing with MBNG DIN matrix handling and pool searching. Instead, I just made a small array holding flags for whether to load or save a patch to each channel next frame, and moved the actual calling of the SD-card-reading functions to a function that was only a couple of functions deep from the loop in APP_Background. So the stack below it is much less filled up.

Edited February 2, 2014 by Sauraen

[TK.]

change APP_BIG_STACK_SIZE to 1000000, and see if it compiles

 

of course, it will compile because the memory is taken from the heap during runtime, and no from the static allocated RAM section during compile time.

 

Best Regards, Thorsten.