- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
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.
Solved! Go to Solution.
- Tags:
- drive mode
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
Placing a watch on pwm_h_hsiom allows to observe the value.
For P9[6]:
And for P10[1]:
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:
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't have a screenshot with P9[6] yet, but here's one with P10[1]:
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here are new scope shots.
First one:
- 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:
- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
Placing a watch on pwm_h_hsiom allows to observe the value.
For P9[6]:
And for P10[1]:
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:
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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