Application build problems ADuCM3029_demo_cn0414 using ADICUP3029

I am simply trying to build the ADuCM3029_demo_cn0414 in CCES, as it currently exists.  I'm new to the CCES environment, and have not modified any of the code to reflect my particular application.  I had lots of problems with unresolvable, and conflicting variables as I tried to get the thing to build.  The problem was endemic to all of the projects that were installed into the IDE.  It looked like something major was missing somewhere.

Depending on which CMSIS pack or combination of packs was installed, the unresolvable variables problem seemed to change somewhat.  I found and installed the CMSIS development pack 5.7.1 -dev0, and that seemed to fix the unresolvable variables problem.  That made me feel good, but other problems became visible, now related to the RTE.

I found one EZ article from someone who was having problems getting blink to work because of conflicting variables in the RTE file startup_ADuCM3029.c .  The ADI engineer suggested commenting out the four linker related external variables that were causing the conflict; done.  That allowed another problem to become visible, .../RTE/Device/ADuCM3029/system_ADuCM3029.c:378:31: error: 'NVIC_INTS' undeclared (first use in this function).

I don't know how to get this thing to work.  Am I going to keep exposing more problems as I go along?  What am I missing?  Do I need to rollback CCES to  Please help.



  • 0
    •  Analog Employees 
    on Jan 19, 2021 8:01 AM


    There should be no more problems after commenting lines in system_ADuCM3029.c that refer to the already defined variables. I would suggest trying with CCES 2.9.1 or higher and ARM.CMSIS 5.6.0 first. Do you still encouter problems like this?


  • Andrei,

    Thank you for your reply.  I think the problem with my project may be a bit more complex than you and I think. 

    I started using CCES  I commented out the other issues, but using CCES caused other problems to show up.  It looks like the GPIO driver and possibly other drivers for other elements of the project/processor combinations is messed up in CCES, and I think the problem crosses multiple projects for the ADuCM3029.  I didn't see this type of problem in CCES, once I got the right CMSIS pack combination installed.  I can't figure out how to get the GPIO variables to resolve in the CCES 

    Maybe it's buried somewhere in the CMSIS packs or elsewhere, but I can't tell where.  There must be some sort of combinations of the CCES CMSIS packs or system RTE configuration that needs to be enabled to get it to work.

    In CCES, I do not have the unresolved variables problem.  Instead, I get the following error message (Additional CRLF added to make the lines more readable) as the final build message output after building project ADuCM3029_demo_cn0414:

    'Building target: ADuCM3029_demo_cn0414'

    'Invoking: CrossCore GCC ARM Embedded C Linker'

    arm-none-eabi-gcc -T"C:\Analog Devices\CrossCore Embedded Studio 2.8.0\ADICUP3029 Workspace\EVAL-ADICUP3029-master.zip_expanded\EVAL-ADICUP3029-master\projects\ADuCM3029_demo_cn0414/RTE/Device/ADuCM3029/ADuCM3029.ld" -Wl,--gc-sections -mcpu=cortex-m3 -mthumb -specs=nosys.specs _RTE_ __ADUCM3029__ __SILICON_REVISION__=0x102 "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/ARM/CMSIS/5.7.1-dev0/CMSIS/Core/Include" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/ARM/CMSIS/5.7.1-dev0/CMSIS/Driver/Include" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/ARM/CMSIS/5.7.1-dev0/CMSIS/Driver/VIO/Include" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADI-BleSoftware/1.0.1/Include/communication" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADI-BleSoftware/1.0.1/Include/communication/ble" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/adc" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/beep" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/crc" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/dma" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/flash" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/gpio" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/i2c" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/pwr" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/rng" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/rtc" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/spi" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/sport" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/tmr" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/uart" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/wdt" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/ADuCM302x_DFP/3.1.0/Include/drivers/xint" "C:/Analog Devices/CrossCore Embedded Studio 2.8.0/ARM/packs/AnalogDevices/EV-COG-AD3029LZ_BSP/3.1.0/Include" "C:\Analog Devices\CrossCore Embedded Studio 2.8.0\ADICUP3029 Workspace\EVAL-ADICUP3029-master.zip_expanded\EVAL-ADICUP3029-master\projects\ADuCM3029_demo_cn0414/RTE" "C:\Analog Devices\CrossCore Embedded Studio 2.8.0\ADICUP3029 Workspace\EVAL-ADICUP3029-master.zip_expanded\EVAL-ADICUP3029-master\projects\ADuCM3029_demo_cn0414/RTE/BLE" "C:\Analog Devices\CrossCore Embedded Studio 2.8.0\ADICUP3029 Workspace\EVAL-ADICUP3029-master.zip_expanded\EVAL-ADICUP3029-master\projects\ADuCM3029_demo_cn0414/RTE/Device/ADuCM3029" -o  "ADuCM3029_demo_cn0414" @input-file.txt -lm

    arm-none-eabi-gcc: error: _RTE_: No such file or directory

    arm-none-eabi-gcc: error: __ADUCM3029__: No such file or directory

    arm-none-eabi-gcc: error: __SILICON_REVISION__=0x102: No such file or directory

    make: *** [ADuCM3029_demo_cn0414] Error 1\

    It looks like _RTE_, __ADUCM3029__, and __SILICON_REVISION__ are variables of some sort, and the errors associated with them seem to indicate that they are somehow referred to in file names or directories.  Maybe this is an unfortunate compiler mislabeling of the problem, but I cannot tell.  These variables are defined in the .cproject file in the main project directory, and are referred to multiple times in the file. 

    Unfortunately, this whole thing is a bit tricky to use, because of all of the things that have to be unpacked, installed, and enabled.  This looks like some sort of set-up problem, but I cannot tell what I am missing in the set-up.  Therefore, I don't know how to resolve this problem.  The project will not completely compile, and as such, I cannot get the project off ground zero.

    There is another error in the ADuCM3029_demo_cn0414/RTE/Device/ADuCM3029/adi_adc.c file that is flagged as a self reference that maybe should be defined in another way, but I did not write the code.

              /* Clear the status bits */
              pDevice->pReg->STAT =  pDevice->pReg->STAT;

    Apparently, this shows up in two places, only in the adi_adc.c file in the ADuCM3029_demo_cn0414 project.  I do not know what the compiler does when it finds such a statement.  However, this problem did not stop the project build.  In fact, you have to search the project to find it.

    Please help.



  • 0
    •  Analog Employees 
    on Jan 22, 2021 7:24 PM in reply to

    Thanks Allan for the follow up.  Glad things are now working for you.



  • I found a new problem.  I cannot figure out how to disable semihosting.  All of the wikis and other information related to that seems to be out of date with respect to my CCES  The instructions refer to things that I cannot see or find.  I've looked everywhere.  Would you please tell me how to disable semihosting in CCES



  • +1
    •  Analog Employees 
    on Jan 25, 2021 10:13 AM in reply to


    This is in 2.9.1. You have to go to the project properties by right-clicking on the project.

    Then you must go to the Setting menu under the C/C++ Build dropdown and go to the Libraries option From the CrossCore GCC ARM Embedded C Linker Dropdown, just like in the picture. There, the semihosting support option has to be set to nosys.specs.

    It should be the same process as in 2.8.0.

    Please be sure to clone the project from the Github repo. If you clone it all these settings should already be in place.


  • Thanks Andrei, that worked.  As I try to learn how to use the CCES IDE and the ADICUP3029, I am running some of the simple example codes such as blinky_example, and uart_autobaud_example.  Both of these worked just fine.  I was able to (after commenting out the conflicting variables) compile, download, and run both of those examples, repeatedly and interchangeably.  In both cases the onboard debugger was enabled.  I was able to stop the debugger and run both examples in stand alone mode, without the debugger running.  All is well with these test programs. 

    I wanted to get as many simple test programs as possible to run, before I started on the more complex examples that use more hardware.  That brings me to the latest problem.  I thought that the command line interpreter example, ADuCM2039-demo_cli example program, would be easy to run.  After all, it does have it's own wiki (  Unfortunately, this one is not working for me; I am able to compile the code, but it will not download to the ADICUP3029.  It looks like the debugger is enabled, but since the code did not download, it automatically terminates.  If blinky_example was already installed, it remains installed after running the ADuCM2039-demo_cli in CCES, which should compile, download, and run the code with the debugger enabled.

    I noticed that there were some significant changes to portions of the project that are shown in github through, but the updated project code is not specifically available in github, just the notification of the changes (as I see it).  Is there an updated ADuCM2039-demo_cli that fixes the identified issues, or do I have to make those entries manually to get the project to work?


    Allan Haas

  • Hi Folks,

    I still want to get ADuCM2039-demo_cli example program to work, but in the meantime, I am also now working on ADuCM3029_demo_cn0414.  It looks like there are some patches to the project that have to be done to make it work correctly. I'm not sure how to make these patches.  Can you help me with that?

    So far, I have managed to compile, download, and run the program in its existing state.  I managed to figure out what the terminal window size should be, and am able to get the program to show the splash screen shown in, sort of.  There are some things that show up wrong.  

    This is a window that is 99x60.  Any other size displays completely incorrectly.  The first three lines look right, but the rest don't.  I was able to get the help menu to show up, but none of the commands work.


    Allan Haas

