MPU definition collision between RTOS.h and core_cm4.h

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • MPU definition collision between RTOS.h and core_cm4.h

    I'm doing some rearranging of the example project. If I include the CMSIS microcontroller header before RTOS.h in my file that integrates the RTOS I get the following error:


    1> /Volumes/Development/louise/CMSIS/CMSIS/Include/core_cm4.h:1420:46: error: expected ')' before '*' token
    1> /Volumes/Development/louise/RTOS/RTOS.h:1657:12: note: in expansion of macro 'MPU'
    1> /Volumes/Development/louise/CMSIS/CMSIS/Include/core_cm4.h:1420:46: error: expected ')' before '*' token
    1> /Volumes/Development/louise/RTOS/RTOS.h:1657:12: note: in expansion of macro 'MPU'


    `core_cm4.h` defines `FPU` as follows:


    C Source Code

    1. #define FPU ((FPU_Type *) FPU_BASE )

  • I really need a fix for this. It's colliding with my code in other places


    I've lost a lot of time trying to integrate EMBOS this time around. The features are nice (MPU support, plugin) but it's not very readable or maintainable so I find myself making many changes to clean it up. In this case I have a set of classes for the peripherals including the NVIC which leads to the include of the CMSIS header for the microprocessor. In the original file the required registers were redefined rather than use the definition in the header which I feel is poor form.

  • RE: MPU definition collision between RTOS.h and core_cm4.h

    Dear Kenny,

    Thank you for pointing us towards this. Your objection is basically correct: While we do not re-define any symbols already defined inside the CMSIS header, we do use "MPU" as a name for a structure member inside RTOS.h. This results in the observed problem with embOS-MPU (but not embOS) when both core_cm4.h and RTOS.h are included in that exact order. We will address this and likely change the member's name in future releases. In the meantime, however, a possible workaround is to include both files in reversed order, that is RTOS.h first and core_cm4.h second. That way, when RTOS.h is preprocessed, "MPU" is not a defined symbol to the preprocessor and thus won't be replaced.

    Kenny wrote:

    I'm doing some rearranging of the example project. If I include the CMSIS microcontroller header before RTOS.h in my file that integrates the RTOS I get the following error:


    While unrelated to your observation, we usually wouldn't recommend to include core_cm4.h directly with your application, but indirectly through the device-specific header file. This is for the reason that the device-specific header defines certain properties of your device on which the core-specific header file relies in return, e.g. __CM4_REV, __MPU_PRESENT, and __FPU_PRESENT, which otherwise may be undefined or defaulted.

    Kenny wrote:


    `core_cm4.h` defines `FPU` as follows:

    C Source Code

    1. #define FPU ((FPU_Type *) FPU_BASE )


    "MPU" is used in RTOS.h instead of "FPU". Since "MPU" was defined analogously in core_cm4.h, however, this does not make much of a difference.

    Kenny wrote:

    I really need a fix for this. It's colliding with my code in other places


    In urgent cases, please consider contacting us directly via our support email address. While we would usually answer request from our customers herein as well, this forum, according to its terms of use, is not meant for technical support from our technical support personnel.

    Kenny wrote:

    I've lost a lot of time trying to integrate EMBOS this time around. The features are nice (MPU support, plugin) but it's not very readable or maintainable so I find myself making many changes to clean it up.


    I'm sorry to hear your experience with embOS was that time consuming. However, since our product and especially the preconfigured start projects devilered with it will usually work with no modification at all, I'm rather surprised you needed to "clean up" embOS. I presume you are using a trial version of embOS MPU for Cortex-M and Embedded Studio? Can you give more details on your project and which modifications you had to perform? We can do this via email as well so you won't need to disclose any information on a public forum.

    Kenny wrote:

    In this case I have a set of classes for the peripherals including the NVIC which leads to the include of the CMSIS header for the microprocessor. In the original file the required registers were redefined rather than use the definition in the header which I feel is poor form.


    Can you please specify which re-definitions you are referring to? Regarding NVIC, our CMSIS-based start projects usually contain one or two definitions, but none of them re-define any symbol from the CMSIS headers.

    Best regards,

    SEGGER - embOS Support
    Martin
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Thanks for your detailed response Martin.


    In terms of clean up I'm only touching RTOSInit_STM32F4x_CMSIS.c. In that file a couple of NVIC registers and several UART registers are defined. I prefer to have them defined once in the CMSIS header. I'm not sure why you would do this at all.


    I also use C++ and have my own classes for the peripherals including the NVIC. Generally defining SysTick_Handler and OSHW_Init() are pretty straight forward but I also remove many of the very sparse comments and macro definitions and anything unnecessary for my specific port for maintainability. The many macro if/else make the code very difficult to read and I try to minimize this. I understand that you probably do have to keep all of this in here to avoid code repetition.


    I do not include core_cm4.h directly. Just pointing out the code. I made a mistake and included the FPU rather than MPU definition from core_cm4.h. It was a late night.


    I didn't realize that the support email was still active. So many companies have moved to a forum. We are in the process of purchasing the EMBOS license so I will send urgent requests there and post others here.


    The JLINKMEM stuff threw me. I didn't know whether I needed or not so lost some time there. I thought RTT was the name of the game these days.


    I understand that most embedded engineers will just include whatever they are given but there are a few of us that try to keep code tidy in the spirit of future maintenance.

  • Dear Kenny,

    Kenny wrote:

    I also use C++ and have my own classes for the peripherals including the NVIC. Generally defining SysTick_Handler and OSHW_Init() are pretty straight forward but I also remove many of the very sparse comments and macro definitions and anything unnecessary for my specific port for maintainability. The many macro if/else make the code very difficult to read and I try to minimize this. I understand that you probably do have to keep all of this in here to avoid code repetition.

    Many of the #if/#else directives used in RTOSInit originate from the different communication channels associated with embOSView. Furthermore, in regards to RTOSInit_STM32F4x_CMSIS.c, this specific file was intended to fit several different hardware setups, and thus includes different initializations for different USARTs used with different eval boards. I fully agree that this adds to a rather crowded impression. Usually, however, our start projects do not contain more than one USART initialization, and in some cases we may completely omit any USART initialization in favor of communication via Jlink. The resulting source files effectively are much easier to maintain. Other #if/#else directives target different compilers or other mandatory aspects and thus may, unfortunately, not be omitted. However, we are constantly striving to make our source code more convenient to work with, and thus have just recently re-thought some of the macro definitions used in our RTOSInit files, effectively rendering the source code even more readable and maintainable. These modifications will be integrated in future releases of embOS and embOS-MPU.

    Kenny wrote:

    In terms of clean up I'm only touching RTOSInit_STM32F4x_CMSIS.c. In that file a couple of NVIC registers and several UART registers are defined. I prefer to have them defined once in the CMSIS header. I'm not sure why you would do this at all.

    We'd usually do this for compatibility reasons. For example, we've seen cases in which, while sporadic, the device speficic files were altered in a way that was incompatible to a previous version. Still, we're always open for suggestions and improvements, hence we'll likely address this as well in the near future.

    Kenny wrote:

    I didn't realize that the support email was still active. So many companies have moved to a forum.

    We rather see the forum as a valuable addition to our regular support, which itself is offered via email. For further information, please also refer to the User & Reference Guide for embOS, which includes a dedicated chapter on our support.

    Kenny wrote:

    The JLINKMEM stuff threw me. I didn't know whether I needed or not so lost some time there. I thought RTT was the name of the game these days.

    JlinkMEM is used exclusively for communication with embOSView. There's no need to keep it if you don't intend to use embOSView, or else prefer a serial connection to do so.

    Best regards,

    Martin
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.