I get a warning for a timing violation to the CyHFClk on a UDB Timer clocked by LFClk. Despite having no code errors, the gcc loader errors out. Who can fix this?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
StWa_1982846
Level 3
Level 3
First like received

The timer is set to issue an interrupts continuously at 10 ms intervals. I would ignore the warning, but the gcc loader bombs out -- no other errors and the only other warning is a variable set but not used. Memory space usage is generally less than 50% for this project.

This seems like a serious bug. How can you get a timing violation for the 48 MHz with a block clocked at 37.768 kHz? Doesn't the UDB take care of the clock transitions properly?

Project archive attached.

PSoC Creator 4.2 (4.2.0.641)

OS: Windows 7 Pro, SP1, 64-bit

Kit: CY8CKIT-042-BLE-A

Device: CY8C4248LQI-BL583

Relevant  bits of the Build Report...

Synthesis...

Tech Mapping...

Analog Placement...

Info: plm.M0038: The pin named DspOut(1) at location [IOP=(1)][IoId=(1)] prevents usage of special purposes: F(OA,2). (App=cydsfit)

Info: plm.M0038: The pin named DspOut(2) at location [IOP=(1)][IoId=(2)] prevents usage of special purposes: F(OA,2). (App=cydsfit)

Info: plm.M0038: The pin named DspOut(3) at location [IOP=(1)][IoId=(3)] prevents usage of special purposes: F(OA,3). (App=cydsfit)

Info: plm.M0038: The pin named DspOut(4) at location [IOP=(1)][IoId=(4)] prevents usage of special purposes: F(OA,3). (App=cydsfit)

Analog Routing...

Analog Code Generation...

Digital Placement...

Digital Routing...

Bitstream Generation...

Bitstream Verification...

Static timing analysis...

Warning: sta.M0019: BLE_Environmental_Sensing02_timing.html: Warning-1366: Setup time violation found in a path from clock ( CyHFClk ) to clock ( CyHFClk ). (File=C:\Users\stevewald.AMERICANSEMI\Documents\PSoC Creator\BLE_Environmental_Sensing02\BLE_Environmental_Sensing02.cydsn\BLE_Environmental_Sensing02_timing.html)

API Generation...

Dependency Generation...

Cleanup...

arm-none-eabi-gcc.exe -mcpu=cortex-m0 -mthumb -I. -IGenerated_Source\PSoC4 -Wa,-alh=.\CortexM0\ARM_GCC_541\Release/main.lst -g -D NDEBUG -Wall -ffunction-sections -ffat-lto-objects -Os -lm -c main.c -o .\CortexM0\ARM_GCC_541\Release\main.o

main.c: In function 'AppCallBack':

main.c:101:28: warning: variable 'authInfo' set but not used [-Wunused-but-set-variable]

     CYBLE_GAP_AUTH_INFO_T *authInfo;

                            ^

arm-none-eabi-gcc.exe -mcpu=cortex-m0 -mthumb -I. -IGenerated_Source\PSoC4 -Wa,-alh=.\CortexM0\ARM_GCC_541\Release/ess.lst -g -D NDEBUG -Wall -ffunction-sections -ffat-lto-objects -Os -lm -c ess.c -o .\CortexM0\ARM_GCC_541\Release\ess.o

...

arm-none-eabi-gcc.exe -Wl,--start-group -o "C:\Users\...\Documents\PSoC Creator\BLE_Environmental_Sensing02\BLE_Environmental_Sensing02.cydsn\CortexM0\ARM_GCC_541\Release\BLE_Environmental_Sensing02.elf" .\CortexM0\ARM_GCC_541\Release\main.o .\CortexM0\ARM_GCC_541\Release\ess.o .\CortexM0\ARM_GCC_541\Release\debug.o .\CortexM0\ARM_GCC_541\Release\ACREOdisplay.o .\CortexM0\ARM_GCC_541\Release\cyfitter_cfg.o .\CortexM0\ARM_GCC_541\Release\cymetadata.o .\CortexM0\ARM_GCC_541\Release\Cm0Start.o .\CortexM0\ARM_GCC_541\Release\BLE_Environmental_Sensing02.a "..\..\4.2\Downloads ( 4.2).cylib\BLE_v3_52\Library\gccCyBLEStack_BLE_SOC_PERIPHERAL.a" -mcpu=cortex-m0 -mthumb -L Generated_Source\PSoC4 -Wl,-Map,.\CortexM0\ARM_GCC_541\Release/BLE_Environmental_Sensing02.map -T Generated_Source\PSoC4\cm0gcc.ld -specs=nano.specs -Wl,--gc-sections -lm -g -ffunction-sections -Os -ffat-lto-objects -Wl,--end-group

