3 Replies Latest reply on Mar 18, 2016 8:59 AM by user_1377889

    Shouldn't Pin_Write(1u) keep pin high forever?

    user_13524663

      I am working through Alan Hawes' videos using the PSoC 4 BLE and am extending his code from the following video:

         

      http://www.cypress.com/video-library/PSoC/psoc-4-ble-101-5-using-capsense-bluetooth-low-energy/108391?tid=84506&sort_by=created&form_build_time=0.95414400

         

      To start experimenting with the API I am going to use the LED connected to a pin to indicate whether something happened or not. To start, I use the following code to turn the LED on as CYBLE_ERROR_OK must be returned (the slider function works fine):

         

      int main()
      {
          CYBLE_API_RESULT_T thingy;
          
          CyGlobalIntEnable; /* Enable global interrupts. */

         

          /* Place your initialization/startup code here (e.g. MyInst_Start()) */
              
          CapSense_Start();
          CapSense_InitializeAllBaselines();
          CapSense_ScanEnabledWidgets();
          
          thingy = CyBle_Start(Stack_Handler);
          
          if(thingy == CYBLE_ERROR_OK) LED_Write(1u);

         

          for(;;)

         

          {

         

      When I turn on or reset the board the LED turns on and then turns off. I think that it should remain of forever, or until I turn the board off. I have

         

      - disabled "HW connection" under "Digital output",

         

      - set the "Drive mode" to "Strong drive"

         

      - left all other pin settings at their default

         

      - pin name is now "LED"

         

      - set pin 43 (P2[6]) as the LED connection

         

      I have tested the following added immediately after the "if" line shown above:

         

          CyDelay(500);
          LED_Write(0u);
          CyDelay(500);
          LED_Write(1u);

         

      This causes the LED to blink, so I know that my code is working, just not as I expect it to. I expect the LED to remain on after the for(;;) loop is entered. That blinking code also works when made part of the "if" statement showing that "thingy" did indeed equal "CYBLE_ERROR_OK". 

         

      What am I not understanding about pins?

        • 1. Re: Shouldn't Pin_Write(1u) keep pin high forever?
          user_1377889

          Probably the PSoC is sent to deep sleep thus saving energy.

             

          As long as you are trying to understand the PSoC's internal handling I would suggest you not to enable the BLE radio and use the Kit just for programming pins, timers etc.

             

          In case you got stuck (as here) it is always advisable to post your complete project, 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.

             

           

             

          Bob

          • 2. Re: Shouldn't Pin_Write(1u) keep pin high forever?
            user_13524663

            Bob,

               

            Now I feel really stupid. I assumed that the LED would light when the pin was held high. It won't because the Pioneer's schematic shows that pin needs to be grounded for the LED to light. So I changed my code to:

               

            if(thingy == CYBLE_ERROR_OK)  LED_Write(0u);

               

            and it stays lit, as the board was designed. I suppose that I was thrown by the fact that the LED even turned on when the pin was connected to V+. Had the LED not lit at all, but the slider function still worked, I would have realized my wrong assumption immediately. 

               

            So, now my question is, why would connecting the LED's cathode to V+ cause it turn for a short period? Is it due to how PSoC connects its pins?

               

            Sincerely, Jeff

            • 3. Re: Shouldn't Pin_Write(1u) keep pin high forever?
              user_1377889

              I suppose the LED is not lit by your LED_Write(), but by the initialization routines. Place a breakpoint on your write and watch what happens...

                 

               

                 

              Bob