NCS CAF leds modules work inversely?

[Harvey Zheng]

Hi，

I have a problem about CAF leds modules. I submit a led event to turn on led for 3600ms and turn off led for 500ms, but it work inversely in fact.

I find that leds.c will delay 3600ms firstly withoud turn on led, it will turn on led for 500ms after 3600ms.

static void led_update(struct led *led)
{
	k_work_cancel_delayable(&led->work);

	led->effect_step = 0;
	led->effect_substep = 0;

	if (!led->effect) {
		LOG_DBG("No effect set");
		return;
	}

	__ASSERT_NO_MSG(led->effect->steps);

	if (led->effect->step_count > 0) {
		int32_t next_delay =
			led->effect->steps[led->effect_step].substep_time;

		k_work_reschedule(&led->work, K_MSEC(next_delay));
	} else {
		LOG_WRN("LED effect with no effect");
	}
}

static void work_handler(struct k_work *work)
{
	struct led *led = CONTAINER_OF(work, struct led, work);

	const struct led_effect_step *effect_step =
		&led->effect->steps[led->effect_step];

	__ASSERT_NO_MSG(effect_step->substep_count > 0);
	int substeps_left = effect_step->substep_count - led->effect_substep;

	for (size_t i = 0; i < ARRAY_SIZE(led->color.c); i++) {
		int diff = (effect_step->color.c[i] - led->color.c[i]) /
			substeps_left;
		led->color.c[i] += diff;
	}
	set_color(led, &led->color);

	led->effect_substep++;
	if (led->effect_substep == effect_step->substep_count) {
		led->effect_substep = 0;
		led->effect_step++;

		if (led->effect_step == led->effect->step_count) {
			if (led->effect->loop_forever) {
				led->effect_step = 0;
			} else {
				struct led_ready_event *ready_event = new_led_ready_event();

				ready_event->led_id = LED_ID(led);
				ready_event->led_effect = led->effect;

				EVENT_SUBMIT(ready_event);
			}
		}
	}

	if (led->effect_step < led->effect->step_count) {
		int32_t next_delay =
			led->effect->steps[led->effect_step].substep_time;

		k_work_reschedule(&led->work, K_MSEC(next_delay));
	}
}

[Håkon Alseth]

Hi,

 

Could it be that you LEDs are defined as active low in DT?

Like here for the nRF52840-DK: https://github.com/nrfconnect/sdk-zephyr/blob/v2.7.0-ncs1/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts#L28

 

The CAF module reads from the device tree, as explained here:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.8.0/nrf/libraries/caf/leds.html#configuring-leds-in-dts

Kind regards,

Håkon

[Harvey Zheng]

I think the problem is because led_update() delay 3600ms firstly but not set led color. I don't know the reason for the design.

Thanks!

[Håkon Alseth]

Hi,

 

As mentioned, the PWM channels are by default inversed.

If you change this line (and do the similar to the other PWM pins that you use):

github.com/.../nrf52840dk_nrf52840.overlay

To:

/delete-property/ ch0-inverted;

 

Then it should not be inversed after rebuilding and flashing.

 

Kind regards,

Håkon

[Harvey Zheng]

Hi，

Thank you. I change the file as you said. Now it works as I set it up, but there is still a delay at the beginning, it seems to be caused by this line: https://github.com/nrfconnect/sdk-nrf/blob/v1.8.0/subsys/caf/modules/leds.c#L169

And, I have a next question. What do I need to change when I use GPIO as  backend for the LEDs? It has the same problem as PWM.

[Håkon Alseth]

Hi,

 

Harvey Zheng said:

Thank you. I change the file as you said. Now it works as I set it up, but there is still a delay at the beginning, it seems to be caused by this line: https://github.com/nrfconnect/sdk-nrf/blob/v1.8.0/subsys/caf/modules/leds.c#L169

Is this the initial delay that is problematic?

 

Harvey Zheng said:

And, I have a next question. What do I need to change when I use GPIO as  backend for the LEDs? It has the same problem as PWM.

This is configurable in kconfig, using these configurations:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.8.0/nrf/libraries/caf/leds.html#configuration

 

Kind regards,

Håkon

[Harvey Zheng]

"Is this the initial delay that is problematic?"

Yeah, every time the LED is updated, it is delayed but no color is set. The led's color is set here: https://github.com/nrfconnect/sdk-nrf/blob/v1.8.0/subsys/caf/modules/leds.c#L124

And, you can see the next delay here: https://github.com/nrfconnect/sdk-nrf/blob/v1.8.0/subsys/caf/modules/leds.c#L149

[Håkon Alseth]

Hi,

 

Thanks for confirming. I am able to reproduce the scenario on my end as well.

After inverting the pins in DT and looking into the scenario, it is the leds.c::leds global variable which is initialized (from device tree) to 0x64, which the "pwm_nrfx.c" driver interprets as setting the gpio as a "solid" output.

 

This is the initialization for reference:

https://github.com/nrfconnect/sdk-nrf/blob/v1.8.0/subsys/caf/modules/leds.c#L58-L60

 

I'm reporting this back to R&D now.

 

Kind regards,

Håkon