PSoC Creator™ 4.2 Analog Router: Analog Routing Fails in PSoC® 4 BLE Design when moving from 128k to 256k Flash – KBA222345

Version: **



Why does a design, successfully built on a PSoC 4 BLE part with 128 KB flash, fail to build (with error apr.M0003: Unable to find a solution to the analog routing) when the design is retargeted to a part with 256 KB flash on PSoC Creator 4.2? Or why does a design targeting a PSoC 4 BLE part with 256k of flash build on PSoC Creator 4.1 but fail to build on PSoC Creator 4.2?



PSoC Creator correctly reports a resource conflict that prevents a valid routing solution.

Due to the manner in which digital control signals are shared, there is a potential for conflict between a digital signal on a pin in the SAR port and a hardware-sequenced opamp output, or vice versa, when the opamp output switch can also be controlled via the digital signal interconnect (DSI). For more details on the reason for this conflict, refer to KBA220202.

On PSoC 4 BLE parts with 128 KB flash, only the output switches for opamps 2 and 3 support DSI control. On parts with 256 KB flash, all four opamps support DSI control of their output switches.

PSoC 4 BLE parts with 256 KB flash have the following constraints:

          1.)  If a pin at port 2, pin 2 (P2[2]) or port 2, pin 3 (P2[3]) has a hardware-routed digital signal, it is not possible for the SAR to scan a signal on P3[2] or P3[3], respectively, using automatic hardware-controlled sequencing.

          2.)  If a pin on P3[2] or P3[3] has a hardware-routed digital signal, it is not possible for the SAR to scan the output of opamp 0 or 1, respectively, using automatic hardware-controlled sequencing.

The first constraint is common to all PSoC 4 BLE parts and is discussed in KBA220202. The second constraint is unique to parts with 256 KB flash.

Note that connecting a pin to the amux bus also consumes that pin’s DSI connection if the pin is in a port connected to the DSI. Due to a defect, versions of PSoC Creator prior to 4.2 did not detect this resource conflict. In these versions, the build succeeds but the SAR potentially encounters a situation where a signal on one channel impacts the conversion results for other channels.


There are three possible workarounds:

1.)  Change the connectivity of the pins on P3[2:3] so that they are not connected to a hardware-routed digital signal.

2.)  If the design only connects two opamp outputs to the SAR, move these opamps to locations 2 and 3.

3.)  If neither of the previous two opamps is viable, but high-speed channel switching is not critical, use firmware-based sequencing of the SAR inputs, which is not subject to the constraints described above. This can be achieved by performing the following steps:

          a.   Configure the ADC component for only a single channel. Set the sample mode to “hardware trigger” and connect a “logic low” component to the “soc” terminal.

          b.   Connect the ADC input(s) to the output(s) of an analog mux component (single or differential as required). ‘

          c.   Use the ADC_StartConvert API to trigger the first conversion.

          d.   After each ADC conversion, use the firmware to copy the result for storage (or perform any other processing as required by the specific application).

          e.   Use the Amux channel select the API to switch to the next input.

          f.    If different channels require different SAR configurations, call the SAR APIs, if necessary, to adjust its configuration for the next channel.

          g.   Repeat steps c to f for each input to complete the scan.