I am using a PIC32MZ1024EFG100T and when I compile and run the code through the debugger it seems to work correctly BUT when running on simulator it locks in a software breakpoint.
Michorchip tech support has gone through the code/project and replicated exactly the same issue and it seems to be caused by something related to freeRTOS.
Please see attached screenshots from Microchip related to this feedback of theirs:
FIRST MICROCHIP EMAIL (screenshot “software breakpoint 1.png”:
Thanks for providing the project, I tried on test machine and could able to duplicate the issue you mentioned. I see the below error message when I compile your project.
d:/microchip/xc32/v2.50/bin/bin/…/…/lib/gcc/pic32mx/4.8.3/…/…/…/…/pic32mx/bin/as.exe: out of memory allocating 4294967280 bytes
SECOND MICROCHIP EMAIL (screenshot “software breakpoint 2.png”:
I further looked at it and noticed that it is caused due to the below line of code.
pxNewListItem->pxNext = pxIndex;
Keep a breakpoint at /* Create OS Thread for APP_DEBUG_Tasks. */
Then in list.c, keep a breakpoint on this line pxNewListItem->pxNext = pxIndex; in
function void vListInsertEnd( List_t * const pxList, ListItem_t * const pxNewListItem .
The general exception is caused due to the Load or Store.
With reference to the comment in their first email “…memory allocating 4294967280 bytes” no idea where such huge number could come from. I don’t have any dynamic memory allocation in my code. The only dynamic allocation is done by freeRTOS for the various tasks etc. Each task is also very “simple” and short with minimal memory allocation.
The only data that is not just few bytes is a large B&W image stored in a fixed array declared as:
- even that size is not even remotely close to the size mentioned in the error
- that variable is not dynamically allocated
- it is a global variable so not related to any task anyway
Furthermore, following useful feedback from this forum, I also changed the heap strategy to “heap_4.h” long time ago and haven’t had any issues on the debugger or simulator since then.
IMPORTANT: The issue is that the debugger does not support that software breakpoint so have no way of finding out if the same is occurring on the silicon without showing any symptoms but still being a potential issues in time with allocation and de-allocation.
How can I find out what causes it and how to make sure the code is safe?
Thank you as always!