dibosco wrote on Monday, November 12, 2012:
Thanks for the replies and and sorry for the delay in replying, I didn’t get a notification of a reply.
I think it’s RAM because removing a task took it from crashing to not crashing (with a HardFaultException). What I did was remove the USB code as it’s not often used in normal operation and it went from crashing once a key is pressed to not crashing unless you go into “set-up mode”. Once this mode is entered, code that is not normally executed is called, so I assumed I was overflowing its stack; increasing its stack size brings the other problem back where it crashes on a keypress, which made me think I was right on the edge of code usage.
I have also had situations where it would crash as soon as the scheduler was started unless I did something like reduce the size of the stack in a thread to free up an extra bit of memory.
I think it’s a fair question to ask about longs v bytes, because reserving a byte on the STM32 seem to take up a long. I assume from what’s been said, FreeRTOS is very neat with how it uses memory and it somehow packs chars within a long for queues.
An example of task creation is:
xTaskCreate(ProcessKeys, ( signed char * ) “Process Capacitive Keys”, PROCESS_KEYS_STACK_SIZE, NULL, mainProcessKeys_TASK_PRIORITY, NULL );
When I looked at where FreeRTOS had crashed when it hit a HardFaultException, it was usually the same task, but not always.