Application build problems ADuCM3029_demo_cn0414 using ADICUP3029

I am simply trying to build the ADuCM3029_demo_cn0414 in CCES 2.8.0.0, 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 2.6.0.0?  Please help.

Thanks,

Allan

Parents
  • 0
    •  Analog Employees 
    on Jan 19, 2021 8:01 AM 2 months ago

    Hello,

    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?

    Regards,
    Andrei

  • 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 2.9.3.0.  I commented out the other issues, but using CCES 2.9.3.0 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 2.9.3.0, and I think the problem crosses multiple projects for the ADuCM3029.  I didn't see this type of problem in CCES 2.8.0.0, 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 2.9.3.0. 

    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 2.8.0.0, 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.

    Thanks,

    Allan

  • 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?

    Thanks,

    Allan Haas

  • Hi Andrei,

    I guess there is a more relevant question.  Has the CN0414 Project software been abandoned by ADI?  I ask this because we bought the hardware, and have managed to get the ADI software to work somewhat.  Although, it does produce some strange results using the default settings.  The picture is an Excel plot of the time series from the CN0414, using a ±10 V 10Hz input signal on vin1.  The total signal content is 1,000 samples at 31,250 Samples/second.  Notice how the negative portion of the signal is oddly shaped.  It looks like something is affecting mostly the negative portion of the signal.  Also, the positive portion of the signal is not smooth either; the samples seem to not be continuous in time, with these settings.  Can you identify what is causing this behavior in the CN0414 software/settings? 

     XLSX

    Thanks,

    Allan Haas

  • 0
    •  Analog Employees 
    on Feb 24, 2021 8:27 PM 1 month ago in reply to ahaas@hgiworld.com

    Hi Allan,

    I can assure you that ADI hasn't abandoned this software project.  Can you share a bit more about your hardware setup and test instrumentation being used?  A picture would also be helpful to accompany your description.  

    Cheers,

    Brandon

  • Hi Brandon,

    Thank you for your help.

    I am simply using the CN0414 project hardware (EVAL-ADICUP3029 and EVAL-CN0414-ARDZ) with a function generator that is set to 10Hz at ±10Vpp, an oscilloscope with a 1M input impedance, and Tera Term on my PC as the data collection device.  I used the command "ags vin1 1000", copied the data off the Tera Term window, and pasted it into Excel.  I counted the number of samples, and for a linear time conversion rate, I set the time step to 1/Fs, or 1/31250.  That is the Excel file that I included with my last post. 

    The command "stts" gives the following result:

    >stts

    Status of the application:

    Channel update rate: 100.00000000Hz
    ADC output coding: BIPOLAR
    ADC output data rate: 31250_sps
    ADC filter configuration: s5+s1
    ADC postfilter: DEACTIVATED
    ADC postfilter configuration: opt3 = 20 SPS, 86 dB rejection, 50 ms settling
    To get information on voltage channel status enable open-wire detection.

    Apparently, the conversion time is not linear, making my typical sample interval calculation wrong.  It looks like the channel update rate is the steps in the positive part of the waveform, but the negative part is totally weird.  See the attached photo for the oscilloscope and the CN0414 set-up.  I just used the parameters that were set during project initialization after power up.  I have not tried to control any parameters yet.  Maybe there is a delay being inserted that I am not aware of.  Clearly, I am missing something here.

    Is this helpful?

    Thanks,

    Allan Haas

  • +1
    •  Analog Employees 
    on Feb 26, 2021 12:00 PM 1 month ago in reply to ahaas@hgiworld.com

    Hello Allan,

    Thank you for reporting the bug with the odd sine shape on the negative side. Turns out it was a bug in displaying the floating point negative numbers in the firmware. This pull request should fix that issue.

    Were there any other bugs that you were facing?

    Regards,
    Andrei

Reply Children