7 Replies Latest reply on Apr 13, 2015 9:13 AM by JoMe_264151

    PSoCCreator 3.0 vs 3.1 uint64 issues

    userc_41591

      Just installed PSoC Creator 3.1 and i found some issues when handling the unsigned long long (uint64) type.

         

       

         

      So i did a little function Test64() and compilled and download to the target board in both versions, then i got the results with the JTAG debugger (Miniprog 3).

         

       

         

      Can be seen that a simple assignment with unsigned is very different and i risk saying that the behavior of PSoC Creator 3.1 is erroneous.

         

       

         

      Anyone has a clue about that ?

         

       

         

      // ARM GCC 4.7.3 (PSoC Creator 3.0 SP2)
      void Test64() {
          unsigned long long w64;
          unsigned int w;
          unsigned a = sizeof(w64);    // 8 bytes
          unsigned b = sizeof(w);        // 4 bytes
          
          w64 = 5;                    // 0x0000000000000005
          w64 = 0x0FFFFFFF;                // 0x000000000FFFFFFF
          w64 = 0xEFFFFFFF;                // 0x00000000EFFFFFFF
          w64 = 0xFFFFFFFF;                // 0x00000000FFFFFFFF
          w64 = (uint64_t)0xFFFFFFFF;            // 0x00000000FFFFFFFF     
          w64 = (uint64_t)0xFFFFFFFFu;        // 0x00000000FFFFFFFF
          w64 = (uint64_t)0xFFFFFFFFull;            // 0x00000000FFFFFFFF
          w64 = (uint64_t)((unsigned int)0xFFFFFFFFu);    // 0x00000000FFFFFFFF
          w64 = (uint64_t)((unsigned long long)0xFFFFFFFFu);  // 0x00000000FFFFFFFF 
          w = 0xFFFFFFFFu;                    // 0xFFFFFFFF
          w64 = (unsigned long long)w;            // 0x00000000FFFFFFFF
               
          w = 10;             
          w64 = (1u << w);        // 0x0000000000000400
          w = 40;
          w64 = (unsigned long long)((unsigned long long)1ull << w);    // 0x0000010000000000
          
      }

       
      // ARM GCC 4.8.4 (PSoC Creator 3.1)
      void Test64() {
          unsigned long long w64;
          unsigned int w;
          unsigned a = sizeof(w64);    // 8 bytes
          unsigned b = sizeof(w);        // 4 bytes
          
          w64 = 5;                // 0x0000000000000005
          w64 = 0x0FFFFFFF;            // 0x000000000FFFFFFF
          w64 = 0xEFFFFFFF;            // 0xFFFFFFFFEFFFFFFF   What ??
          w64 = 0xFFFFFFFF;            // 0xFFFFFFFFFFFFFFFF
          w64 = (uint64_t)0xFFFFFFFF;        // 0xFFFFFFFFFFFFFFFF   didnt work
          w64 = (uint64_t)0xFFFFFFFFu;    // 0xFFFFFFFFFFFFFFFF    didnt work
          w64 = (uint64_t)0xFFFFFFFFull;        // 0xFFFFFFFFFFFFFFFF    didnt work
          w64 = (uint64_t)((unsigned int)0xFFFFFFFFu);    // 0xFFFFFFFFFFFFFFFF   damn, didint work
          w64 = (uint64_t)((unsigned long long)0xFFFFFFFFu);  // 0xFFFFFFFFFFFFFFFF    dont know what to try
          w = 0xFFFFFFFFu;            // 0xFFFFFFFF
          w64 = (unsigned long long)w;    // 0xFFFFFFFFFFFFFFFF
          
          w = 10;
          w64 = (1u << w);                        // 0x0000000000000400
          w = 40;
          w64 = (unsigned long long)((unsigned long long)1ull << w);    // 0x0000000000000000
          
      }

        • 1. Re: PSoCCreator 3.0 vs 3.1 uint64 issues
          dakn_263916

          I would file a CASE on this with a link to this post.

             

           

             

              

             

                    

             

          To create a technical case at Cypress -

             

           

             

          www.cypress.com

             

          “Support”

             

          “Technical Support”

             

          “Create a Case”

             

           

             

          You have to be registered on Cypress web site first.

             

           

             

          Regards, Dana.

          • 2. Re: PSoCCreator 3.0 vs 3.1 uint64 issues
            JoMe_264151

            w64 = 0xEFFFFFFF;            // 0xFFFFFFFFEFFFFFFF   What ??

               

            That is correct!

               

            0xEFFFFFFF = -268435457, now expand that to a 64-bit integer and you'll get a lot of leading "F"s due to sign extension.

               

            Or would you like to have

               

            w64 = 0xEFFFFFFFu;            // 0x00000000EFFFFFFF  no sign extension

               

             

               

            Bob

            • 3. Re: PSoCCreator 3.0 vs 3.1 uint64 issues
              userc_41591

              Bob, have you tested it with the new PSoC Creator 3.1 ?

                 

              With mine, even

                 

              w64 = 0xFFFFFFFFu;            // Results in 0xFFFFFFFFFFFFFFFF

                 

              w64 = 0xFFFFFFFFull;            // Results in 0xFFFFFFFFFFFFFFFF

                 

               

                 

              and the left shift with more than 32bits only returns zero (with PSoC Creator 3.0 it works)

              • 4. Re: PSoCCreator 3.0 vs 3.1 uint64 issues
                JoMe_264151

                The underlying C-compiler is not special for Cypress PSoCs, but is the standard GNU GCC package. So you can be quite sure that such a simple thing as in64 will be handled correctly there.

                   

                I did not run the program which I indeed compiled under Creator 3.1. Instead I checked the generated listing for my main.c which I can find under the "Results"-tab.

                   

                Handling of signed/unsigned integer constants can be platform dependent, so the results might be different, have a look here: stackoverflow.com/questions/11310456/is-the-integer-constants-default-type-signed-or-unsigned

                   

                and here msdn.microsoft.com/en-us/library/aa245308%28v=vs.60%29.aspx

                   

                 

                   

                I cannot verify your results, my toolchain (ARM GCC 484) gives different values from yours.

                   

                There might be an error in the PSoC debugging module when displaying int64, so it is better to check the memory, but I did not check that.

                   

                 

                   

                Bob

                • 5. Re: PSoCCreator 3.0 vs 3.1 uint64 issues
                  userc_41591

                  Thank you for the answer.

                     

                   

                     

                  As it isnt a compiler issue that is generically reproducible, I will try to isolate whats happening.

                     

                   

                     

                  I was testing on a project that i am working on the older GCC/PSoCC3.0. Maybe opening the project on the new PSoC Creator messed with some settings. Need to test on a fresh created one.

                  • 6. Re: PSoCCreator 3.0 vs 3.1 uint64 issues
                    userc_41592

                    Hi

                       

                    I also found strange behavior when debugging uint64 variables.

                       

                    Example:  when the value of my uint64 variable is 900000000 then that value is also displayed in the debugger watch panel.

                       

                    But when I multiplied that value by 100, the result in the debugger is wrong (much larger). It seems that there are added some bits on the left side..

                       

                    Using that value to check if it is between a max and min value, that calculations are right. So the value in the variable is OK but not in the debugger watch panel.

                       

                    Maybe a debugger error?

                       

                    F.Y.I. I’m using the latest version of Creator on a Windows 64-bit PC.

                       

                    Regards,

                       

                    Rob

                    • 7. Re: PSoCCreator 3.0 vs 3.1 uint64 issues
                      JoMe_264151

                      Debugger error confirmed, I'll file a case on this topic.

                         

                       

                         

                      Bob