Forgive the newbiancy, but I've just added a global array to my PIC32 project. e.g. buffer[BUFFER_SIZE]; I've already got several tasks and the project works great however when BUFFER_SIZE is increased above a few hundred bytes or so, it seems a couple tasks no longer execute and I end up in the exception handler with a databus error.

I've got the stack overflow set with a breakpoint in that hook and I've increased the heap size and all task sizes several times to no avail.

Suggestions appreciated!

Have you checked that the tasks are actually created successfully? Look at the return value of xTaskCreate(), and if you are using heap_1.c or heap_2.c (not sure about heap_3.c, but maybe that too) then define a malloc failed hook to see if any allocations fail.

Also check the linker script/map file to ensure you are using the right memory layout for the PIC32 chip you are using.

Hi Dave, thanks for the reply.


- Yes, I've got traps on all the xTaskCreate() calls -- no apparent problem there.
- I'm using heap_2 and added the malloc failed hook/define but it doesn't seem to be getting hooked.
- I'm not specifying a linker script so MPLAB is defaulting ot the standard script for my PIC32.

Basically, I had a huge RTOS queue (40960 bytes) and found QueueSendToBack seemed a bit expensive so I was trying to replace it with my own circular buffer/array. I've made all the necessary changes, eliminated the queue, and defined my array buffer. Once I increase the size of my array past a couple hundred bytes, the tasks don't seem to run properly. I know that's a bit vague and it could be a multitude of things -- the point is, I'm not *using* the array in my code yet... just allocating/defining it.

If it's under a certain size, everything works fine; if not, I don't get any exceptions (that I'm aware of) but things are not fine.

If I could create a Queue of size=40960, why can't a define a native array of the same size? What's different about the Queue creation?

Ok, wow, sorry for wasting everyone's time. It turns out this wasn't RTOS related at all. The initializer for said array was "0" instead of "{0}" which somehow caused all sorts of havoc without any warning(s).

Thanks for your time.