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

[Zaher]

Posted on October 28, 2017 at 23:20

I have commented the offending line, added the printf() function in main, right after all initializations and before the scheduler starts, and the value it returns is 80. Isn't that way more than the MAX_PRIORITIES defined in the config of FreeRTOS?

[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

[Egg Car · Accepted solution]

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.

[Zaher]

Posted on November 06, 2017 at 12:31

Thank you. I will try it if I had the same error again. For now, it's already solved as stated earlier. Like you said, it's an issue with the ARM Assembler as I have never seen this issue with gcc. I have almost an identical copy of the project built for AC6 and it compiles and works just fine! 

[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