Endless loops on vPortRaiseBASEPRI on disassembly

I compiled FreeRTOS with cmake + make for stm32f722 (cortex-m7), however, when I run it on my device, it gets stuck on the “vPortRaiseBASEPRI” function from portmacro.h. I’ve attached the disassembly below. It looks like the disassemble has a lot of jumps to the same line? What could be the problem here?

the file is from portable\GCC\ARM_CM7\r0p1

portFORCE_INLINE static void vPortRaiseBASEPRI( void )
{
uint32_t ulNewBASEPRI;

  __asm volatile
     0800 F9AA   B              0x0800F9AA
     0800 F9C0   B              0x0800F9C0
     0800 F9D6   B              0x0800F9D6
     0800 FD36   B              0x0800FD36
     0800 FD4C   B              0x0800FD4C
     0800 FD62   B              0x0800FD62
     0801 025A   B              0x0801025A
     0801 0288   B              0x08010288
     0801 02C2   B              0x080102C2
     0801 02F0   B              0x080102F0
     0801 032A   B              0x0801032A
     0801 0358   B              0x08010358
     0801 0392   B              0x08010392
     0801 03C0   B              0x080103C0
     0801 053C   B              0x0801053C
     0801 0552   B              0x08010552
     0801 0570   B              0x08010570
     0801 0572   NOP
     0801 0B7A   B              0x08010B7A
     0801 0BE8   B              0x08010BE8
     0801 0BEA   NOP
     0801 0C4A   B              0x08010C4A
     0801 101E   B              0x0801101E
     0801 1034   LDR            R3, [SP, #4]
     0801 10E4   B              0x080110E4
     0801 10E6   NOP
     0801 110A   B              0x0801110A
     0801 1186   MOV.W          R3, #0x50
     0801 118A   CPSID          i
     0801 118C   MSR            BASEPRI, R3
     0801 1190   ISB            SY
     0801 1194   DSB            SY
     0801 1198   CPSIE          i
     0801 1256   B              0x08011256
     0801 12B4   B              0x080112B4
     0801 12CA   LDR            R3, [SP, #12]
     0801 1318   B              0x08011318
     0801 133E   B              0x0801133E
     0801 4F6A   B              0x08014F6A
     0801 4F8C   B              0x08014F8C
     0801 4FA6   B              0x08014FA6
     0801 4FC6   B              0x08014FC6
     0801 4FDC   B              0x08014FDC
     0801 504A   B              0x0801504A
     0801 50E4   B              0x080150E4
     0801 5102   B              0x08015102
     0801 5196   B              0x08015196
     0801 52CC   B              0x080152CC
     0801 5396   B              0x08015396
     0801 53B4   B              0x080153B4
     0801 5506   B              0x08015506
     0801 5560   B              0x08015560
     0801 557C   B              0x0801557C
     0801 56D2   B              0x080156D2
     0801 56F0   B              0x080156F0
     0801 57B8   B              0x080157B8
     0801 58DC   B              0x080158DC
     0801 58F2   B              0x080158F2
     0801 5AA6   B              0x08015AA6
     0801 5AA8   MOV            R5, R0
     0801 5AAA   B              0x08015902
     0801 5BDE   B              0x08015BDE
     0801 5C12   B              0x08015C12
     0801 5C64   B              0x08015C64
     0801 604E   B              0x0801604E
     0801 60C0   B              0x080160C0
     0801 60D6   B              0x080160D6
     0801 60EC   B              0x080160EC
     0801 61E6   B              0x080161E6
     0801 6264   B              0x08016264
     0801 62EC   B              0x080162EC
     0801 6302   B              0x08016302
     0801 6318   B              0x08016318
     0801 650E   B              0x0801650E
     0801 6576   B              0x08016576
     0801 66A2   B              0x080166A2
     0801 674E   B              0x0801674E
     0801 6800   B              0x08016800
     0801 6858   B              0x08016858
     0801 686E   B              0x0801686E
     0801 6914   B              0x08016914
     0801 6950   B              0x08016950
     0801 69AE   B              0x080169AE
     0801 69F6   B              0x080169F6
     0801 6A62   B              0x08016A62
     0801 6A78   B              0x08016A78
     0801 6BBC   B              0x08016BBC
     0801 6BEE   B              0x08016BEE
     0801 6C90   B              0x08016C90
     0801 6CFC   B              0x08016CFC
     0801 6E0E   B              0x08016E0E
     0801 6E66   B              0x08016E66
     0801 6EB4   B              0x08016EB4
     0801 6EB6   NOP
     0801 6F22   B              0x08016F22
     0801 6F3C   B              0x08016F3C
     0801 702E   B              0x0801702E
     0801 70F0   B              0x080170F0
     0801 7154   B              0x08017154
     0801 716A   B              0x0801716A
     0801 72C4   B              0x080172C4
     0801 72FC   B              0x080172FC
     0801 7312   B              0x08017312
     0801 7328   B              0x08017328
     0801 733E   B              0x0801733E
     0801 735A   B              0x0801735A
     0801 73FA   B              0x080173FA
     0801 7E8C   B              0x08017E8C
     0801 7EBA   B              0x08017EBA
     0801 7ED0   B              0x08017ED0
     0801 8572   B              0x08018572
     0801 8598   B              0x08018598
     0801 85B6   B              0x080185B6
     0801 87DC   B              0x080187DC
     0801 8A08   B              0x08018A08
     0801 8C1C   B              0x08018C1C
     0801 8E78   B              0x08018E78
     0801 8E7A   NOP
     0801 A298   B              0x0801A298
     0801 A29A   NOP
     0801 A9D6   B              0x0801A9D6
     0801 ABD6   B              0x0801ABD6
     0801 BD8E   B              0x0801BD8E
     0801 BEA6   B              0x0801BEA6
     0801 C4D2   B              0x0801C4D2
     0801 C566   B              0x0801C566
     0801 CB7A   B              0x0801CB7A
     0801 CD58   B              0x0801CD58
     0801 CD5A   NOP
     0801 D004   B              0x0801D004
     0801 D01A   B              0x0801D01A
     0801 D224   B              0x0801D224
     0801 D888   B              0x0801D888
     0801 D89E   B              0x0801D89E
     0801 D8B4   B              0x0801D8B4
     0801 D8DC   B              0x0801D8DC
     0801 D9A8   B              0x0801D9A8
     0801 D9BE   B              0x0801D9BE
     0801 D9FA   B              0x0801D9FA
     0801 DA10   B              0x0801DA10
     0801 DAA4   B              0x0801DAA4
  (
    "  mov %0, %1                        \n"  \
    "  cpsid i                          \n" \
    "  msr basepri, %0                      \n" \
    "  isb                            \n" \
    "  dsb                            \n" \
    "  cpsie i                          \n" \
    :"=r" (ulNewBASEPRI) : "i" ( configMAX_SYSCALL_INTERRUPT_PRIORITY ) : "memory"
  );
}

I’m using arm-none-eabi toolchain and here’s the compile options

-mcpu=cortex-m7 -march=armv7e-m -mthumb -mfpu=fpv5-sp-d16 -mfloat-abi=hard -0g -g -O3 -fdata-sections -ffunction-sections

Adding @rtel’s comment as well from the original SourceForge ticket:

Richard Barry wrote on May 22, 2020:
The assembly code bares no resemblance to the source code, especially as the source function is written in assembly. For that reason I am confident this is not a FreeRTOS bug…

My first thought is that the signature says ‘FORCE_INLINE’, which will mean that there shouldn’t be a free copy of such a function, but will only occur ‘inline’ where the call is being made, so one question come, where are you seeing this disassembly?

A long list of branches sounds like the is actually the interrupt vector table, could your program have crashed at a jump to location 0, and the disassembler see that this function has an address of 0 (because it doesn’t exist) and labels it as such?

I agree - this looks like the vector table, and most probably the debugger is not able to directly relate the source code to the assembly code because you have the optimisation turned up - a known quirk of GCC.

The actual code for that function is at address 0801 1186 - this is the r0p1 code, which includes additional interrupt manipulation to work around a bug in that early core version.

If you are stuck in an interrupt vector that has its default “branch to yourself” handler, rather than a handler you have installed, then it could be one of the following:

  1. You have hit a hard (or other) fault - check the address you are in to see how it maps the to the vector table’s source code - you can get the start address of the vector table from the vector base address register or the map file generated when you built the code (it will be zero unless your start up code moved the vector table into RAM).

  2. A genuine interrupt occurred and you have not installed a handler for the interrupt. That could be one of the three FreeRTOS interrupts (see the red “special note for Arm Cortex users” on this page https://www.freertos.org/FAQHelp.html), or a peripheral interrupt.

I got the disassembly when debugging the .elf file with Ozone. It doesn’t seem like its the vector table, I checked and the vector table is at 0x200000 on the debugger.

I’ll recheck the startup file and try to test with a minimal FreeRTOS project.

Here’s the context of the situation, I have a project initially built with IAR compiler however, I am now unable to use the IAR for compilation so I moved to GCC. The project worked fine with the IAR so I was thinking I was maybe missing something with the compile options with GCC.

Turns out, the dissasembly for the vPortRaiseBASEPRI probably just lists all the location where the function was inlined.

I was actually getting stuck in the inline in xQueueGenericSend: 758 at 0x80153B4. The assert fails which is weird because I don’t suspend the scheduler in any part of the project and I’m sure the scheduler is started since the function that calls the send Queue is actually started by the mainTask which won’t start if the scheduler is not started.

line 758: configASSERT( !( ( xTaskGetSchedulerState() == taskSCHEDULER_SUSPENDED ) && ( xTicksToWait != 0 ) ) );

queue.c , Line 758
 08015398   9B01        LDR            R3, [SP, #4]
 0801539A   2B00        CMP            R3, #0
 0801539C   F43F AF01   BEQ.W          0x080151A2
 080153A0   F04F 0350   MOV.W          R3, #0x50
 080153A4   B672        CPSID          i
 080153A6   F383 8811   MSR            BASEPRI, R3
 080153AA   F3BF 8F6F   ISB            SY
 080153AE   F3BF 8F4F   DSB            SY
 080153B2   B662        CPSIE          i
portmacro.h , Line 195
 080153B4   E7FE        B              0x080153B4
queue.c , Line 776
 080153B6   4642        MOV            R2, R8
 080153B8   4649        MOV            R1, R9
 080153BA   4620        MOV            R0, R4
 080153BC   F7FF FD88   BL             prvCopyDataToQueue            ; 0x08014ED0

I think I’ve solved the problem but I’m not sure how and what the cause of the problem really is. I rebuilt the entire project by starting a new project from scratch entirely for gcc and slowly transferring the app source files.