.\CortexM0\ARM_GCC_541\Release\ess.o:(.data+0x0): multiple definition of `singleSegChr'

.\CortexM0\ARM_GCC_541\Release\main.o:(.data+0x10): first defined here

.\CortexM0\ARM_GCC_541\Release\ess.o:(.data+0x8): multiple definition of `sevenSegChr'

.\CortexM0\ARM_GCC_541\Release\main.o:(.data+0x18): first defined here

.\CortexM0\ARM_GCC_541\Release\debug.o:(.data+0x0): multiple definition of `singleSegChr'

.\CortexM0\ARM_GCC_541\Release\main.o:(.data+0x10): first defined here

.\CortexM0\ARM_GCC_541\Release\debug.o:(.data+0x8): multiple definition of `sevenSegChr'

.\CortexM0\ARM_GCC_541\Release\main.o:(.data+0x18): first defined here

.\CortexM0\ARM_GCC_541\Release\ACREOdisplay.o:(.data+0x12): multiple definition of `singleSegChr'

.\CortexM0\ARM_GCC_541\Release\main.o:(.data+0x10): first defined here

.\CortexM0\ARM_GCC_541\Release\ACREOdisplay.o:(.data+0x1): multiple definition of `sevenSegChr'

.\CortexM0\ARM_GCC_541\Release\main.o:(.data+0x18): first defined here

collect2.exe: error: ld returned 1 exit status

The command 'arm-none-eabi-gcc.exe' failed with exit code '1'.

--------------- Rebuild Failed: 07/02/2018 11:35:21 ---------------

Steve

0 Likes
1 Solution

Ryan, I really appreciate your discussion here - it's stimulating my thought, but I have trouble understanding some points...

    1. How does this unrelated issue create a timing violation in the DspTimer CSB? -- See #5 below.

        - Please point me to something that will help identify anything in the code or design actually causing the timing violation ... it seems to come and go at random.

    3. What is the general rule for using 'clean and build' vs. 'incremental build'?

        - Use 'clean and build', before building, .o, .elf, .hex, .map files which generated during last build will be deleted and regenerated.

       - I meant how do you know for sure when the compile is losing it because it needs a clean-out? Or do you just clean automatically when errors/warnings appear?

    4. Does it make any practical difference to declare a global stringconstant to be 'static', 'volatile', or 'const'?

        - Sorry I realized that I can't tell their differences in a short word...When I met this kind of problems, I always refer to some material in internet, such as: http://sun.aei.polsl.pl/~rstaros/S/Cp3/cp3-5-static%20const%20volatile.ppt

        - I found the ppt above obtuse at best (perhaps if I had the talk to go with it?). This article from the Barr Group is much more understandable:

           Combining C’s volatile and const Keywords «  Barr Code

    5. Why did you add an include for project.h in ess.c right after including common.h which also includes project.h? Do I need to include cytypes.h when also including project.h which also includes it? -- Adding missing project.h include in ess.c appeared to have fixed the the DspTimer timing violation in debug mode, but building the code in release mode can also throw the timing violation with the fix still in place. Ouch.

          - I saw the error details said: "The pin is able to perform some fixed special functions, yet the pin was not used for any of those special purposes. Since the pin is not used for any special purpose, if you lock the pin placement, you will be blocked from using any of those special features in the future."

          - There is no pin directly related to ess.c. What 'error details' are you are talking about? Ahh, there were INFOs about OpAmps which were blocked from being used by some pins connected to the ADC and the Display, which I ignored. How do they relate to the problem?

    6. What was wrong with defining the SegChr strings only in common.h? Why create a 2nd identical set of strings for main.c? If common.h is multiply defining the strings should we not use the "#ifndef COMMONDEFS \n #define COMMONDEFS \n ... #endif" trick? -- Tried that trick just now... didn't work at all to remove multiple defs. Apparently each header file is parsed before the #defines take effect or something.

        - I am confused at this too...

        - Looking for a method of including non-duplicated string definitions for global use by multiple files, including main.c ... I finally found it! One needs to use the 'extern' qualifier, but you cannot set an extern's initial value. So define the strings as extern and arbitrary length in display.h, then set the initial values & sizes in display.c, then use the strings anywhere after including display.h. No more multiple define messages or linker fails.

