Help! I've run out of PsoC4 control cells!

[Anonymous]

OK, so I'm trying to do a PSoC4 BLE device that has a fair number of blocks, and I seem to have run out of control cells. I'm using a SCB UART, SCB I2C and UDB SPI, the SARMUX ADC, 2 op amps and the 4.2 BLE Stack. I'm trying to add switchable gain by adding 2 AMUXes, but when I do that, the placer fails with no useful error messages (i.e. it just says "the placer has failed" and refers me to the placer section of the .rpt file which, of course, just says the same thing). If I remove one of the AMUXes, it works, and the rpt file shows control cells at 100%. 

   

If I replace the AMUXes with hardware AMUXes and tie the select line to ground, it builds, but then I'd need to add a control register block so I can affect the select line, and when I do that, I still run out of control cells.

   

So my conclusion is that I've run out of control cells.

   

I can use virtualMuxes and have two versions of the firmware, but it seems ridiculous to OTAP 100K+ of Flash in order to just reconfigure the switching fabric. I'm guessing if I dig deep enough into the TRM, I can figure out how to do that via registers... but if it's as simple as that, why can't I do it dynamically via a switchable virtual MUX block?

   

Or is there some other way somebody can think of to recover control cells, or avoid needing them?

   

Thanks!

       

--- 

       

LATE UPDATE:

   

I managed to get this working. It wasn't a lack of control cells.

   

Basically, the solution was to leave the defined op amp pin unallocated and have neither of the AMUX inputs go to the pin that is specified for the op amp. Instead, I picked two unrelated pins for the AMUX inputs -- they were yellow instead of green in the pin map.

   

Then I let the switching fabric route those to the AMUX and thence to the opamp. I guess it makes sense-- if you're already using the external pin that's specific to that opamp as a MUX input, nothing else can use it. But not obvious, and there were two error messages-- one of them wrong ("out of control cells") and the other one useless ("sjplacer couldn't find a solution")

   

Gotta step up the error message quality, Cypress!

[HeLi_263931]

The PSoC4 BLE has quite limited UDB resources (e.g. when compared to a PSoC5). Your best chance is to look at the UDB SPI block and check whether you can reclaim an UDB from it by reconfiguration. Look at its data sheet which explains how many resources are consumed under which circumstances. Depending on your performance requirements, you could replace it by bit-banging the protocol.

[Anonymous]

This SPI is going to an FRAM, so I probably shouldn't bit bang it, too timing critical. I'm not sure I understand how one would reclaim a UDB via configuration, though. But I am certainly getting a case of PSoC 5 envy 🙂

[HeLi_263931]

Apart from the transfer speed, nothing in ther SPI protocol is timing-critical (so ist just getting slower). But for larger amounts of data bit-banging is too slow, I agree.

   

Depending on the actual configuration of the SPI master it uses different amounts of UDBs. Since we don't know how yours is configured, just look at the data sheet and see whether you are already at the minimum number of UDBs, or whether you can change some configuration.

[odissey1]

jim_reich,

   

>I'm trying to add switchable gain by adding 2 AMUXes...

   

Use external resistors to control Opamp gain. Furthermore, the Control register is not required, to save resources pins can be directly written to by CPU.

   

http://www.cypress.com/blog/psoc-insiders-blog/design-idea-analog-gain-controlled-digitally

[Anonymous]

I am using external resistors to control gain, with the AMUXes switching between sets of resistors. Thanks for the pointer-- that article has a bunch more options for me to consider.