5 Replies Latest reply on Jan 3, 2017 3:59 AM by openpinballproject_1467701

    Pins configured in Creator cydwr/pins tab but need to override in firmware

    openpinballproject_1467701

      I've configured the SPI block in Creator, and configured the MOSI and SCLK pins to be output on P0[4] and P0[6].  In the flash, I have a stored configuration which says whether the SPI block is needed, and if it isn't needed, I want to reclaim those pins as GPIO.  I've tried not calling the SPI_Start(), which calls the SPI_Init(), but the pins are always configured.  The only way I can reclaim those pins is to delete the SPI block (which I can't do since it is needed in some configurations). I have tried change HSIOM (addr 0x40010000) to 0x00000000 to switch it back to GPIO, but that hasn't worked.  What other registers do I need to change to reclaim those two bits.  Thanks in advance,

         

      Hugh

        • 1. Re: Pins configured in Creator cydwr/pins tab but need to override in firmware
          user_78878863

          I think you cannot remove blocks and their routing during runtime. But you can route the SPI outputs through a MUX, and the switch during runtime between the SPI pins and a control register.

          • 2. Re: Pins configured in Creator cydwr/pins tab but need to override in firmware
            openpinballproject_1467701

            That seems different than the PSoC4 Architecture document TRM_001-85634_0C.  Looking at Top Level Architecture drawing (Figure 1-2), it shows the High Speed I/O Matrix with the DSI and GPIOs in parallel.  Using that drawing, it seems that even if I completely configure the SCB to be a SPI and P0[4] and P0[6] to outputs, I should still be able to use the HSIOM to switch back and forth between GPIO and SPI functions.  Setting the HSIOM_PORT_SEL0 register to 0 says "0x0: GPIO: Pin is regular firmware-controlled I/O or connected to dedicated hardware block (Opamp inputs/outputs, SARMUX, SAR reference, LPCOMP inputs) .See the device datasheet for details.  Proper configurations of corresponding GPIO_PRT registers are required to use dedicated hardware
            signals."

               

            The MUX that you mentioned...could that be internal to the chip, or would it need to be an external mux?

            • 3. Re: Pins configured in Creator cydwr/pins tab but need to override in firmware
              user_78878863

              I didn't realize you were talking about the SCB SPI block. For that the pins are hard-routed to the physical pins, so you cannot use an internal mux (which you could use with an UDB SPI block).

                 

              Yes, you can meddle with the internal routing registers. But doing so relies on that the routing never changes 8which is can during a recompile, or a new Creator version). Its also not really documented.

                 

              You could try whether you can make a copy of the SCB SPI component, and can add a mux component between the SCB block and the output pins (I don't think it will work, but it is worth a try).

                 

              When in doubt, raise a support case with Cpyress and ask them directly - they should know best. (and please come back and tell the solution here...)

              • 4. Re: Pins configured in Creator cydwr/pins tab but need to override in firmware
                vsrs

                Hi,

                   

                By changing the HSIOM register it should be possible to reclaim the pins as GPIO. I think you may have to change the drive mode of the pins. The MOSI pins may be in high impedance digital( I am expecting your psoc is slave), which you should change to strong drive. The drive mode change API can be found in SPI_1_mosi_s.c  file. And while writing values on HSIOM register make sure that you are not changing any bits not corresponding to the pin you need.

                Regards,
                VSRS

                • 5. Re: Pins configured in Creator cydwr/pins tab but need to override in firmware
                  openpinballproject_1467701

                  I tried making changes to the HSIOM register, and it didn't work.  (i.e. masking bits I was interested in, and setting to the correct value as GPIO inputs).  The SPI that I am using is a SPI master (uses the SPI data bits to drive neopixels).  In a second case I use those pins as inputs.  (Read a sector in flash to determine whether it is a SPI master, or GPIO inputs at initialization time, it never switches between these two cases).  After exhausting all fo the different possibilities of the HSIOM register, I've decided to try and fix this at a later date by maybe creating a UDB SPI block as suggested by hli.  I need a deep FIFO because that provides me with the interrupt latency that I need.  When I figure it out, I will post back a solution.