2

I'm making project generated with STM32CubeMX for stm32f469i-disco.

I have based setup on "FreeRTOSconfig.h" from "Demonstration" project in STM32CubeFWF4V1.16.0 repo. Fresh project from CubeMX compiles without problems, but after adding STemWin lib "STemWin532_CM4_OS_Keil_ot.lib" I get the error

"..........\Middlewares\ThirdParty\FreeRTOS\Source\portable\RVDS\ARMCM4F\port.c(507): error: A1586E: Bad operand types (UnDefOT, Constant) for operator ("

Interesting fact is that "Demonstration" compiles without this error.

How do I get the project configured:

In CubeMX:

  1. Add periphs needed: DMA2D, DSIHost, FMC etc.

  2. Add BSP drivers for touchscreen etc. Now, it copiles without problems.

  3. Clone "Clock Configuration" based on "Demonstations"

  4. In "Configuration" tab I clone all configuration based on code from "Demonstrations"

Then in Keil: 5. I update Include Path in target options.

  1. Add all STemWin files and when i try to compile: "...Bad operand types..."

When I disable freertos in CubeMX and add non-OS STemWin lib it compiles without problems. When I try to compile non_OS STemWin lib with FreeRTOS enabled, it fails with the same message.

What have I tried to do? Update port.c. Nothing changed.

Am I missing something while creating project?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
pondito
  • 21
  • 3

2 Answers2

1

After spending 2 days to find out what might be the reason for this error, I just found it and my project now compiles with FreeRTOS enabled and all the other sources used initially. Well, it's apparently a recursive include for stm32f4xx_hal.h file. I have added some modules from the demo package and those have some dependencies. Because I wanted to strip out some functions from some modules, I have manually added the includes/resources for the functions needed, which has contributed to that error, as I did not add any guards to my includes.

The offending line was in port.c file, and the error was because of a wrong constant value passed to the assembly line 483: mov r0, #configMAX_SYSCALL_INTERRUPT_PRIORITY

Replacing configMAX_SYSCALL_INTERRUPT_PRIORITY with any numeric value has helped in compiling the code, but I thought I should not leave it like that and it would be much better if I found out the reason for the problem.

More could be found here: https://community.st.com/thread/44751-portc483-error-a1586e-bad-operand-types-undefot-constant-for-operator

Embedded Music
  • 39
  • 8
0

I got a same problem while building a Nucleo-F401RE board firmware with CubeMX 4.25.
This problem started just after setting LL driver use (Low-Level driver) instead of HAL in a CubeMX setting dialog.
I think this problem is from complicit in C definition of header file. Including LL driver header may change __NVIC_PRIO_BITS definition in somewhere. 

#ifdef __NVIC_PRIO_BITS
#define configPRIO_BITS         __NVIC_PRIO_BITS
#else
#define configPRIO_BITS         4
#endif
#define configMAX_SYSCALL_INTERRUPT_PRIORITY (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS))

Changing __NVIC_PRIO_BITS to 4 in a generated source code will solve the problem.

/* mov r0, #configMAX_SYSCALL_INTERRUPT_PRIORITY */
mov r0, #(configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - 4))
Hill
  • 3,391
  • 3
  • 24
  • 28