PIC24EP256MC202 Calling TaskStartScheduler resets application (very basic)

dom11990 wrote on Saturday, April 19, 2014:

Hello all,

This is my first attempt at making FreeRTOS (8.0.0) run on this particular PIC. I’ve spent the better part of the day reading all the doc and ensuring that I have everything in the right place. I’ve selected the heap2.c (although I tried them all) and included the appropriate #define MPLAB_PIC24_PORT to ensure the right port files are included. I am able to compile the code but as soon as I hit the TaskStartScheduler line, I am greeted with the following debug message

“No source code lines were found at current PC 0x2d6”

I of course created a task prior to calling this function as outlined below. Does anyone have any idea what could be wrong or how I can troubleshoot this? Any insight would be greatly appreciated!

xTaskCreate( Tester, "Tester", TEST_TASK_STACK_SIZE, NULL, TEST_TASK_TASK_PRIORITY, Test_thandle);


rtel wrote on Sunday, April 20, 2014:

You need to determine two things:

  1. How far into the function to you get before the error happens. Step into the function in the debugger - can you get into the function at all? If you can get in, keep stepping until the error occurs, then let us know.

  2. Whether the error is that 0x2d6 just isn’t a valid address, in which case the source code cannot be found because there simply isn’t any executable program at that address, or if the address is a valid code address, in which case the error is that the compiler does not know how to resolve the code at that address into a source file. Can you determine what is at that address by looking in the map file? Are you building with optimisation completely turned off?


dom11990 wrote on Sunday, April 20, 2014:

Thank you for your reply. I have all optimizations disabled. The reset occurred during the call to the stdlib malloc which doesn’t seem right. I thought that if there is insufficient heap it should simply return 0? I increased the stack on each function and this resolved the problem. However, now it is resetting during a context switch when a higher priority task preempts a lower priority task. I’ve run a trace on the execution and attached everything after the tick that should initiate the context switch. It seems like the PC isnt getting saved properly because it tries to execute the instruction at 0.

“No source code lines were found at current PC 0x0”

Can you provide some insight on what could be causing this? Thank you for your help? Hopefully after this is resolved everything will run smoothly :slight_smile:

rtel wrote on Sunday, April 20, 2014:

I missed the fact that it was resetting from your first post - I see now you mention it in the title.

If you are using heap_2.c then the stdlib malloc should never be getting called, not from the kernel code anyway, obviously if you call malloc() from your application code then it would.

Where is the stdlib malloc() getting called? Do you have a heap defined for it to use? Note this is different to the heap used by FreeRTOS. http://www.freertos.org/a00111.html

Everything seems ok up to the POP SR, 14 instructions up from the bottom of the trace. There should be a return after that - but it shows 0. I’m not sure how you created that trace, so I’m not sure how to interpret that. Maybe that is showing that the next instruction is 0, in which case it would see like the flash was corrupt (are you running this from flash or RAM?), or that it jumped to zero after executing the return.

Please ensure stack overflow checking is turned on: http://www.freertos.org/Stacks-and-stack-overflow-checking.html


dom11990 wrote on Sunday, April 20, 2014:

Oh my mistake I meant heap3.c The one that uses the standard malloc. I have been running this code in the MPLAB X 2.05 Simulator. I’ve never had the simulator randomly or incorrectly reset so I don’t think it is a problem with the simulator. I’m declaring Heap in my project properties since heap3.c requires you to do this manually to function properly. I currently have my project heap and the FreeRTOSconfig heap size set to 5000. This particualr MCU has run code in the past utilizing 20kb of heap without issues.

As per the trace, I created it using built in functionality of the MPLAB X Simulator.

I enabled CHECK_FOR_STACK_OVERFLOW with the second option and created a hook function containing a breakpoint but it doesnt seem to get called.

I checked the portasm file I have and it definitely has the return following the POP SR call. It just doesn’t seem to get called for some reason and jumps to address 0 instead.
Any idea what my next troubleshooting steps could be?

Thanks for your help,

rtel wrote on Sunday, April 20, 2014:

If you are using heap_3 then the heap size is set by your project’s options, so configTOTAL_HEAP_SIZE doesn’t do anything.

If you are using heap_1, heap_2 or heap_4 then configTOTAL_HEAP_SIZE allocates an array that is used as the heap, and the heap allocated by your tools is not used, so you may as well set it to as close to 0 as it will let you.

If malloc() is the problem then it is possible your program is overwriting the data structures used by malloc() itself, or that a linker script problem is causing either variables to be allocated to space within the heap or the stack and heap are clashing.

I think you said you had tried other heap implementations already, but the simplest thing to do would be switch to heap_1.c (which means you cannot delete anything! OK for a test but remember to switch back if your real application every deletes a task, queue, semaphore, etc.), set the heap allocated by your tools to as small as it will let you so as not to waste RAM, set configTOTAL_HEAP_SIZE to an appropriate value, and set a malloc failed hook with a break point in it to catch malloc failures.

After that I don’t know. These are just suggestions that might help you debug.


dom11990 wrote on Sunday, April 20, 2014:

Switching to heap4 with a larger stack per function resolved the problem, I’m guessing that not having a sufficiently large enough stack is what prevented this from fixing the issue right off the bat.

I did some searching around and apparently others have had a similar problem because they redefined / overwrote some symbols that stdlib malloc uses under the hood. Is there a way I can check if I was doing this? I’ve never had a problem with the stdlib malloc before going to freertos. Thanks again for all your help.