5 Replies Latest reply on Feb 21, 2017 11:40 AM by jim_reich_1873026

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

    jim_reich_1873026

      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!