FreeRTOS 9 gets stuck halted infinite loop

[bptech]

Just a note in case someone else runs into the same issue (which is not actually an issue).

SAM4S Xplained Pro, using VisualStudio 7. I copied the FreeRTOS 9 files in over the FreeRTOS 7.3 from ASF. Just to have the latest FreeRTOS. In FreeRTOSconfig they have the standard define for configASSERT():

#define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }

Note that this disables interrupts and halts. All good.

Then I run the code, and instead of running it does not respond at all. No LEDs flashing, nothing. So I hit the pause button to see where the code is stuck. I see this:

Code: Select all

portFORCE_INLINE static void vPortRaiseBASEPRI( void )
{
uint32_t ulNewBASEPRI;

	__asm volatile
	(
		"	mov %0, %1												\n"	\
		"	msr basepri, %0											\n" \
		"	isb														\n" \
		"	dsb														\n" \
		:"=r" (ulNewBASEPRI) : "i" ( configMAX_SYSCALL_INTERRUPT_PRIORITY )
	);
}

Very puzzling. I look at disassembly and see this:

Code: Select all

.../source/portable/gcc/sam/portmacro.h 
	__asm volatile
00402B86   mov.w	r3, #160		 
00402B8A   msr	basepri, r3		 
00402B8E   isb	sy		 
00402B92   dsb	sy		 
00402B96   b	#-4		

It is stuck on the last line, which is a branch to itself.

Actually, though it looks weird, this is just the normal configASSERT() in action. xportRAISEBASEPRI is actually how this processor implements taskDISABLE_INTERRUPTS so what you are seeing is: disable interrupts, infinite loop. Just as advertised. If you go to the call stack and go up one level you can see the configASSERT call and see what went wrong. Just double-click on the line in the call stack right below the top line, below where the yellow arrow is pointing. This will take you to a cofigASSERT() call that failed and you need to fix whatever is shown as wrong.

I am putting this here in case somebody else gets stuck for a few hours trying to figure out why their program gets stuck in such a seemingly odd way. It is perfectly normal, a feature not a bug. All you FreeRTOS old hands are laughing at my youthful folly, but remember you were newbies once too.

[ghassen14]

Hello,
I have been blocked in the same issue. I finally resolve it.
I did the work on an other hardware STM32f4 (Cortex M4 family). The issue was caused by an invalid interrupt priority which was too high that blocked other kernel interrupt.

I wish I helped.