How can I force PSoC Creator to create an AMuxBus connection between P11 and P10?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ChRe_4711096
Level 4
Level 4
50 replies posted 25 replies posted 25 sign-ins

I want to see if I can route a design with the smaller BGA (CY8C6347BZI-BLD53, 116-BGA). This package doesn't have P10.7, which I need as an input to the SARMUX.

I'm already using an external wire to connect from the AMuxBus segment around P11 to the segment around P10, so I'd like to know if it's possible to use the internal switch as well, and how I'd tell PSoC Creator to close it:

Screenshot 2020-11-02 205022.png

the reason why I want to go through another AMuxBus segment is that I need a 3:1 pre-mux as shown above. This already works on another chip, with different pins.

0 Likes
1 Solution

The SARMUX only has control to the MUX_SWITCH0 register. Said that, if you have only two pins (single ended) connected to the AMuxBus, you can handle without CPU intervention (one pin connected to AMUX A, and other to AMUX B). If you have three pins (single ended) connected to AMuxBus, then you need to handle the mux switches with CPU.

View solution in original post

0 Likes
15 Replies
Vasanth
Moderator
Moderator
Moderator
250 sign-ins 500 solutions authored First question asked

Hi ,

If you hover over the switches in PSoC Creator -> CYDWR -> Analog Tab, you can see the register addresses and masks. Which can be used to write the registers to close the switches. But regarding your use case, if you are using Scan ADC, you may not be able to achieve full speed conversion rate as CPU intervention is needed to update these routes in between.

Best Regards,
Vasanth

0 Likes

SARMUX should be able to scan without CPU intervention even with mixed inputs from P10 and AMuxBus, shouldn't it?

0 Likes

The SARMUX only has control to the MUX_SWITCH0 register. Said that, if you have only two pins (single ended) connected to the AMuxBus, you can handle without CPU intervention (one pin connected to AMUX A, and other to AMUX B). If you have three pins (single ended) connected to AMuxBus, then you need to handle the mux switches with CPU.

0 Likes

I've created and attached a simplified project that has the same issue: It uses SARMUX to switch between 4 differential pairs, and one 3:1 pre-mux. This pre-mux is wired to P10 through an external wire, and I want this external wire to become an AMuxBus connection (labeled "A4_n_bus" in the schematic):

Screenshot 2020-11-06 124649.png

I've tried to use a directive but that didn't have any effect at all. Do directives only apply to digital routing?

The analog constraint mentioned in the Net Tie component datasheet is apparently missing in PSoC Creator (why!?), so that approach didn't lead anywhere either.

0 Likes

When going to the smaller BGA, I can only get the fitter to route through AMuxBus if I add an "intermediate dummy" analog pin ("Pin_1"):

Screenshot 2020-11-06 210919.png

It's a start, not perfect (but the extra pin is not necessarily a problem), and might fail in an overall more complex design. Another detail I noticed is that the analog switch for P10.7 is present and used by the fitter, even though the package doesn't provide the pin.

It'd be great if I could assemble the analog routing piece by piece and then somehow export the analog setup into a constraint file.

0 Likes

The problem is that PSoC Creator doesn't allow connecting a mux to another mux. You can trick it by connecting a pin between the muxes, as you did.

Another thing you can do is to not use a mux at all. Just place the default pin from P11 to the SAR MUX directly. Then use DMA or CPU to write directly to the P11 mux switch (PRT11_PORT_SEL0).

0 Likes

Unfortunately, in this application, I want hardware control of the pre-mux to get more slack in CPU and DMA operation.

Isn't there a contradiction between the mux-to-pin-to-mux trick and the limitation that PSoC Creator doesn't allow mux-to-mux? It's still a direct connection, after all.

0 Likes

There is no benefit of placing a Control Register to switch the hardware AMux. It would burn a control cell and PLDs. If you have a state machine that controls the hardware Amux, then it is a good idea to use it.

0 Likes

Yes, the control register doesn't make much sense in this simple demo case other than to have DSI control for the analog muxing. However, had I given you the target project in which I actually want to use the analog muxing discussed here, I'm pretty sure you would have wished for something simpler because it takes ages to build, and crashes PSoC Creator (on my computer at least) quite often.

