I'm sorry you are running into this. I couldn't get your design to route, even unlocking all the pins. Could you submit a technical support case to "http://www.cypress.com/mycases"? Please include the 4.0 version of your project, which should be in the Archive directory.
Let me know the case number when you have it filed. We think this is an issue routing the TCPWM output which we can workaround using a a directive in the DWR. More later.
Hey Romain, as I mentioned in the email you can workaround this by letting CA float. This is similar to what is described in the KBA, but not exactly the same. We need to update the KBA. This from the developer
P1 is associated with the switch from the OA1 1x output to the SAR, so its DSI needs to be quiet. A little less complicated than the port 3/port 2 conflict since at least P1 is the dedicated output pin for OA10. But, like the problem described in the KBA, it's ultimately a silicon limitation.
We should update the KBA to discuss this second problematic situation: The 1x (internal only) is routed to one channel of a multi-channel SAR so you can't use the dedicated 10x pin for that opamp to route a DSI signal.
The ZIP file I've attached contains the 4.0 version. I checked it again right now.
I will open a case.
Is there a case number? I would like to track the progress.
When you file a case, please ask them to refer to Cypress CDT# 282311. I have described the problem and attached your test case (thanks for that). I can give you a directive to work around the problem.
Hi Matt, thanks for the valuable explanation!
I let the CA1 signal float and it got remapped to P3, the project builds now. Thank you! (I have to update the PCB now, damn!)
I'm using all 8 inputs of P2 (PSoC 4200M) as analog inputs, fed in the SAR-ADC as per my sample project. I need to know if all the other signals on P0, P1 and P3 are "safe" now. The board is about to hit production, this is my last chance to re-map anything :)
I just found this KBA, which takes information from the technical reference manual and reasonably distills it. I say "reasonably" because it's a pretty complicated issue.
I was researching why the upgrade to Creator 4.1 gave me the error
<Port2(0)> cannot be placed at <P2> because the location does not support the required features: <ROUTABLE>.
and found this thread. Unfortunately, our PCB goes in production today and it's too late for me to revise the pin assignment. Bummer!!
I am using CYBLE-214009-00 (which has CY8C4248 embedded), three interrupt lines on P2[4:2], and ADC_SAR_SEQ_P4 with 5 channels (P3.0, P3.1, P3.2, P3.3, P3.6). That is the recipe for failure described in KBA220202.
The facts are
1. Creator 4.0 is not capable of catching the conflict between P3.2 and P2.2, and the one between P3.3 and P2.3. So far, Creator 4.0 simply compiles without any error.
2. ADC reading is messed up only when DSI output is driven high at a different pin other than the pin being scanned. That is, in my design, P2.2 goes high while P3.1 is being scanned.
So, will it still work if I use Creator 4.0 and make sure none of P2 pins goes HIGH (ie, change the pins to HI Z) while ADC is scanning its input pins? Thanks for any input!!
In my case the problem was arrived due to an error in pin properties. More specific, I had setup the problematic pin as "HW connected", but actually without any hardware connection at it. Unfortunately the previous version of the PSoC Creator did not issued an error in such a case. As far as I uncheck the HW connection check box at Configure 'cy_pins' menu, the problem solved.
I hope to help you.
Your issue was valid but not the same as mine. I do not have "HW connected" checked, so the error
<Port2(0)> cannot be placed at <P2> because the location does not support the required features: <ROUTABLE>
reported by Creator 4.1 is indeed a routing issue. As Bob put it, " the error existed in Creator 4.0 and is now detected in Creator 4.1".
KBA220202 points out, the error occurs when
1. PSoC 4 BLE design using the ADC_SAR_SEQ_P4 Component
2. ADC_SAR_SEQ_P4 uses multiple channels
3. A locked, hardware-driven digital output pin routed through the DSI shares the pin index with one of the ADC_SAR_SEQ_P4 inputs, and is in port 2.
(However, my case is hardware-driven digital input pin)
It also explains the reason:
if the DSI output line for a pin in port 2 (P2) is driven HIGH, any hardware-controlled SAR switch which uses that line as a control signal connects that input pin to the SAR. If this were to occur at a time when the SAR was scanning a different input pin, it would cause the two inputs to become shorted, causing inaccurate ADC conversion results.
Since my board is already made and too late to change, I am trying to find a firmware solution. Maybe this:
1. stick to Creator 4.0, which is not capable to catch this routing error
2. make sure DSI output enable line is not driven HIGH or detach the pin from AMUXBUS while SAR is scanning a different input pin.
I don't think DSI, being hardware controlled, output enable line can be stopped from going HIGH. But it seems I can detach P2.2 from AMUXBUS temporarily by setting HSIOM_PORT_SEL2 register's bits 11:8 to 0, ie, "Pin is regular firmware-controlled I/O or connected to dedicated hardware block." (ref: page 77 of PSoC 4 BLE TRM.)
Here is what one of the developers told me.
The key point is to ensure that the DSI line itself does not go high. It is not sufficient to simply disable the driver on the pin (by setting OE low).
If that can't be done, your idea of disconnecting one of the problematic pins while the SAR is scanning other channels should work provided you are scanning slowly enough to be able to toggle that in firmware. The easiest and safest way to do this would actually be to turn off the switch between the SAR and P3 during those times. To do this, write a 1 to bit 2 of SAR_MUX_SWITCH_CLEAR0. Then write a 1 to bit 2 of SAR_MUX_SWITCH0 when you want to re-enable scanning of that input. Note that this assumes P3 is a single-ended vplus input, which is what post #38 seems to indicate.
Another workaround: If you do not need the speed of dedicated hardware sequencing, you can also switch the SAR to single-channel mode, put a firmware-controlled analog mux out in front, and manage the sequencing yourself in firmware. The DSI line conflict does not arise when the dedicated SAR sequencer hardware is not in use.
I am so sorry we did not catch this in 4.0. :-(
Thanks, mdl, for taking the time to respond!!
We decide to put the pilot production on hold and re-make the PCB with different pin assignment. Even though it costs us time and money, as well as frustration inside and outside my department, we like the improvement in Creator 4.1, such as CapSense and BLE, and don't want to be locked in 4.01.
We pick your product because we really like it, but this situation is totally unacceptable to your loyal customers, like us. I am not trying to give you a bad time, on the contrary, I want to compliment you and your team on the excellent support to the community. My point is, the Creator team must raise the quality standard in the future.
Totally agree with the previous comment.
There has been a couple of ongoing issues with PSoC Creator which are still not resolved:
- Errors not clearing up with a Rebuild (even with a Clean - Rebuild).
- Linker not always called when Rebuilding.
These aren't big issues, but they tarnish our experience with the tools. A small bug-fix update would be greatly appreciated.
I too was forced a respin of the PCB before entering production when 4.1 was released. It's all good now!
Tony, I believe the workaround of disconnecting the pin from the DSI should work with 4.1 as well.
It is not acceptable. You are being very reasonable.
The team is disappointed we let this out and has done a massive quality audit.
I appreciate you working with us.