PWM not working after upgrade to nrf Connect SDK 1.9.1

[csteaderman]

Since upgrading to nrf Connect SDK 1.9.1, I no longer have PWM output. No errors returned when calling pwm_pin_set_usec, yet no output.

I tried upgrading to the latest nrf Connect SDK (2.2.0), thinking that perhaps a bug was fixed, but the number of changes (include paths, etc) was too daunting.

[Sigurd Hellesvik]

Hi,

Can you post the part of your code where you use pwm_pin_set_usec()?

Regards,
Sigurd Hellesvik

[csteaderman]

#define AFE_CLOCK_NODE  DT_ALIAS(afe_clock)

#if DT_NODE_HAS_STATUS(AFE_CLOCK_NODE, okay)

#ifndef DT_PWMS_LABEL

#define AFE_CLOCK_LABEL DT_NODELABEL(AFE_CLOCK_NODE)

#else

#define AFE_CLOCK_LABEL DT_PWMS_LABEL(AFE_CLOCK_NODE)

#endif

#define AFE_CLOCK_CHANNEL   DT_PWMS_CHANNEL(AFE_CLOCK_NODE)

#define AFE_CLOCK_FLAGS DT_PWMS_FLAGS(AFE_CLOCK_NODE)

#else

#error "Unsupported board: afe-clock devicetree alias is not defined"

#define AFE_CLOCK_LABEL ""

#define AFE_CLOCK_CHANNEL   0

#define AFE_CLOCK_FLAGS 0

#endif

 

    int ret = 0;

    _AfeClock_dev = device_get_binding(AFE_CLOCK_LABEL);

    if (!_AfeClock_dev) {

        Z_LOG(LOG_LEVEL_ERR, "Error: didn't find %s device.", AFE_CLOCK_LABEL);

        ret |= 0x1;

    }

 

    ret = pwm_pin_set_usec(AfeClock_dev, AFE_CLOCK_CHANNEL,

                   PWM_USEC(period), PWM_USEC(width), AFE_CLOCK_FLAGS);

    if (ret) {

        Z_LOG(LOG_LEVEL_ERR, "Error %d: failed to set pulse width.", ret);

    }

[Sigurd Hellesvik]

Hi,

I am Out of Office today and tomorrow, but I will continue to look into this on Wednesday.

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

Hi,

csteaderman said:

I am getting the following warning, but no description about the appriopriate alternate method for defining the actual pin assignment for the PWM signal.

'ch0-pin' is marked as deprecated in 'properties:' in C:/Nordic/v2.2.0/zephyr/dts/bindings\pwm\nordic,nrf-pwm.yaml for node /soc/pwm@4001c000.

See https://github.com/nrfconnect/sdk-nrf/blob/v2.2.0/samples/bluetooth/mesh/light_ctrl/boards/nrf5340dk_nrf5340_cpuapp_ns.overlay  for an example of a pwm overlay file.

csteaderman said:

Best I can tell, they are the same.

Oh well, it was worth a shot.

csteaderman said:

When I probe the GPIO line that is supposed to have the PWM signal on it, it is at 0V.

Which instrument did you use for probing? (oscilloscope/logic analyzer)?

Regards,
Sigurd Hellesvik

[csteaderman]

DMM.

[csteaderman]

Any more insights on how I should get PWM working on my custom PCBA?

[Sigurd Hellesvik]

Hi,

Sorry, this ticket was lost in the system.

Reading through it again now, I saw that I asked:

Sigurd Hellesvik said:

Can you try the zephyr fade_led sample on your board, to see if it behaves in the same way or not?

And you answered:

csteaderman said:

Not easily. My development is beyond using dev boards, and I am running on a custom PCBA now. When I probe the GPIO line that is supposed to have the PWM signal on it, it is at 0V.

Why can you not do it easily?

Would it not be using DTS to change the pins in the fade_led_sample and then probe the lines during the sample?

Regards,
Sigurd Hellesvik

[csteaderman]

I need to change all the clock modes, comment out most of the other pin definitions, and change enough of the code that if it doesn’t work I’d be unsure whether something I did wrong made it stop working. Not impossible, just difficult. I will take a look at the latest fade_led example and update my code to match the DTS definitions and code for manipulating the PWM properties. Hopefully that will shed some light. 

[csteaderman]

I was able to convert my device tree and software calls to be consistent with latest best practices. I am now able to get my PWM signal out! Unfortunately, my SPI communication has now stopped as the polarity of the CS signal is inverted. I am guessing that it is a similar issue with device tree and software calls. Should I create a new ticket or address it here? My old code grabbed the device object from the device tree and then I defined a spi_config struct to pass on the spi_read/write/transceive calls. Since this seems to not be working, I updated to defining the CS parameters in the device tree itself and am using the spi_read_dt/write_dt/transceive_dt calls but it still won't change the polarity of the CS signal. I need ACTIVE_LOW. I am using spi1. Any insights?

[Sigurd Hellesvik]

csteaderman said:

I am now able to get my PWM signal out!

Good to hear!

csteaderman said:

Should I create a new ticket or address it here?

We can continue here.

csteaderman said:

Any insights?

Can you share your pinctrl configuration for SPI?

Our central nRF pairing sample uses SPI with ACTIVE LOW cs-gpios.
Is this what you need?

Regards,
Sigurd Hellesvik

[csteaderman]

Here are the relevant sections from the pinctrl file and device tree files.

	spi1_default: spi1_default {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 16)>,
				<NRF_PSEL(SPIM_MOSI, 0, 15)>,
				<NRF_PSEL(SPIM_MISO, 0, 14)>;
		};
	};

	spi1_sleep: spi1_sleep {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 16)>,
				<NRF_PSEL(SPIM_MOSI, 0, 15)>,
				<NRF_PSEL(SPIM_MISO, 0, 14)>;
			low-power-enable;
		};
	};

&spi1 {
	compatible = "nordic,nrf-spi";
	status = "okay";
	pinctrl-0 = <&spi1_default>;
	pinctrl-1 = <&spi1_sleep>;
	pinctrl-names = "default", "sleep";
	cs-gpios = <&gpio0 18 GPIO_ACTIVE_LOW>;
	afe4490: afe4490@0 {
		compatible = "vnd,spi-device";
		reg = <0>;
		spi-max-frequency = <4000000>;
		label = "afe4490";
	};
};

[Sigurd Hellesvik]

Can you share your SPI code?

Or even better, a minimal sample with only SPI communication so I can try to replicate the issue on my end?

Regards,
Sigurd Hellesvik