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:
The project is attached.
Questions:
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.
Lo and behold, the pins are handled differently by the toolchain:
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.
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
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).
Here are new scope shots.
First one:
What I observe on the output (Ch3):
This is not the desired output.
Second one:
What I observe on the output (Ch3):
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.
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
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.
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
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:
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:
Lo and behold, the pins are handled differently by the toolchain:
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.
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