Resistive pull-up/down not working on all pins

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

cross mob
lock attach
Attachments are accessible only for community members.
ChRe_4711096
Level 4
Level 4
50 replies posted 25 replies posted 25 sign-ins

I want to use resistive pull-up/down on a pin and just tried it with P9[6] (CYBLE-416045-02). That resulted in the output looking a lot like "strong drive" (both towards high and towards low, with sharp edges). When I used P10[1] instead, the behavior was as expected. The pin is driven by a PWM block. The architecture TRM (002-18176 Rev. *J) mentions that peripheral IO drive mode is different from DSI IO drive mode, but I don't know which actually applies in my case.

The goal is to use two IOs and a single external pull-up resistor (8k2 or 8k66 to 5V, safe for the clamping diodes) to produce 3-state PWM for an NCP81253 gate driver:

pastedImage_0.png

The pins "pwm" and "pwm_n" are used to see the raw PWM output on a scope.

pwm_H and pwm_L are used together to generate the 3-state PWM output:

  • pwm_L can directly pull the output (TP) low
  • pwm_H can pull the output to mid-level using the internal pull-down resistor when pwm_L is high-Z
  • when pwm_H is high and pwm_L is high-Z, the internal pull-up (towards 3V3) and the external pull-up pull the output to 4V0 (with the internal pull-up being typically 5k6). This is high enough to be interpreted as "high" by the NCP81253.
  • the internal pull-up in pull-up/down mode isn't necessary, but doesn't hurt in this case. If there was a mode that featured resistive pull-down only, I'd use it.

The project is attached.

Questions:

  • Are there any restrictions regarding IO pin drive configuration?
  • If so, where can I find them?
  • Is there any part of IO pin configuration that I overlooked?

My target application (CY8C6347BZI-BLD54 or -BLD34, both 124-BGA) needs 12 resistive pull-up/down IOs, preferably in places that simplify PCB layout, preferably next to another IO configured as open drain pulling low (as in the attached project, for a total of 24 IOs for 12 gate drivers). I don't want to try all of those manually, especially given that I don't have a suitable dev board for that kind of trial and error experiment.

0 Likes
1 Solution

Lo and behold, the pins are handled differently by the toolchain:

  • P9[6] is wired directly as a peripheral output (ACT0)
  • P10[1] is routed through DSI

I found this by reading the HSIOM selection after startup:

pastedImage_2.png

Placing a watch on pwm_h_hsiom allows to observe the value.

For P9[6]:

pastedImage_3.png

And for P10[1]:

pastedImage_4.png

Unfortunately, there's no obvious way to get pin 9[6] back into the desired output mode because with HSIOM_SEL_DSI_ACT_0 I can't de-assert OUT_EN using the OUT register and I haven't found a way to clear a PWM timer's OUT_EN:

pastedImage_5.png

On the plus side, the real application has some routed logic between the PWM and the pin, so it should work as desired because the pin's HSIOM then has to select DSI_GPIO.

View solution in original post

0 Likes
8 Replies
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi,

The architecture TRM (002-18176 Rev. *J) mentions that peripheral IO drive mode is different from DSI IO drive mode, but I don't know which actually applies in my case

Ideally all the pins inside the PSoC 6 device are identical (except the OVT pins of port 1). The pin drive mode is the last stage of the GPIO. Please refer page number 242 of the device architecture TRM. 

While we are checking your project can you please attach the waveforms of the output with pins P9[6] and P10[1]. We would like to check how much they differ in terms of response.

Thanks

Ganesh

0 Likes

I don't have a screenshot with P9[6] yet, but here's one with P10[1]:

ds1054z-scope-display_2020-12-27_12-33-18.png

Ch1: pwm (output from timer, active high)
Ch2: pwm_n (output from timer, active high)

Ch3: 3-state PWM on P10[1], external pull-up (8k66) to 5V, clamped by internal protection diodes to roughly 3V8

Ch4: ignore; this is output from behind the external FET driver and FETs.

I'll rebuild the circuit on breadboard later and make a screenshot with P9[6]. The bottom line is that Ch3 looked like Ch1 and Ch2 when I used P9[6] (edges were sharp, high level was 3V3).

0 Likes

Here are new scope shots.

First one:

ds1054z-scope-display_2020-12-29_11-49-47.png

  • Ch1: pwm
  • Ch2: pwm_n
  • Ch3: pwm_H (on 9[6]) tied to pwm_L, external pull-up (8k66) to 5V

