cancel
Showing results for 
Search instead for 
Did you mean: 

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

Zaher
Senior II
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
1 ACCEPTED SOLUTION

Accepted Solutions
Posted on November 06, 2017 at 05:13

It seems that the stm32f407xx.h(or other models) constant definition is the culprit.

/**

  * @brief Configuration of the Cortex-M4 Processor and Core Peripherals

  */

&sharpdefine __CM4_REV                 0x0001U  /*!< Core revision r0p1                            */

&sharpdefine __MPU_PRESENT             1U       /*!< STM32F4XX provides an MPU                     */

&sharpdefine __NVIC_PRIO_BITS          4U       /*!< STM32F4XX uses 4 Bits for the Priority Levels */

&sharpdefine __Vendor_SysTickConfig    0U       /*!< Set to 1 if different SysTick Config is used  */

&sharpdefine __FPU_PRESENT             1U       /*!< FPU present                                   */

Just remove the 'U' behind these constants, it then works well. Seems that armcc assemblier does not recognize C-format constant representation.

View solution in original post

15 REPLIES 15
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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
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! ,

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?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on October 28, 2017 at 22:18

Code cannot execute from CCM RAM, so that can be a problem if any code is moved there, but the assembler doesn't understand that limit so hard to see why it would error.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on October 28, 2017 at 22:25

Yes, it is an STM32F407, and the FPU is enabled, as well! I'm sorry, I should have mentioned that from the beginning. 

The offending line is:

mov r0,

‌

I believe I was wrong on my assumption. It has nothing to do with memory allocation on the CCM region. I removed that piece of code and the assembler still throws the error. 

Posted on October 28, 2017 at 22:29

I don't think the code was moved to CCM, but it was a buffer used for memory allocation in the CCM region:

&sharpdefine MEM_BASE 0x10000000

mem_TypeDef memory_pool __attribute__((at(MEM_BASE)));
Posted on October 28, 2017 at 22:29

perhaps add the line in the .C file in one of the other functions

printf('%d\n', 

configMAX_SYSCALL_INTERRUPT_PRIORITY);

Or mouse over 

configMAX_SYSCALL_INTERRUPT_PRIORITY and see if you can right click to the definition, and it is numeric.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on October 28, 2017 at 22:42

I have disabled Browse Info in the target options for faster compile time. I just re-enabled it and now compiling the project. I can also debug that numeric. I have ITM Trace Support for debugger. Will get back with that numeric shortly...

Posted on October 28, 2017 at 23:04

It took it more than 15 minutes to compile with Browse Info enabled in target options. Here is what I got so far:

&sharpdefine configMAX_SYSCALL_INTERRUPT_PRIORITY ( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )