4

I'm developing code for a Cortex M0 using FreeRTOS and eclipse with the AC6 plugin. At the end of my tasks, I'm using an assert to determine if the watermark of my task is greater than the specified task size. The macro I use for my assert looks like this:

#define HMI_DBG_ASSERT(x) if ((x) == 0) {taskDISABLE_INTERRUPTS(); \
                  HAL_GPIO_WritePin(ASSERT_LED_GPIO_Port, ASSERT_LED_Pin, GPIO_PIN_SET); \
                  for( ;; );}

My tasks look like this:

for(;;)
{
    //some
    //code
    uxHighWaterMark = uxTaskGetStackHighWaterMark( NULL );
    HMI_DBG_ASSERT(uxHighWaterMark >= WDG_STACK_SIZE_WATERMARK_WORD);
}

This compiles and works perfectly! My issue is that I'm working on common code with another developer, and he used a macro that is almost identical to mine:

#define CMN_DBG_ASSERT(x) if ((x) == 0) {taskDISABLE_INTERRUPTS(); \
                  HAL_GPIO_WritePin(ASSERT_LED_GPIO_Port, ASSERT_LED_Pin, GPIO_PIN_SET); \
                  for( ;; );}

When I call this macro, my compiler returns the following error:

selected processor does not support `cpsid i' in Thumb mode

the "taskDISABLE_INTERUPTS();" macro is defined by FreeRTOS, and calls the following assembly instruction:

__asm volatile( " cpsid i " )

I find it weird that my compiler doesn't complain with my other macro, but with this one it does. Also, I tried using my HMI_DBG_ASSERT in the .c file where my CMN_DBG_ASSERT is called, and I get the same error. I made sure that my code includes the file correctly and my inclusion path in eclipse is specified.

Cortex-M wiki says that "CPSIE and CPSID also don't exist because ARM instruction set is missing from Cortex-M. Other CPS instructions still exists in the Cortex-M."

ARM's website does have a specification for the CPSIE and CPSID in their documentation for Cortex-M0:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/BABHBAAB.html

In any case, the macro has been called before and it worked fine, it's just really weird that my compiler is only complaining now. A colleague of mine using IAR Cortex-M edition tried using the macro and it worked fine... I'm starting to think its another strange eclipse problem.

Can anybody shed some light on the issue I'm having?

Roberto Viglione
  • 51
  • 6
  • Any reason you use a macro and not a function as would be good practice? – too honest for this site Aug 12 '16 at 17:04
  • This was my colleague's idea at first, and I just used his code. I think that's beside the issue of this problem because the macro did work in the past. – Roberto Viglione Aug 12 '16 at 17:07
  • What toochain are you using, and what options are you passing to it? (I'm not sure what "the AC6 plugin" is) – Notlikethat Aug 12 '16 at 17:07
  • GCC. -mcpu=cortex-m0 -mthumb -mfloat-abi=soft -D__weak="__attribute__((weak))" -DALIZETI_USE_HMI_DB -DALIZETI_IS_HMI -D__packed="__attribute__((__packed__))" -DUSE_HAL_DRIVER -DSTM32F072xB -DALIZETI_USE_BMS_DB -I../../../Inc -I../../../Drivers/STM32F0xx_HAL_Driver/Inc -I../../../Drivers/STM32F0xx_HAL_Driver/Inc/Legacy -I../../../Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM0 -I../../../Middlewares/Third_Party/FreeRTOS/Source/include -I../../../Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS - – Roberto Viglione Aug 12 '16 at 17:08
  • ahh toolchain, OpenSTM32 – Roberto Viglione Aug 12 '16 at 17:08
  • 1
    "it did work" - the standard excuse for bad coding style ... – too honest for this site Aug 12 '16 at 17:11
  • http://www.cplusplus.com/reference/cassert/assert/ – Roberto Viglione Aug 12 '16 at 17:13
  • 1
    Sound like configuration problem. Is the AC6 responsible for generating the platform specific files? I guess it is. Double check the settings you have used that they match your target processor. If they are correct, it is probably just buggy and should be reported to the developer. – Eugene Sh. Aug 12 '16 at 17:16
  • If you really want to use a macro, at least wrap it in a `do{}while()`, so it doesn't have weird interactions with `else`. – Peter Cordes Aug 12 '16 at 17:19
  • 2
    Well, it _looks_ like the appropriate `-march` and/or `-mcpu` options aren't being propagated through to the assembler. At a guess, I'd start by pointing a finger in the direction of Eclipse and the confusing difference between changing build settings for the whole project vs. changing them for specific files. – Notlikethat Aug 12 '16 at 17:23
  • @Notlikethat I think I found my problem, my folder with the common code doesn't have the -mpcu option, Ill try to see what caused that. – Roberto Viglione Aug 12 '16 at 17:38

1 Answers1

1

Solved. Somehow my folder with the common code had a different build setting than the other folders in my project, and the -mcpu flag was not there. To reset build configuration to default:

Right-click folder -> Resource Configurations -> Reset to Default

Roberto Viglione
  • 51
  • 6