Initial spike with PWM implementation

RE: Initial spike with PWM implementation

Vidar Berg — Thu, 28 Feb 2019 08:25:45 GMT

All IO pins will be configured with their default configuration (input - disconnect) after a reset. That is, all reset types except "Wakeup from System OFF reset". So unless you use System OFF, I'm not sure why you see the spike.

From the PS:

RE: Initial spike with PWM implementation

DeveloperZ — Wed, 27 Feb 2019 18:14:55 GMT

[quote userid="4240" url="~/f/nordic-q-a/43844/initial-spike-with-pwm-implementation/173279"]have you tried the same with other Mesh examples? [/quote]

Yes I did try.

[quote userid="74350" url="~/f/nordic-q-a/43844/initial-spike-with-pwm-implementation/172756"]I implemented the start_PWM() function before the initialize() and start(). This doesn't result in any spike. [/quote]

This one solved the issue because the pin is initially configured active LOW because of which there is the spike when I reboot and the initialize() function takes few ms to implement. Now, as I am initializing the PWM initially, there isn't the spike.

RE: Initial spike with PWM implementation

Vidar Berg — Wed, 27 Feb 2019 14:25:37 GMT

Sorry, misread that. Our Mesh examples do not use Pin 11 as far as I can see. Please try the following: comment out the PWM initialization then read out the pin configuration register after the app has been initialized to determine whether the pin has its default configuration or not (input - disconnect).

EDIT: you mentioned testing this with SDK 15.2.0, but have you tried the same with other Mesh examples?

RE: Initial spike with PWM implementation

DeveloperZ — Mon, 25 Feb 2019 13:51:07 GMT

Sorry, you got me wrong. They were separate applications. We were able to implement UART Tx on pin 11 in a different application and PWM on pin 11 in a different application.

We never faced any error in prior cases as we never had the soft-on PWM functionality on reset.

RE: Initial spike with PWM implementation

Vidar Berg — Mon, 25 Feb 2019 13:48:10 GMT

UART Tx? You should not have both PWM output and UART enabled on the same pin at the same time. Do you see the spike if you don't initialize UART?

RE: Initial spike with PWM implementation

DeveloperZ — Mon, 25 Feb 2019 13:43:08 GMT

We are using pin 11 for "LIGHT_FIXTURE". There is a pin definition as SER_CONN_CHIP_RESET_PIN defined as 11 but that never affected our development till date. We were able to implement PWM and UART communication successfully on pin 11.

RE: Initial spike with PWM implementation

Vidar Berg — Mon, 25 Feb 2019 13:32:58 GMT

What pin number do you use for "LIGHT_FIXTURE"?

RE: Initial spike with PWM implementation

DeveloperZ — Mon, 25 Feb 2019 12:57:58 GMT

[quote userid="4240" url="~/f/nordic-q-a/43844/initial-spike-with-pwm-implementation/172709"]Have you checked if one of the LED_x definitions in your board file is assigned to the same pin as LIGHT_FIXTURE?[/quote]

No, there isn't any definition in the board file that matches with the same pin as LIGHT_FIXTURE.

Here is what we did, I implemented the start_PWM() function before the initialize() and start(). This doesn't result in any spike.

[quote userid="74350" url="~/f/nordic-q-a/43844/initial-spike-with-pwm-implementation/171894"]Is there any startup time for the Mesh?[/quote]

It looks like this spike is a result of the startup/setup time for Mesh.

RE: Initial spike with PWM implementation

Vidar Berg — Mon, 25 Feb 2019 09:38:48 GMT

Hi,

So it seems like the spike is not caused by the PWM implementation then. The example do toggle LEDs to indicate various states. Have you checked if one of the LED_x definitions in your board file is assigned to the same pin as LIGHT_FIXTURE?

RE: Initial spike with PWM implementation

DeveloperZ — Tue, 19 Feb 2019 13:15:24 GMT

Hi,

[quote userid="4240" url="~/f/nordic-q-a/43844/initial-spike-with-pwm-implementation/171880"]The pin should be set low when you configure it to "active high".[/quote]

When I set the pin to active high, I need not change anything as the driver (active high) will have the LED connected turned OFF.

[quote userid="4240" url="~/f/nordic-q-a/43844/initial-spike-with-pwm-implementation/171880"]Do you get a shorter pulse if you remove the 850 us delay? [/quote]

There isn't any difference in the pulse when I remove the delay or have it as the pulse is quite random. On few occasions, I won't even see the pulse/spike.

