If you look at the resources output after a compile on an empty project
you see total availabe pins as 24, 2 used.
I see 24 GPIO total on package drawing.
There are indeed - but I'm not using the two for debugging (except for, well, debugging).
My pins panel shows 21 pins - all GPIO pins except P3, P3 and P1 are assigned - and yet I'm getting this error claiming I'm trying to use 23 out of 22 available pins.
Disabling the external bypass for the ADC, for instance, causes the error to go away. In fact, dropping any one pin from the schematic causes the error to go away, regardless of which pin it is. I can't really see how this can be due to any sort of fundamental internal limitation - and it would be an odd one if it were, preventing one from using all the pins available on the package.
Are you using OpAmps? They have fixed pins routed to their inputs/output, and they cannot be changed. When you use other pins for these connection, the fixed pins get used nonetheless. I'm not sure about what happens when you use the OpAmp pins only internally.
But what you can do: look at the analog design viewer (in the design wiede resources editor), there you can check which components are connected to which pins. You can also look at the (generated) *.rpt file, which shows the "pin listing" and the "analog placement result".
I am using an opamp, with two dedicated pins and one (the + input) routed internally. The + input's dedicated pin is the only one not assigned.
I've now tried deleting every component one at a time; apart from the ADC (because of the bypass pin), none of them affected the pin count.
As Danaa points out, a blank schematic results in two used pins (presumably the debugging ones?) - I can only assume that somewhere there's a limit set based on the reserved number of pins (22), rather than the full number of pins (24), and that's then being compared to the full number of pins including the debug ones, resulting in the error.
I just created an empty project with the CY8C4245, and compiled it. When then looking at the design wide resources, pin view, you see that the SWD pins are assigned, so you have only 22 pins left. When changing the "debug select" config to GPIO, these two pins are free to use, so you have 24 pins available.
The SWD pins are P3 and P3, so this accounts for two of the three pins which are free for you. The third one, P1, is assigned to TCPWM2:P. Are you using PWMs in your design?
Maybe you can share your design, so we can have a look?
Here's simple reproduction steps:
- Create a new PSoC 4200 project. Set device as CY8C4245PVI-482.
- Add a pin component. Untick contiguous and hw connection, and set to 21 pins
- Compile. You will see the 'too many pins' error, despite there being 1 fewer pin than available hardware pins (excluding debug).
Hmm. I did just that, and it compiled... Since it was an analog component, I changed it to digital, and got an error. Though it was a different one than yours:
Error: rtr.M0004: E1216: Routing of net ClockBlock_HFCLK Failed. Source : :m0s8clockblockcell.hfclk, Sink : :ioport4:pin0.in_clock
This error goes away when you configure the inputs as "transparent" instead of synced. So I guess it has something to do with getting a clock signal to the pins?
21 digital outputs (in transparent mode) work. So I tested with 13 outputs, and 8 inputs. Got the same error. When making sure that none of the inputs is on port 4, the error goes away.
Maybe you can try that too?
Oh, found it in the TRM:
- the input sync is done in the so-called "port adapter block"
- port 4 has no port adapter block
- so none of the pins ion port 4 can be synced
- none of the pins on port 4 can be routed through the DSI either (so no connection to anything in UDBs)
So maybe you can solve that by checking what gets assigned to port 4.
I just realised I'm using PSoC creator 2.2. I'll download 3; it sounds like it'll fix it.
Yup, that fixed it! Thanks, and sorry for the trouble, everyone.
It really was the update of Creator? Then it looks like the CyFitter got better with placing the pins with that version...
Yup, updating the creator was the only change I made. But I'm pretty sure it wasn't a fitting issue - but rather an issue where it was comparing (user_pins + reserved_pins) to (total_pins - reserved_pins), effectively double-counting the reserved pins.
I did my tests with Creator 3.0, so its easily possible to get errors with just 21 pins (and yes, I did disable SWD). So it might easily be that Creator 2.2 tried to place all the pins (e.g. outputs) on ports 0 to 3, just to find out at the end that there is an (synced) input which would be placed on port 4 - which is not allowed.