port.c(483): error: A1586E: Bad operand types (UnDefOT, Constant) for operator (

[Zaher]

Posted on October 28, 2017 at 21:35

I'm trying to compile a project generated using STM32CubeMX for MDK-ARM but the compiler gives the following error: 

port.c(483): error: A1586E: Bad operand types (UnDefOT, Constant) for operator (

everytime I enable the 'FreeRTOS' option in CubeMX. Initially, and after generating the code from CubeMX, everything compiles without an issue, but as soon as I start to add some source files to the project, the compiler starts to complain about that error in port.c file. Removing the newly added sources with their include paths doesn't help solve the issue. It's just like if something corrupts the FreeRTOS port sources and it won't go away until I disable the 'FreeRTOS' option then re-enable it and generate the code again. 

Upgrading to the latest STM32CubeMx with the latest firmware packages for my device did not help, as well! 

#configmax_syscall_interrupt_priority #stm32f4-freertos-port.c(483):-error:-a1586e:-bad-operan

[Tesla DeLorean]

Posted on October 28, 2017 at 21:40

Guess you'd want to look closely at the line in question, and ask yourself why the *assembler* is throwing an error on it.

What version of Keil/MDK-ARM ?

Present the surrounding lines, and any #ifdef/#endif around them.

[Zaher]

Posted on October 28, 2017 at 21:50

 ,

 ,

I'm on version 5.15

And here is the assembler block in question: ,

__asm void xPortPendSVHandler( void )

 ,

{

 ,

extern uxCriticalNesting,

 ,

extern pxCurrentTCB,

 ,

extern vTaskSwitchContext,

PRESERVE8

mrs r0, psp

 ,

isb

 ,

/* Get the location of the current TCB. */

 ,

ldr r3, =pxCurrentTCB

 ,

ldr r2, [r3]

/* Is the task using the FPU context? If so, push high vfp registers. */

 ,

tst r14, ♯ 0x10

 ,

it eq

 ,

vstmdbeq r0!, {s16-s31}

/* Save the core registers. */

 ,

stmdb r0!, {r4-r11, r14}

/* Save the new top of stack into the first member of the TCB. */

 ,

str r0, [r2]

stmdb sp!, {r3}

 ,

mov r0, ♯ configMAX_SYSCALL_INTERRUPT_PRIORITY

 ,

msr basepri, r0

 ,

dsb

 ,

isb

 ,

bl vTaskSwitchContext

 ,

mov r0, ♯ 0

 ,

msr basepri, r0

 ,

ldmia sp!, {r3}

/* The first item in pxCurrentTCB is the task top of stack. */

 ,

ldr r1, [r3]

 ,

ldr r0, [r1]

/* Pop the core registers. */

 ,

ldmia r0!, {r4-r11, r14}

/* Is the task using the FPU context? If so, pop the high vfp registers

 ,

too. */

 ,

tst r14, ♯ 0x10

 ,

it eq

 ,

vldmiaeq r0!, {s16-s31}

msr psp, r0

 ,

isb

 ,

♯ ifdef WORKAROUND_PMU_CM001 /* XMC4000 specific errata */

 ,

♯ if WORKAROUND_PMU_CM001 == 1

 ,

push { r14 }

 ,

pop { pc }

 ,

nop

 ,

♯ endif

 ,

♯ endif

bx r14

 ,

nop

 ,

nop

 ,

}

I guess it's something related to memory allocation on the stack? If I was not wrong on my assumption, this happens everytime I try to add some source files from the demo package that allocate memory on the CCM 0x10000000 region. ,

** Just updated the block! ,

[Tesla DeLorean]

Posted on October 28, 2017 at 22:17

So assuming an STM32F4 part?

Which is the offending line here?

Is the FPU enabled in the target options dialog?

[Zaher]

Posted on October 29, 2017 at 10:56

I believe I have just found what causes that error and my project compiles now with all the modules added without any issue. It had nothing to do with memory allocation on CCM, interrupt priorities, or anything I have thought of before. It was just an include file. One of the modules I have used from the demo package includes the main.h file, which in turn includes the stm32f4xx_hal.h file. Replacing that file with the device header file, stm32f4xx.h, has solved the issue and now the project compiles with FreeRTOS enabled and all the other sources I had initially! 

Not sure if that was a permanent solution to the problem, but I'm really afraid of getting the same error again as I add more and more sources to the project. Up to this moment, everything seems to be working flawlessly! 

Zaher

[Lyn Maric]

Posted on November 09, 2017 at 07:54

It's a new bug of CUBEMX V4.23, and you just need remove this 'U'  

#define __NVIC_PRIO_BITS          4U ,that's will be OK.

[Sasha A]

Posted on March 08, 2018 at 12:01

Same bug in CubeMX 4.24