display.h:

extern const uint8 sevenSegHex[];

extern const uint8 singleSegChr[];

display.c:

const uint8 sevenSegHex[17] = {0xee, 0x28, 0x76, 0x7c,  0xb8, 0xdc, 0xde, 0x68,        // '0' .. '7'

                                                    0xfe, 0xfc, 0xfa, 0x9e,  0xc6, 0x3e, 0xd6, 0xd2, 0u};   // '8' .. 'F' \0

const uint8 singleSegChr[8] = {0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0u};

    7. Is there a build report somewhere that outlines the include-file-tree? How can I get a better understanding how this works? -- it seems I am constantly writing include files ad-hoc and having to trial-and-error the results. For instance: when should I put the include in the .c code file and when in the .h header file?

          - Could this "Code Explorer" window play a role as a include-file-tree?

          - No. There should be some kind of switch that will direct the compiler to list and report the order and usage of all include files by the build, including and especially hidden system stuff.

View solution in original post

0 Likes
4 Replies
RyanZhao
Moderator
Moderator
Moderator
250 sign-ins First question asked 750 replies posted

Hi Steve,

Seems that the error is multiple definition of 'sevenSegChr' and 'singleSegChr'. It may be caused by some .h files included repeatedly. I double-checked your code and did some change. It built successfully. And I think the code changed by myself can be optimized more. 

Thanks,

Ryan

Thanks, Ryan...

But this is mysterious!

  1. How does this unrelated issue create a timing violation in the DspTimer CSB? -- See #5 below.
  2. Why do I get different warnings/errors from debug vs. release builds? I admit the code is buggy, but it doesn't help to have the compiler throwing red herrings and inconsistent results.
  3. What is the general rule for using 'clean and build' vs. 'incremental build'?
  4. Does it make any practical difference to declare a global string constant to be 'static', 'volatile', or 'const'?
  5. Why did you add an include for project.h in ess.c right after including common.h which also includes project.h? Do I need to include cytypes.h when also including project.h which also includes it? -- Adding missing project.h include in ess.c appeared to have fixed the the DspTimer timing violation in debug mode, but building the code in release mode can also throw the timing violation with the fix still in place. Ouch.
  6. What was wrong with defining the SegChr strings only in common.h? Why create a 2nd identical set of strings for main.c? If common.h is multiply defining the strings should we not use the "#ifndef COMMONDEFS \n #define COMMONDEFS \n ... #endif" trick? -- Tried that trick just now... didn't work at all to remove multiple defs. Apparently each header file is parsed before the #defines take effect or something.
  7. Is there a build report somewhere that outlines the include-file-tree? How can I get a better understanding how this works? -- it seems I am constantly writing include files ad-hoc and having to trial-and-error the results. For instance: when should I put the include in the .c code file and when in the .h header file?

Steve

0 Likes