What I observe on the output (Ch3):

  • high level is about 3V4 (would probably be 3V3 if measured in a better environment, and if my assumption that the pin is pushing/pulling is correct)
  • remains low as long as pwm (Ch1) is low

This is not the desired output.

Second one:

ds1054z-scope-display_2020-12-29_11-53-55.png

  • Ch1: pwm
  • Ch2: pwm_n
  • Ch3: pwm_H (on 10[1]) tied to pwm_L, external pull-up (8k66) to 5V

What I observe on the output (Ch3):

  • is low when pwm_n is high
  • goes to mid-level when both pwm and pwm_n are low (during the deadtime inserted by the PWM timer)
  • goes to high level when pwm_n is low and pwm is high
  • high level is about 3V6...3V8

This is the desired outcome.

The only change made between the two scope shots is that I used P9[6] for pwm_H to create the first one, and P10[1] to create the second one.

0 Likes

As you say, page 242 of the architecture TRM is pretty clear - drive mode is the last stage of the GPIO structure. However, there's a difference between

  • figure 22-3 ("CPU and DSI/UDB I/O Drive Mode Block Diagram", subfig. 7) and
  • 22-4 ("Peripheral I/O Drive Mode Block Diagrams", subfig. 7).

The former looks just like the diagram shown in the pin configuration dialog. The latter has an extra pair of FETs that look exactly like the strong drive configuration. These are enable if OUT_EN is asserted (high). So if - for whatever reason - the toolchain configures the hardware for peripheral I/O drive mode, I'd see exactly the result that I see on my scope.

My understanding of the whole problem (how is PSoC creator interpreting my schematic, is the pin in CPU or peripheral drive mode, etc) feels pretty shallow so all I can really tell is that I'm not seeing what I expect when using P9[6]. I can try other pins broken out on the CYBLE-416045-02 but I don't think that will help me understand the underlying problem.

0 Likes

ChRe

From the datasheet, the driver takes care of the dead time automatically, no external dead time insertion is necessary. Also, the internal pull up/DN resistors variation is rather high, and can't be relied upon to guarantee consistent mid-voltage. I believe that driving this chip needs a single PWM output with pin setting configured in strong drive mode with enable, and an external resistive divider, holding ~2V when pin state is set to disabled (HiZ).

/odissey1

0 Likes

I agree that there is a more straight forward way of driving the gate driver. However, I'd like to try it this way for several reasons:

  • the ballout and overall feature set of the PSoC project are designed to be used with a variety of gate drivers, not just this one
  • my smallest PCB design doesn't allow me to place additional resistors, not even in 0201

regarding deadtime: Yes, this driver takes care of that. I inserted DT to see if the mid level is correct, and it isn't. Not because there's a variance in the internal pull-up/down resistors, but apparently because the GPIO is acting up. Which brings me to the other concern you raised:

We calculated the external pull-up to be 8k66 (or 8k2) to make it work throughout the range specified in the datasheet - not just for the typical value:

pastedImage_2.png

0 Likes

Lo and behold, the pins are handled differently by the toolchain:

  • P9[6] is wired directly as a peripheral output (ACT0)
  • P10[1] is routed through DSI

I found this by reading the HSIOM selection after startup:

pastedImage_2.png

Placing a watch on pwm_h_hsiom allows to observe the value.

For P9[6]:

pastedImage_3.png

And for P10[1]:

pastedImage_4.png

Unfortunately, there's no obvious way to get pin 9[6] back into the desired output mode because with HSIOM_SEL_DSI_ACT_0 I can't de-assert OUT_EN using the OUT register and I haven't found a way to clear a PWM timer's OUT_EN:

pastedImage_5.png

On the plus side, the real application has some routed logic between the PWM and the pin, so it should work as desired because the pin's HSIOM then has to select DSI_GPIO.

0 Likes

EDIT: This problem was caused by C32 in the CY8CPROTO-063-BLE. It increased the time constant of the output to something that was larger than my PWM period. Everything was fine after removing the cap.

 

I'm also having a problem with P12.7 (CY8CPROTO-063-BLE) which doesn't seem to do anything at all, as if it were high impedance, even though it's driven by a datapath's parallel out and apparently configured correctly (CY_GPIO_DM_PULLUP_DOWN).

Were you able to check internally if there are any subtle differences I might be running into?

Edit: Same symptom with a fresh CY8CPROTO-063-BLE, so I don't think I just damaged the GPIO structure of the first module. The schematic doesn't look suspicious around P12.7

0 Likes