Compiler Error for CMSIS-core_cm3.c

Thread Starter

justinvil1103

Joined Apr 6, 2016
52
Hi,

I am currently using the following microcontroller (STM32F100C8T6B) in my design. I am using the STM32CubeIDE and I trying to build the project, but I am getting the following compiler errors from the "core_cm3.c" file

Error: registers may not be the same -- strexb r3,r2,[r3]'

Error: registers may not be the same -- strexh r3,r2,[r3]'

Any help would be greatly appreciated

Thanks,

WJ


This is the version for core_cm2.c

/**************************************************************************//**
* @file core_cm3.c
* @brief CMSIS Cortex-M3 Core Peripheral Access Layer Source File
* @Version V1.30
* @date 30. October 2009
*
* @Note
* Copyright (C) 2009 ARM Limited. All rights reserved.

Below is where the error in the file
/**
* @brief STR Exclusive (8 bit)
*
* @Param value value to store
* @Param *addr address pointer
* @Return successful / failed
*
* Exclusive STR command for 8 bit values
*/
uint32_t __STREXB(uint8_t value, uint8_t *addr)
{
uint32_t result=0;
// register uint32_t result asm ("r2");
__ASM volatile ("strexb %0, %2, [%1]" : "=&r" (result) : "r" (addr), "r" (value) );
return(result);
}
/**
* @brief STR Exclusive (16 bit)
*
* @Param value value to store
* @Param *addr address pointer
* @Return successful / failed
*
* Exclusive STR command for 16 bit values
*/
uint32_t __STREXH(uint16_t value, uint16_t *addr)
{
uint32_t result=0;
register uint32_t result asm ("r2");
__ASM volatile ("strexh %0, %2, [%1]" : "=&r" (result) : "r" (addr), "r" (value) );
return(result);
}
 

MrChips

Joined Oct 2, 2009
34,626
Search using Google Search:

AI Overview

The error "registers may not be the same" when compiling with GCC targeting ARM Cortex-M3, particularly when using core_cm3.c, often stems from incorrect register usage in inline assembly, specifically with strexb and strexh instructions. These instructions are used for atomic byte and half-word store operations, and the compiler, especially with optimizations like -O2, can detect register conflicts that violate the ARM architecture's rules.

Here's a breakdown of the issue and how to resolve it:

Understanding the Problem

  • strexb and strexh:
    These instructions (store exclusive byte and store exclusive half-word) are used for atomic memory operations. They involve writing to a memory location only if the corresponding exclusive access reservation is still valid.
  • Register Conflicts:
    The ARM architecture mandates that the source and destination registers in these instructions must be different. The compiler might optimize and use the same register for both, leading to the error.
  • Optimization Levels:
    Higher optimization levels (like -O2 and above) increase the likelihood of these register conflicts being exposed.
  • core_cm3.c:
    This file, part of the CMSIS (Cortex Microcontroller Software Interface Standard) library, often contains inline assembly implementations of atomic operations, making it a common source of this error.
Solutions
  1. 1. Modify core_cm3.c:
    • The most direct approach is to modify the core_cm3.c file, specifically the functions that use strexb and strexh, such as __STREXB and __STREXH.
    • The error usually appears in these functions: uint32_t __STREXB(uint8_t value, uint8_t *addr) and uint32_t __STREXH(uint16_t value, uint16_t *addr).
    • You need to ensure that the source and destination registers are different. For example, if you have strexb r0, r0, [r1], change it to strexb r0, r2, [r1] (assuming r2 is available).
  2. 2. Use cmsis_gcc.h:
    • In some cases, the strexb and strexh functions might have been moved from core_cm3.c to cmsis_gcc.h.
    • If you're using a newer version of the CMSIS libraries, you might need to check and modify cmsis_gcc.h instead.
  3. 3. Generate New Startup Files:
    • If the issue is widespread across multiple files, consider generating new startup files using a tool like STM32CubeMX. This ensures synchronization between different files and can resolve the problem.
  4. 4. Adjust Optimization:
    • Temporarily lowering the optimization level (e.g., from -O2 to -O1 or even -O0) can help isolate the problem. If the error disappears, it confirms that optimization is the root cause.
  5. 5. Disable LTO (Link-Time Optimization):
    • In some IDEs, you might have an option to enable Link-Time Optimization (LTO). Disabling it can also help work around the issue.
  6. 6. Consult GCC Documentation:
    • For a deeper understanding of register allocation and constraints in inline assembly, consult the GCC documentation.
 
Top