cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC Creator & Designer Software

New Contributor II

Dear Sir, 

   

I did an update on installed PSoC Creator from version 4.01 Update 1, to Version 4.1. After this, I tried to re-compile a project by using the new version. Of course, first I had updated the project components (Project -> Update Components). Unfortunately teh project does not compiled without errors, while in the previous PSoC Creator version the compilation was OK.

   

I received the following error messages:

   

1.  E2713: <sensors(2)> cannot be placed at <P2[2]> because the location does not support the required features: <ROUTABLE>. The placer reported an error.

   

2. E2055: An error occurred during placement of the design.

   

3."C:\Program Files (x86)\Cypress\PSoC Creator\4.1\PSoC Creator\bin/sjplacer.exe" failed (0x00000001)

   

4. The fitter aborted due to errors, please address all errors and rebuild.

   

have you got any idea about this error, or how to overcome it?

   

 

   

Best Regards

   

Bill

0 Likes
Reply
1 Solution
New Contributor II

Hi bobgoar,

   

Finaly I managed to compile the code with PSoC Creator 4.1. 

   

Another problem that faced is that the compiler did not recognize inline functions if they are declared in separate files (.h for function signature, c fr the body). The reason is that the new PSoC Creator is based on GCC 5.4.1 compiler instead GCC 4.5 version. The GCC 5.4.1 uses CNU11 standard instead GNU89.

   

The solution to this is to declare all the inline functions as extern inline.

   

For more information take a look on this: https://gcc.gnu.org/gcc-5/porting_to.html

   

 

   

Thanks

   

Bill

View solution in original post

0 Likes
Reply
50 Replies
Honored Contributor II

Please post your code so we can check it. 

0 Likes
Reply
New Contributor II

Hi bob, 

   

Unfortunately I can't do this, as I have NDA issues with my company

0 Likes
Reply
Honored Contributor II

Did you update your components ?

0 Likes
Reply
New Contributor II

...yes, I have already updated all the projects components. Let me tell you that exactly the same project, is compiled without any error in the previous PSoC Creator IDE

0 Likes
Reply
Honored Contributor II

I just tried a program for a Psoc 5lp and it compiled fine.

0 Likes
Reply
New Contributor II

Actually the Project is base on a PSoC 4 device (CY8C4248LQI-BL563)

0 Likes
Reply
Honored Contributor II

I need your project so I can check it. I just tried an example Ble program an it was okay. 

0 Likes
Reply
Honored Contributor II

I tried your chip with an example program it was okay. Please post your code.

0 Likes
Reply
New Contributor II

Hi bobgoar,

   

may be i prepare a version for update, but let me ask you what exactly have to have. All the project? May be zip it and upload it here

   

 

   

Bill

0 Likes
Reply
New Contributor II

Hi Bobgoar

   

Here is my project..

   

 

   

Thanks

   

Bill

0 Likes
Reply
Employee

The error indicates an issue with the fitter which takes care of analog/digital routing.  

   

Make two copies of the project.  Open one of them using 4.0, and the other using 4.1.  Check if pin allocations are same in the two projects.  Maybe pin allocations got messed up during the update process.

0 Likes
Reply
New Contributor II

Good Morning graa,

   

I have already checked the pin allocations and are exactly yhe same for the 4.0 & 4.1 version of the project. Also the source code and all the files are the same for the two versions...

0 Likes
Reply
Honored Contributor II

Looks like a bug - there is no indication in the TRM or the family data sheet that P2[2] is not usable. What did you connect there?

   

You probably should rais a bug report with Cypress (top right, 'MyAccount/MyCases')

0 Likes
Reply
New Contributor II

Hi hli,

   

Yeap, it looks like a bug. Exactly the same project was fitted OK by using the previous PSoC Creator version. The only action i did is to update the components (Project -> Update Components). The P2[2] is a digital input, connected on a switch. Also an edge interrupt is assigned at the P2[2].

   

Thanks for your advice. I will raise a Bug Report.

0 Likes
Reply
Honored Contributor II

You can fix the issue by removing uncheck HW connections in the Sensor now it compiles but you have 8 other errors such as  Update_GATT(&FlangePosition, sizeof(FlangePosition), CYBLE_MY_WAKEMEUPPOSITION_CHAR_HANDLE);.

   

0 Likes
Reply
Honored Contributor II

Also you are right at the limits on resources.

0 Likes
Reply
New Contributor II

thanks bobgoar

   

The sensor pins are not hardware connected. But somehow the old PSoC Creator version did not issued an error message for this. Now the fitting is OK, but the compiler issued ...40 errors. All the errors related to undeclared functions. I don't know why. May be the new GCC compiler wants us something different on function definition / declaration

   

Many thanks again

   

Bill

0 Likes
Reply
New Contributor II

Hi bobgoar,

   

Finaly I managed to compile the code with PSoC Creator 4.1. 

   