Is there any startup time for the Mesh? Because, when we tried it with the 15.2.0 SDK, we can't see that initial spike while rebooting.

Thank you.

RE: Initial spike with PWM implementation

Vidar Berg — Tue, 19 Feb 2019 12:26:56 GMT

The pin should be set low when you configure it to "active high". Do you get a shorter pulse if you remove the 850 us delay?

hmolesworth, the app_pwm library generates the PWM output signal with the TIMER, PPI, and GPIOTE peripherals instead of using the dedicated PWM module available on the 52 series. So this is a different implementation.

RE: Initial spike with PWM implementation

DeveloperZ — Mon, 18 Feb 2019 20:11:32 GMT

I did try inverting the polarity of the PWM pin which is similar to what you are suggesting.
That also has a similar spike when powering ON the driver.

RE: Initial spike with PWM implementation

hmolesworth — Mon, 18 Feb 2019 19:57:34 GMT

I see multiple bugs in the PWM libraries, not sure whether that would help. A fix worth trying is to use ms-bit inverted, if you haven't tried already. The startup pulse is different for Low-High PWM (value) vs. High-Low PWM (0x8000|value). I use differential PWM signals so see both simultaneously; maybe try doing this for your LED drive to see if one signal in your case looks preferable. I also control pin initialisation seperately from the library, but can get a 4uSec unwanted pulse on Low-High but not on High-Low startup.

So the bugs: From the user manual

// 6.17.5.15 PSEL.OUT[n] (n=0..3)
//  Address offset: 0x560 + (n × 0x4)
//  Output pin select for PWM channel n
//  Bit number 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
//          ID                                                                         C B A A A A A
// Reset 0xFFFFFFFF                  1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
//  ID RW Field Value ID Value Description
//  A RW PIN [0..31] Pin number
//  B RW PORT [0..1] Port number
//  C RW CONNECT Connection   Disconnected 1 Connected 0

From the library for PWM nrfx_pwm.h and nrfx_pwm.c in SDK 15.2.0:

/**
 * @brief This value can be added to a pin number to inverse its polarity
 *        (set idle state = 1).
 */
#define NRFX_PWM_PIN_INVERTED    0x80

static void configure_pins(nrfx_pwm_t const * const p_instance,
                           nrfx_pwm_config_t const * p_config)
{
    uint32_t out_pins[NRF_PWM_CHANNEL_COUNT];
    uint8_t i;

    for (i = 0; i < NRF_PWM_CHANNEL_COUNT; ++i)
    {
        uint8_t output_pin = p_config->output_pins[i];
        if (output_pin != NRFX_PWM_PIN_NOT_USED)
        {
            bool inverted = output_pin &  NRFX_PWM_PIN_INVERTED;
            out_pins[i]   = output_pin & ~NRFX_PWM_PIN_INVERTED;

            if (inverted)
            {
                nrf_gpio_pin_set(out_pins[i]);
            }
            else
            {
                nrf_gpio_pin_clear(out_pins[i]);
            }

            nrf_gpio_cfg_output(out_pins[i]);
        }
        else
        {
            out_pins[i] = NRF_PWM_PIN_NOT_CONNECTED;
        }
    }

    nrf_pwm_pins_set(p_instance->p_registers, out_pins);
}

There is no inverted bit in the manual; this affects port output initialisation and the use of Port 1.x for PWM.

RE: Initial spike with PWM implementation

DeveloperZ — Mon, 18 Feb 2019 18:21:15 GMT

also, we logged the status of the soft on and when checking the logs we see only the first 15 values... while it had to log 300 values

, main.c,  860, ----- BLE Mesh Dimming Client Demo -----
, main.c,  787, Initializing and adding models
, main.c,  227, App OnOff Model Handle: 7
, main.c,  920, PWM max ticks: 8000
, main.c,  929, Current dimming: 0
, main.c,  929, Current dimming: 1
, main.c,  929, Current dimming: 2
, main.c,  929, Current dimming: 3
, main.c,  929, Current dimming: 4
, main.c,  929, Current dimming: 5
, main.c,  929, Current dimming: 6
, main.c,  929, Current dimming: 7
, main.c,  929, Current dimming: 8
, main.c,  929, Current dimming: 9
, main.c,  929, Current dimming: 10
, main.c,  929, Current dimming: 11
, main.c,  929, Current dimming: 12
, main.c,  929, Current dimming: 13
, main.c,  929, Current dimming: 14
Current dimming: 15