0 Likes

Another thought: Once I've tricked PSoC Creator to set up the analog part as desired, I can disconnect the extra pin from AMuxBus during initialization and reclaim it for other (digital) purposes. I just need to find out which connections I need to break.

0 Likes

As I had feared, placing the intermediate pin to trick PSoC Creator doesn't work in a more complex design. It does create a connection between P10 and P11, but then fails for the rest of the analog routing.

So again: is there any way to manually enter parts of an analog design other than by placing pins in suitable ports and then hoping for the best?

0 Likes

Don't use a P10 pin as the intermediate pin, use another P11 pin, then repurpose that pin for something else.

Also make sure all pins from P10 are used, so Creator is forced to use the switches from the SARMux and Global Analog Mux.

If it is still failing, can you please share the project?

0 Likes

I've attached two bundles, suffixed good and bad, where the bad one has the direct connection between AMuxBus around P11 and P9/10. The good one doesn't have it, and the application can be generated successfully. I can even route it on the PCB, which is why I couldn't follow your suggestion too closely.

It's not a huge problem though:

  • the required internal analog connection can be made manually
  • not all pins freed by this are actually needed in the final design
  • those pins that are needed can be controlled by software (not by DSI)

Please also check if I'm not mistaken by thinking that I can close the AMux splitter switches manually:

  • close AMUX_SPLIT_CTL6 ("outer" switches") to create a bus with P9.4, P11.1, P12.3 P12,1 P12.0 to SARMUX. P9.4 and P11.1 are disconnected manually.
  • close AMUX_SPLIT_CTL6 ("inner" switches") to create a bus with P9.5, P11.4, P11.3, P12.5 and P12.4 to SARMUX. P 9.5 and P12.5 are discconnected manually.

To my understanding I just had a bit of luck that the individual AMuxBus segments I want to join aren't "crossed" between inner and outer bus on both sides of AMUX_SPLIT_CTL6.

I hope the zip files contain everything you need to generate the application.

0 Likes

This seems to work better, and even in complex designs:

Screenshot 2020-12-06 190954.png

So I create a 3:1 mux with inputs on P11,12,13,0 and the output on P9. The corresponding input to SARMUX is on P10. This forces PSoC Creator to close AMuxBus switch 6, which is necessary to get the internal analog busses aligned between P9/10 and P11 and upwards. I can then retarget SARMUX from P10.0 and P10.1 to AMuxBus during initialization (dashed lines in the screenshot above). I'll post a working minimal example when I have one.

0 Likes

Got a step further! This was kinda tricky and I think that's because it is assumed that PSoC Creator generates what people need and further modifications aren't necessary. However, I somehow managed to find many bits and pieces in the generated source and in the documentation (arch TRM, reg TRM, PDL documentation) and half-guessed how they go together.

Let's start with the overall goal(s) for a minimal working example:

  1. create an application that has a DSI-controlled analog 2:1 pre-mux to SARMUX
  2. SARMUX has 2 inputs (single ended in this case)
  3. we want to connect the 2:1 mux to the corresponding SARMUX input
  4. we use the DAC to output the measured voltage on one of the 2:1 mux inputs (to check for correct output with a scope)
  5. the analog pins previously used for 2:1 mux out (Aout_0) and SARMUX in (Ain_0) shall be freed

Here's the schematic:

pastedImage_3.png

This is the relevant part of the analog routing:

pastedImage_4.png

The crucial part here is that P9[0] is the output of the 2:1 mux which has its input on P12[6..7]. This forces a connection through AMuxBus splitter 6. Great!

P10[2] is the SARMUX input that we want to move to AMuxBus instead of placing an external wire between P9[0] and P10[2].

The reconfiguration is done in three major steps:

  • disconnect P9[0] from AMuxBus
  • disconnect P10[2] from SARMUX
  • connect AMuxBus to SARMUX instead

One thing that has to be done beforehand is to figure out which AMuxBus is used (A or B). That can be done in a number of ways, and looking at the HSIOM selection for P9[0] seemed to be the simplest.

From the generated source I concluded that the initial setup (in cyfitter_cfg.c) sets bits in SAR_MUX_SWITCH0 and SAR_MUX_SWITCH_SW_CTRL. The bits for P10[2] in SAR_MUX_SWITCH0 must be cleared to disconnect the pin, and that is done with SAR_MUX_SWITCH_CLEAR0 (the regs are RW1S and RW1C, respectively). It must also be cleared in SAR_MUX_SWITCH_SW_CTRL but that's more straight forward since that register allows direct read-modify-write.

Reconnecting AMuxBus to SARMUX was a bit tricky, because I didn't expect a write to SAR_MUX_SWITCH0 to be necessary - but it was (is this documented somewhere?).

This is the resulting reconfiguration code:

  ADC_1_Start();

  // disconnect Aout_0 from pin, and reconnect ADC from Ain_0 to AMuxBus internally

  en_hsiom_sel_t Aout_0_hsiom_sel;

  Aout_0_hsiom_sel = Cy_GPIO_GetHSIOM(Aout_0_PORT, Aout_0_NUM);

  Cy_GPIO_SetHSIOM(Aout_0_PORT, Aout_0_NUM, 0); // third param: 0 for GPIO control

  Cy_GPIO_SetHSIOM(Ain_0_PORT, Ain_0_NUM, 0);

  // disconnect SARMUX from Ain_0

  CY_SET_REG32(CYREG_SAR_MUX_SWITCH_CLEAR0, CY_SAR_MUX_FW_P2_VPLUS);

  uint32_t sq_ctrl = CY_GET_REG32(CYREG_SAR_MUX_SWITCH_SQ_CTRL);

  sq_ctrl &= ~CY_SAR_MUX_SQ_CTRL_P2;

  if(Aout_0_hsiom_sel == 0x4)

  { // Aout_0 was connected to AMuxBus-A

    // reconnect SARMUX from I/O pin to AMuxBus-A

    CY_SET_REG32(CYREG_SAR_MUX_SWITCH0, CY_SAR_MUX_FW_AMUXBUSA_VPLUS);

    uint32_t ch0_config = CY_GET_REG32(CYREG_SAR_CHAN_CONFIG0);

    ch0_config &= ~(SAR_CHAN_CONFIG_POS_PIN_ADDR_Msk | SAR_CHAN_CONFIG_POS_PORT_ADDR_Msk);

    ch0_config |= CY_SAR_POS_PORT_ADDR_SARMUX_VIRT | CY_SAR_CHAN_POS_PIN_ADDR_2;// these values are from PDL documentation, chapter SAR -> SARMUX and SARSEQ

    CY_SET_REG32(CYREG_SAR_CHAN_CONFIG0, ch0_config);

    sq_ctrl |= CY_SAR_MUX_SQ_CTRL_AMUXBUSA;

    CY_SET_REG32(CYREG_SAR_MUX_SWITCH_SQ_CTRL, sq_ctrl);

  }

  else if(Aout_0_hsiom_sel == 0x5)

  { // Aout_0 was connected to AMuxBus-B

    // reconnect SARMUX from I/O pin to AMuxBus-B

    CY_SET_REG32(CYREG_SAR_MUX_SWITCH0, CY_SAR_MUX_FW_AMUXBUSB_VPLUS);

    uint32_t ch0_config = CY_GET_REG32(CYREG_SAR_CHAN_CONFIG0);

    ch0_config &= ~(SAR_CHAN_CONFIG_POS_PIN_ADDR_Msk | SAR_CHAN_CONFIG_POS_PORT_ADDR_Msk);

    ch0_config |= CY_SAR_POS_PORT_ADDR_SARMUX_VIRT | CY_SAR_CHAN_POS_PIN_ADDR_3;

    CY_SET_REG32(CYREG_SAR_CHAN_CONFIG0, ch0_config);

    sq_ctrl |= CY_SAR_MUX_SQ_CTRL_AMUXBUSB;

    CY_SET_REG32(CYREG_SAR_MUX_SWITCH_SQ_CTRL, sq_ctrl);

  }

  else

  {

    // error: we don't know which AMuxBus is used

    void;

  }

I've attached the project, but I'm not sure if P9[0] and P10[2] are properly disconnected from the analog internals yet. If someone can enlighten me - please do!

0 Likes