Another problem that faced is that the compiler did not recognize inline functions if they are declared in separate files (.h for function signature, c fr the body). The reason is that the new PSoC Creator is based on GCC 5.4.1 compiler instead GCC 4.5 version. The GCC 5.4.1 uses CNU11 standard instead GNU89.

   

The solution to this is to declare all the inline functions as extern inline.

   

For more information take a look on this: https://gcc.gnu.org/gcc-5/porting_to.html

   

 

   

Thanks

   

Bill

View solution in original post

0 Likes
Reply
Employee

Hey Bill,

   

So sorry for the problem.  It is actually an error that your design routed in Creator 4.0.1. For some devices, there can be a conflict between Digital Signal Interface (DSI) routing lines and Sequencing SARs with multiple channels.  I will post more later, but if you can change "sensors" to not be on '2' or change the signal on P2[2] so that it is on a different port (or not the same index, [2], as sensors) you can avoid the conflict.

   

We are writing up a knowledge base article and will post something to the Creator start page.

   

Summarizing the conditions where this can occur

   

1. PSoC 4 design using the ADC_SAR_SEQ_P4 component
2. ADC_SAR_SEQ_P4 uses multiple channels
3. A locked, hardware-driven digital pin routed through the DSI shares either the port or pin index as one of the  ADC_SAR_SEQ_P4 inputs.

   

It's actually not all PSoC 4 designs, we are putting together a list.  If your design matches those conditions, it will almost certainly fail.

   

Thanks for posting to the community, and I apologize for the trouble.

   

If you contact me at mdl@cypress.com, I'll have someone from technical support contact you directly.

   

Thanks,

   

--Matt

0 Likes
Reply
Esteemed Contributor II

Hello Matt,

   

so, if I understand correctly, the error existed in Creator 4.0 and is now detected in Creator 4.1 ?

   

 

   

Bob

0 Likes
Reply
New Contributor II

Yeap Guys,

   

The old version did not issue any error or warning message..

   

 

   

Thanks for your help

0 Likes
Reply
Employee

Sorry again for all this.  Is everything OK now?   You have my contact info?

0 Likes
Reply
New Contributor II

Yes Matt, Everything is under control now!!!

   

Many thanks again

   

Bill

0 Likes
Reply
Employee

I'm attaching a draft knowledge base article that one of our engineers put together.

New Contributor II

I was researching why the upgrade to Creator 4.1 gave me the error

<Port2(0)> cannot be placed at <P2[2]> 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!!

--TW

0 Likes
Reply
New Contributor II

Hi Tony,

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.

Bill

0 Likes
Reply
New Contributor II

Hi Bill,

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[2]> 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.)

Any idea???

0 Likes
Reply
Employee

Hey Tony,

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[2] 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[2] 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.  😞

0 Likes
Reply
New Contributor II

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.

Anonymous
Not applicable

Totally agree with the previous comment.

<off topic>

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.

</off topic>

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.

Good luck!

0 Likes
Reply
Employee

Romain, I thought we had addressed all these issues in 4.1.

Do you have an open support case?

--Matt

0 Likes
Reply
Anonymous
Not applicable

Not wanting to hijack this thread, but I do not have a support case. I'm happy to open a new thread to describe the issues if that can help.

Thanks

0 Likes
Reply
Employee

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.

--Matt

0 Likes
Reply
Anonymous
Not applicable

Hi.

   

I have a similar issue with PSOC4 device.

   

My project compiles (and works) on Creator 4.0, but on 4.1 I get the following error:

   

Error: rtr.M0004: E1216: Routing of net ADC_SYNC Failed. Source : :m0s8tcpwmcell_7.tr_underflow, Sink : :p4sarcell.tr_sar_in
Error: rtr.M0004: Error routing design: Routing Failed (12)

   


See the attached project.

0 Likes
Reply
Employee

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.

0 Likes
Reply
Anonymous
Not applicable

Hi, I'm having the same error on the CY8C4245LTI-M445:

   
    

E2713: <CA(1)> cannot be placed at <P1[3]> because the location does not support the required features: <ROUTABLE>.

   
   

The KBA refers to ports 2 and 3, but not to port 1. Is that the same conflict?

   

EDIT:

   

I tried to reproduce in a minimalist project, here attached.

   

I have identified that it is the Opamp_Buffer that causes the error. The project builds if I remove it. (For those interested, here is why I need this op-amp: http://www.cypress.com/blog/psoc-hacker-blog/measuring-vdd-battery-volts-psoc4 )

   

   

Thank you!

   

0 Likes
Reply
New Contributor II

Hi RomainF,

   

I downloaded your project and in my PSoC Creator 4.1 is compiled without any error message!!!

0 Likes
Reply
Anonymous
Not applicable

Hi bascal, I have updated the project in which I can reproduce the error. Please check.

   

Could someone at Cypress provide advices in regards to my application? The PCB is about to hit production. Pin remapping can be considered.

   

Thanks

0 Likes
Reply