Reply Children
  • Hi Folks,

    Okay, I got the terminal to display the intro screen properly.  Sorry about that, I had a couple of settings incorrect.  Still, the only thing that works is the h command, and only once immediately after program start.  The "help" command does not work either.  The command prompt only returns after the first use of the h command.  After that, regardless of the command, including h, the command prompt never returns.  Do the project patches fix the problems and get the project to work?  What am I missing?


    Allan Haas

  • Folks,

    I found the major problem with the project not working.  I needed to install ADuCM302x_DFP.3.2.0.pack.  That took a little bit to figure out.  I managed to install it, and it caused some problems that I mostly figured out.  There's still one problem with two unresolved variables in  pinmux_config.c, but the code seems to work so far.

    Thank you,

    Allan Haas

  • Hi Folks,

    The CN0414 project seems to work, but I have some strange voltage measurement results.  I will get into that later.  In the process of analyzing the ADI software to understand what is going on with the project, I noticed a problematic implementation of the spi_init_param data structure.  This seems like a bug in the code, but maybe you can help me with it.  As it is currently defined in the platform_drivers.h file spi_init_param is:

    typedef struct spi_init_param {
    	enum spi_type type;
    	uint32_t	  id;
    	uint32_t	  max_speed_hz;
    	enum spi_mode mode;
    	uint8_t		  chip_select;
    } spi_init_param;

    and it's subsequent incorporation into another structure is:

    typedef struct {
    	/* SPI */
    	spi_init_param		spi_init;
    	/* Device Settings */
    	ad717x_st_reg		*regs;
    	uint8_t			num_regs;
    } ad717x_init_param;

    which is used to help initialize the AD4111 through the following local variable definition:

    	ad717x_init_param ad4111_ini;

    The structure ad4111_ini is then used to set the parameters for using one of the three available SPI channels to communicate with the AD4111.  The AD4111 is on an Arduino Uno shield, and therefore the SPI port that connects to that shield is the setting that should be used.   It is supposed to initialize the with the following code in the main function of ADuCM3029_demo_cn0414.c:

    	/* AD4111 usage of SPI parameters. */
    	ad4111_ini.spi_init.chip_select = 0xFF; = 0;
    	ad4111_ini.spi_init.max_speed_hz = 4000000;
    	ad4111_ini.spi_init.mode = SPI_MODE_3;
    	ad4111_ini.spi_init.type = SPI_ARDUINO;
    	ad4111_ini.regs = ad4111_regs;
    	ad4111_ini.num_regs = 55;

    The enumerated variables called in spi_init_param are defined in platform_drivers.h as follows:

    typedef enum spi_type {
    } spi_type;
    typedef enum spi_mode {
    	SPI_MODE_0 = (0 | 0),
    	SPI_MODE_1 = (0 | SPI_CPHA),
    	SPI_MODE_2 = (SPI_CPOL | 0),
    } spi_mode;
    typedef enum en_spi_channel {
    	SPI_ARDUINO,	/* SPI0 - used for ARDUINO connector on ADICUP3029 board */
    	SPI_PMOD,	/* SPI1 - used for PMOD connector on ADICUP3029 board */
    	SPI_BLE		/* SPI2 - used to send BLE commands to EM9304 */
    } en_spi_channel;

    Please note that the structure element initialization code, ad4111_ini.spi_init.type = SPI_ARDUINO, uses a reference to an incorrect enumeration variable.  It should be, ADICUP3029_SPI.  Worse yet, there is no reference to the correct enumeration type, en_spi_channel, in the spi_init_param data structure.   So, why does this generally work for this specific application?  Both ADICUP3029_SPI and SPI_ARDUINO evaluate to zero.  I have not traced this down all the way through all usages in this project, or throughout its usage elsewhere in other projects. Therefore, I think the impact is indeterminate for others.

    Does this matter?  I can't tell about other projects, but for my intended expansion of the SPI bus usage to include more peripherals, or even the use of SPI_PMOD and/or SPI_BLE, or anything else with the Arduino SPI interface, this is problematic.  If anything else is used that resolves to greater than zero using that enumeration will likely cause a problem, because there is nothing greater than zero in the spi_type enumeration.

    My solution would be to add another enumerated variable to the spi_init_param data structure,  But that may have big implications within this project, and others.  Also, if it is missing there, is it missing in other data structures that use a similar structure as the spi_init_param data structure for communicating with the ADuCM3029 SPI ports?

    I can see what the code developer was thinking, but he/she must have gotten distracted some time during this code generation and forgot what was going on.  Just guessing, because that happens to me all the time.

    Is it possible for you folks at ADI to fix this problem with a software update?


    Allan Haas

  • 0
    •  Analog Employees 
    on Feb 24, 2021 8:31 AM in reply to


    This is an older project that doesn't use the new framework we have in place right now.

    "ADICUP3029_SPI" was an (even) older enumeration from when the SPI driver was implementing for multiple platforms simultaneously.

    Since then, the platform implementations separated and for the adicup3029 we have "SPI_ARDUINO" which doesn't refer to and Arduino platform, but to the Arduino type connectors on the board (as opposed to the PMOD connector or the SPI that goes to the BLE). It's just letting the driver know where the SPI is routed.


  • Hi Andrei,

    Thank you for your reply.  I am aware of the usage of the Arduino form factor, and I know that the EVAL-ADICUP3029 is not an Arduino machine. 

    We would like to use the CN0414 as a starting point for a new product development R&D.  However, this bug in the CN0414 project software is problematic for my end application.  Also, I am a bit concerned that other bugs may exist that will require some significant software rewriting.  That will defeat some of the rapid prototyping process, if we have to do a significant repair of existing software.

    I would like to be able to use more than one SPI port in my particular application, without having to recreate or rewrite or modify the SPI driver code, and all of the references to it.  Is there an update or newer framework that can be applied to the CN0414 project, or is there a workaround or simple way around the problem?


    Allan Haas