Hi Steve,

     1. How does this unrelated issue create a timing violation in the DspTimer CSB? -- See #5 below.

     2. Why do I get different warnings/errors from debug vs. release builds? I admit the code is buggy, but it doesn't help to have the compiler throwing red herrings and inconsistent results.

          - In debug mode and release mode, the optimization level is different(Emmm...I'm not very sure if there are any other differences). That could lead to some building errors. 

     3. What is the general rule for using 'clean and build' vs. 'incremental build'?

         - Use 'clean and build', before building, .o, .elf, .hex, .map files which generated during last build will be deleted and regenerated.

     4. Does it make any practical difference to declare a global stringconstant to be 'static', 'volatile', or 'const'?

         - Sorry I realized that I can't tell their differences in a short word...When I met this kind of problems, I always refer to some material in internet, such as: http://sun.aei.polsl.pl/~rstaros/S/Cp3/cp3-5-static%20const%20volatile.ppt

     5. Why did you add an include for project.h in ess.c right after including common.h which also includes project.h? Do I need to include cytypes.h when also including project.h which also includes it? -- Adding missing project.h include in ess.c appeared to have fixed the the DspTimer timing violation in debug mode, but building the code in release mode can also throw the timing violation with the fix still in place. Ouch.

          - I saw the error details said: "The pin is able to perform some fixed special functions, yet the pin was not used for any of those special purposes. Since the pin is not used for any special purpose, if you lock the pin placement, you will be blocked from using any of those special features in the future."

     6. What was wrong with defining the SegChr strings only in common.h? Why create a 2nd identical set of strings for main.c? If common.h is multiply defining the strings should we not use the "#ifndef COMMONDEFS \n #define COMMONDEFS \n ... #endif" trick? -- Tried that trick just now... didn't work at all to remove multiple defs. Apparently each header file is parsed before the #defines take effect or something.

         - I am confused at this too...

     7. Is there a build report somewhere that outlines the include-file-tree? How can I get a better understanding how this works? -- it seems I am constantly writing include files ad-hoc and having to trial-and-error the results. For instance: when should I put the include in the .c code file and when in the .h header file?

          - Could this "Code Explorere" window play a role as a include-file-tree?pastedImage_21.png

Thanks,

Ryan

Ryan, I really appreciate your discussion here - it's stimulating my thought, but I have trouble understanding some points...

    1. How does this unrelated issue create a timing violation in the DspTimer CSB? -- See #5 below.

        - Please point me to something that will help identify anything in the code or design actually causing the timing violation ... it seems to come and go at random.

    3. What is the general rule for using 'clean and build' vs. 'incremental build'?

        - Use 'clean and build', before building, .o, .elf, .hex, .map files which generated during last build will be deleted and regenerated.

       - I meant how do you know for sure when the compile is losing it because it needs a clean-out? Or do you just clean automatically when errors/warnings appear?

    4. Does it make any practical difference to declare a global stringconstant to be 'static', 'volatile', or 'const'?

        - Sorry I realized that I can't tell their differences in a short word...When I met this kind of problems, I always refer to some material in internet, such as: http://sun.aei.polsl.pl/~rstaros/S/Cp3/cp3-5-static%20const%20volatile.ppt

        - I found the ppt above obtuse at best (perhaps if I had the talk to go with it?). This article from the Barr Group is much more understandable:

           Combining C’s volatile and const Keywords «  Barr Code

    5. Why did you add an include for project.h in ess.c right after including common.h which also includes project.h? Do I need to include cytypes.h when also including project.h which also includes it? -- Adding missing project.h include in ess.c appeared to have fixed the the DspTimer timing violation in debug mode, but building the code in release mode can also throw the timing violation with the fix still in place. Ouch.

          - I saw the error details said: "The pin is able to perform some fixed special functions, yet the pin was not used for any of those special purposes. Since the pin is not used for any special purpose, if you lock the pin placement, you will be blocked from using any of those special features in the future."

          - There is no pin directly related to ess.c. What 'error details' are you are talking about? Ahh, there were INFOs about OpAmps which were blocked from being used by some pins connected to the ADC and the Display, which I ignored. How do they relate to the problem?

    6. What was wrong with defining the SegChr strings only in common.h? Why create a 2nd identical set of strings for main.c? If common.h is multiply defining the strings should we not use the "#ifndef COMMONDEFS \n #define COMMONDEFS \n ... #endif" trick? -- Tried that trick just now... didn't work at all to remove multiple defs. Apparently each header file is parsed before the #defines take effect or something.

        - I am confused at this too...

        - Looking for a method of including non-duplicated string definitions for global use by multiple files, including main.c ... I finally found it! One needs to use the 'extern' qualifier, but you cannot set an extern's initial value. So define the strings as extern and arbitrary length in display.h, then set the initial values & sizes in display.c, then use the strings anywhere after including display.h. No more multiple define messages or linker fails.

display.h:

extern const uint8 sevenSegHex[];

extern const uint8 singleSegChr[];

display.c:

const uint8 sevenSegHex[17] = {0xee, 0x28, 0x76, 0x7c,  0xb8, 0xdc, 0xde, 0x68,        // '0' .. '7'

                                                    0xfe, 0xfc, 0xfa, 0x9e,  0xc6, 0x3e, 0xd6, 0xd2, 0u};   // '8' .. 'F' \0

const uint8 singleSegChr[8] = {0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0u};

    7. Is there a build report somewhere that outlines the include-file-tree? How can I get a better understanding how this works? -- it seems I am constantly writing include files ad-hoc and having to trial-and-error the results. For instance: when should I put the include in the .c code file and when in the .h header file?

          - Could this "Code Explorer" window play a role as a include-file-tree?

          - No. There should be some kind of switch that will direct the compiler to list and report the order and usage of all include files by the build, including and especially hidden system stuff.

0 Likes