[SOLVED] Porting an IAR EW for ARM project to SES

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

  • [SOLVED] Porting an IAR EW for ARM project to SES

    I am trying to port a project that was written in IAR Workbench for ARM to Segger Embedded Studio. This project was built for an nRF52832 and compiles well with both, IAR and GCC toolchains. According to NordicSemi, the version that is supported by their nRF5 SDK (15.2) requires SES 3.40. So, I installed SES 3.40 for ARM. Additionally, I installed the nordic nRF package.

    I run into a couple of issues that have to do with toolchain configuration though.

    1) In the project, several settings have been defined in a specific headerfile, let's call it "mysettings.h" for the sake of argument. The headerfile is automatically included in IAR's workbench project before compilation of each C module through an IAR EW IDE setting called "Preinclude file". In GCC, I can do the same by specifying "-include mysettings.h" on the commandline. I read SES uses the GCC compiler, but it won't accept the -include argument - not through the IDE nor on the commandline. I can't find a similar setting in the IDE either. Is it possible to "Pre-include" a file somehow?

    2) The environment keeps complaining my license has expired (I installed SES a couple of years ago on this machine...). According to the NordicSemi website, SES is free to use with nRF5x. How do I tell SES about this? Again, NordicSemi's website shows a popup that should be generated by SES that seems to provide a dropdown box where we're supposed to request a license with, but I have never seen that popup. Help?

    3) I require an uninitialized global structure (its contents should survive a reboot of the system). In IAR, there's a language extension modifier named "__no_init", but that is very much IAR specific. How can I keep SES from initializing the variable?

    4) The implementation of C11 seems incomplete. Where is stdatomic.h for example?
  • Hello,

    Thank you for your inquiry.
    1: It is not necessary to port IAR projects if you are using Nordic SDK. The latest SDK already has working Embedded Studio projects. For e.g. the blinky project you can find the emProject file under examples\ble_central\ble_app_blinky_c\pca10040\s132\ses
    If you still need to import some non Nordic SDK example from IAR the following guide can be used: wiki.segger.com/SEGGER_Embedde…to_SEGGER_Embedded_Studio

    2: The license prompt should come up once you try to build any project without a license, see picture attached. Simply press "Activate your free license".
    Keep in mind this license will only be valid for projects where a Nordic target device is selected.

    3: ES uses gcc so you can use __attribute__ ((section (".noinit"))) and place the struct in the noinit section.


    4: Atomics are not part of the C11 gcc default but are optional. Optional libraries can be added by the user. More information can be found in the Embedded Studio Manual.


    Best regards,

    Nino
    Images
    • Capture.PNG

      30.32 kB, 735×481, viewed 432 times
    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.
  • SEGGER - Nino wrote:

    1: It is not necessary to port IAR projects if you are using Nordic SDK. The latest SDK already has working Embedded Studio projects.
    Thanks, but that is not the issue. I have a real-world project that was set up in IAR and need to be worked on off-site. It uses some language extensions and some things like said stdatomic that is supported by native GCC for ARM.

    The remote party uses SES, therefore I have to put a porting effort in this. Most of it is easy, handled by the import-wizzard and described in your manual, little to worry about that. The hard part is linker/locator-stuff which is not handled by the wizard. Probably solvable though.

    However. We have the habit of using a single includefile to store all the generic control-macro's in. They must be available throughout the whole program. I do not want to hide these in an IDE somewhere. That's why we use the pre-include feature from IAR for (or add it to the CFLAGS in the Makefile for GCC through said -include option). Doesn't work though in SES. How can I do that?
  • Hello,

    Thank you for explaining your setup.

    jev wrote:

    However. We have the habit of using a single includefile to store all the generic control-macro's in. They must be available throughout the whole program. I do not want to hide these in an IDE somewhere. That's why we use the pre-include feature from IAR for (or add it to the CFLAGS in the Makefile for GCC through said -include option). Doesn't work though in SES. How can I do that?
    This can be done using global macros under Tools->Options->Building->BUild->Global Macros.
    These will be available across all your ES projects and can be simply called by the macro you defined.
    Is that what you were looking for?

    Best regards,
    Nino
    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.
  • Unfortunately, the solution you mention is merely a method that still hides the macro definitions somewhere in the IDE. We'll just have to live with it I guess, if there just is no way to do pre-include the header we'll just have to document them in such a way they won't be "forgotten about". Fair enough.

    Thanks for your help anyway Nino!
  • Hello,

    What exactly do you mean by hiding it or to turn the question around, when would it not be hiding?
    For example I create a global macro called TestMacro=C:\Test.
    If I now go to my project settings and want to set an option that supports macro extension e.g. "Additional Assembler Options" and edit that I get the attached window.
    With the arrow (red circle) the macro list can be expanded.
    As you can see my global macro is also documented there.

    Best regards,
    Nino
    Images
    • Capture.PNG

      22.08 kB, 471×476, viewed 416 times
    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.
  • SEGGER - Nino wrote:

    If I now go to my project settings
    At that exact point you start "hiding" the setting in a vendor-specific way because one needs the IDE installed and up and running to see it. I can't see the definition in the sourcecode, I can't see 'm in a makefile (note: "make" is a defacto standard, every engineer should be able to read makefiles IMHO). If I want to add definitions, I can't just take out vi or emacs (insert your favorite editor here) and create them - I need to go through the SES IDE or weird things might happen.

    My personal definition is: as soon as somebody needs to learn something about the build environment other than "make" and "cc" to get things up and running, it is vendor-specific and should be avoided as much as possible.

    "When would it *not* be hiding?", was your question. Simple rule of thumb: when its definition is available in a .c or .h file that is part of the project it is not hidden. Most IDE's have some kind of functionality to find a definition if you right-click on a macro. As soon as the IDE is not capable to find its definition, it is hidden. Just to illustrate: sdk_config.h in the Nordic SDK is a configuration file. It starts with:

    #ifdef USE_APP_CONFIG
    #include "app_config.h"
    #endif

    The macro USE_APP_CONFIG must be available throughout the whole program. In SES, it is a "hidden" macro. If I right click on it in the IDE (or press ALT+G), SES can't find its definition. In other IDE's, I can put this macro in a generic include file that is automatically included before compilation of any module. In IAR, I can right-click it and the IDE will jump to its definition.

    The post was edited 2 times, last by jev ().