11 Replies Latest reply on Oct 23, 2014 4:04 PM by userc_42157

    global variables stopping program execution

      We have a program developed (PSoC Creator) by a consultant that runs on a CY8C3244PVI-133 chip. It ran properly on an earlier compiler (late 2013), but now stops at the first program line where a global variable is used. He has defined these (4) global variables immediately above the main.c routine as follows:


      float32 gfTimeScale;
      float32 gfAnalogRange;
      int16 giLastAnalog;
      uint8   gbPhase;


      We are building this project under PSoC Creator 3.0 SP2 (10/2/14) and it builds fine.  But running it under the debugger fails the first time one of the above variables is assigned (whether hardcorded at a numeric value, or calculated from simple arithmetic).  Is it now illegal to define global variables this way (Keil 9.51)?  We have tried everything we can think of to solve this problem but the program halts as soon as any of these global variables is used in a line of code, without any explanation other than that the program stopped at that line (and the global variable value shows as 0 on a mouseover within the debugger after program halt, even though it may be a simple assignment).  For example, like this:


          gfAnalogRange = MAX_ANALOG_VAL - MIN_ANALOG_VAL;


      Both MAX_ANALOG_VAL and MIN_ANALOG_VAL are correct on a mouseover (4220 and 212, respectively).  The program halts on this line.  If we hardcode the value for gfAnalogRange as:


          gfAnalogRange = 4008.0;


      the program halts on that line which is a simple assignment.  Anyone know what is happening here?  Thank you.



        • 1. Re: global variables stopping program execution

          When you compile your project with setting "Release" it may stop anywhere when debugging.


          Make sure you did set the Build Configuration to "Debug" (main window menu item).


          If all fails you can post the complete project here so that we all can have a look at all of your settings? To do so, use
          Creator->File->Create Workspace Bundle (minimal)
          and attach the resulting file.


          If that cannot be done, create a technical case to Cypress. At top of this page "Support&Community->Technical Support ->Create a MyCase"

          • 2. Re: global variables stopping program execution



            Thanks for the reply.  We do have the build set to Debug.  Attached is the "minimal" project archive.  As mentioned, this did run OK at one point and there are no changes to the code since then ... just updates by Cypress to the IDE and compiler, etc. so this appears to be some change in how global variables are managed but it is such a simple setup we can't find anything wrong.  Any help would be greatly appreciated.



            • 3. Re: global variables stopping program execution

              P.S. Attached is a screen capture of the error.

              • 4. Re: global variables stopping program execution

                I did not check your program yet, but stopping at the very first executable line in main() is a default setting for Creator. Just go to "Tools -> Options -> Program/Debug ->General" and set the options for "On Run/Reset run to" to "First Breakpoint".


                Alternatively you should be able to resume the progam under debug by typing [F5].


                Can you tell me if this settles your question?





                • 5. Re: global variables stopping program execution



                  This does let the program run, so thanks for that info.  The reason we got into this debugging effort is because the program does not appear to be running when we program new chips with the .hex file, which is all we had done before (using only the PSoc programmer ... we only had this .hex file so just followed the steps given to us to program new chips).  So we got Creator and learned how to connect the device and run this debugger, and saw that the program was stopping.  Apparently we misinterpreted this as the smoking gun for our problem as it explained our observations (ie. no program running on new programmed chips based on no outputs), but it appears it was a red herring, unfortunately.


                  But now that the program is running we can look at more variables and try to find the real problem. This system acts as a phase shifter for a 62.5 KHz input square wave, but when we run it now we get no shifted output, and no output on a monitor DAC pin, so assumed the program was not running for some reason and thought we had found the problem.  Looks like more headaches ahead though.  Thanks again for the help, and we can now chase down more variables and hopefully find out what is going wrong.

                  • 6. Re: global variables stopping program execution



                    there is an error in the main loop handling the ADC.


                    The ADC is started for a conversion, but the following "if" does not wait for a completion as the comment suggests, instead a new conversion is started. The line should read







                    • 7. Re: global variables stopping program execution



                      Thanks.  I replaced the original line of code with your replacement, but it didn't change the behavior (I cut/pasted your line directly from this forum text box, and commented out the original).  However, I was able to confirm that the DAC output is working by hardcoding several values and seeing the correct result on a voltmeter.  This program is supposed to read a 0-1V signal into the ADC (pin 18), then produce a 0-4V proportional output voltage (in addition to the 62.5 KHz phase shiting, but the DAC output is a simple offset and scale of the input voltage, independent of the fancier square wave shifting code).  But watching the ADC input values in the debugger shows that they don't change no matter what voltage is applied to pin 18.  So it does appear that the problem is related to the ADC and it not reading the correct input value (I can measure the voltage on pin 18 and vary it over the 0-1V range so that physical input is correct).


                      I don't know if this is the correct place to put this comment, but I am very happy to pay for some help with this as it now appears to be some code issue and not what we had originally thought (ie. an issue specific to a new compiler).  It is still puzzling why this same program worked before but doesn't now, as the only change was building it in the updated IDE/compiler.  But from the behavior now it does appear that the ADC readings are not coming in properly, so both outputs remain fixed as a result (ie. the 62.5 KHz square wave doesn't shift, and the 0-4V output stays stuck at about 4V, regardless of the 0-1V control input signal that the ADC is supposed to be reading).

                      • 8. Re: global variables stopping program execution

                        In order to get 0 - 1.024 input range for A/D you have to bypass the input buffer, see pic below.




                        Also you are running at 12 bits, but when you write back out to 8 bit DAC, you should


                        right shift 16 bit A/D result by 4, then cast it to 8 bit for the value to write to DAC. That way


                        you will be writing the top 8 bits of the shifted A/D result to the DAC.




                        Regards, Dana.





                        • 10. Re: global variables stopping program execution

                          You might want to consider A/D in continuous mode, see notes below


                          about input settling time each time A/.D is started. If you do move StartConvert( )


                          before for loop.





                          • 11. Re: global variables stopping program execution



                            Thanks ... I'll look into this tomorrow when I can get back to things.  The DAC output seems to be working OK now, but the ADC input values are not changing in the code even though the voltage at the input pin is varying correctly.  So it looks like there is some problem with the ADC reads now even though this same code worked in the past for the same chip and circuitry.  I will try to find the screen you sent the capture of within Creator.