GPIOs work in erratic manner after BLE mesh node is provisioned.

I am developing a capactive touch switch based home automation system. I am running Zephyr RTOS on nRF52832. All the hardware works fine till BLE mesh node is priovisioned. All GPIOs work in an erratic manner after node is provisioned. My project configuration file is as follows

CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n
#CONFIG_NRFX_COMP=y
#CONFIG_ADC=y
CONFIG_PRINTK=y
#CONFIG_MULTITHREADING=y
#CONFIG_TIMESLICING=y
#CONFIG_TIMESLICE_SIZE=10
#CONFIG_TIMESLICE_PRIORITY=0

CONFIG_INIT_STACKS=n
CONFIG_MAIN_STACK_SIZE=1024
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

CONFIG_BT_OBSERVER=y
CONFIG_BT_BROADCASTER=y
CONFIG_BT_CTLR_DUP_FILTER_LEN=0
CONFIG_BT_CTLR_LE_ENC=n
CONFIG_BT_CTLR_LE_PING=n
CONFIG_BT_DATA_LEN_UPDATE=n
CONFIG_BT_PHY_UPDATE=n
CONFIG_BT_CTLR_CHAN_SEL_2=n
CONFIG_BT_CTLR_MIN_USED_CHAN=n
CONFIG_BT_CTLR_ADV_EXT=n
CONFIG_BT_CTLR_PRIVACY=n
CONFIG_BT_CTLR_TX_PWR_PLUS_8=y

CONFIG_BT_PERIPHERAL=y
CONFIG_BT=y
CONFIG_BT_TINYCRYPT_ECC=y
CONFIG_BT_RX_STACK_SIZE=4096
CONFIG_BT_L2CAP_TX_BUF_COUNT=8

CONFIG_BT_MESH=y
CONFIG_BT_MESH_RELAY=y
CONFIG_BT_MESH_RELAY_RETRANSMIT_COUNT=3
CONFIG_BT_MESH_LOW_POWER=n
CONFIG_BT_MESH_FRIEND=n
CONFIG_BT_MESH_FRIEND_QUEUE_SIZE=16
CONFIG_BT_MESH_ADV_BUF_COUNT=60
CONFIG_BT_MESH_TX_SEG_MAX=6
CONFIG_BT_MESH_TX_SEG_MSG_COUNT=3
CONFIG_BT_MESH_RX_SEG_MSG_COUNT=3
CONFIG_BT_MESH_CRPL=128
CONFIG_BT_MESH_RPL_STORE_TIMEOUT=120
CONFIG_BT_MESH_MSG_CACHE_SIZE=100

CONFIG_BT_MESH_PB_GATT=y
CONFIG_BT_MESH_PB_ADV=y
CONFIG_BT_MESH_GATT_PROXY=y

#CONFIG_BT_MESH_LPN_SCAN_LATENCY=30
#CONFIG_BT_MESH_LPN_RECV_DELAY=40
#CONFIG_BT_MESH_LPN_POLL_TIMEOUT=300

CONFIG_BT_MESH_SUBNET_COUNT=2
CONFIG_BT_MESH_APP_KEY_COUNT=2
CONFIG_BT_MESH_MODEL_GROUP_COUNT=2
CONFIG_BT_MESH_LABEL_COUNT=3

#CONFIG_BT_MESH_IV_UPDATE_TEST=y

#CONFIG_UART_CONSOLE=n
#CONFIG_BT_DEBUG_MONITOR_UART=y
#CONFIG_BT_DEBUG_LOG=y

##CONFIG_BT_MESH_DEBUG=y
#CONFIG_BT_MESH_DEBUG_PROV=y
#CONFIG_BT_MESH_DEBUG_PROXY=y
#CONFIG_BT_MESH_DEBUG_BEACON=y
#CONFIG_BT_MESH_DEBUG_NET=y
#CONFIG_BT_MESH_DEBUG_TRANS=y
#CONFIG_BT_MESH_DEBUG_SETTINGS=y
#CONFIG_BT_MESH_DEBUG_LOW_POWER=y
#CONFIG_BT_MESH_DEBUG_FRIEND=y
#CONFIG_BT_MESH_DEBUG_MODEL=y
#CONFIG_BT_MESH_DEBUG_ACCESS=y
#CONFIG_BT_MESH_DEBUG_CRYPTO=y
#CONFIG_BT_MESH_DEBUG_ADV=y
#CONFIG_BT_MESH_SELF_TEST=y

CONFIG_GPIO=y
CONFIG_I2C=y

CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_HCI_TX_STACK_SIZE=1024
#CONFIG_BT_DEBUG_HCI_CORE=y
#CONFIG_BT_DEBUG_HCI_DRIVER=y

I suspect that there is some configuration setting which is missing

Parents

0 Edvin over 3 years ago

Hello,

All GPIOs work in an erratic manner after node is provisioned.

Can you please elaborate a bit? What do you mean by erratic manner? Do they stop responding? What are they supposed to do? Are they inputs or outputs? Do you stop seeing events? Or are you no longer able to set output values?

BR,
Edvin
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 umeshdj over 3 years ago in reply to Edvin

e.g. provisioning LED connected to P0.25 stops working. After provisioning it is supposed to turn on continuously as per following code snippet

static void prov_complete(uint16_t net_idx, uint16_t addr)

{

int ret;

printk("provisioning complete for net_idx 0x%04x addr 0x%04x\n", net_idx, addr);

primary_addr = addr;

primary_net_idx = net_idx;

provisioned = true;

ret = ledonoff(LED7, LED_ON);

}

.....

int ledonoff(int ledno, /*leds - 1 to 6*/

int onoff /*1 - off, 0 - on*/

)

{

int ret;

switch (ledno) {

case 0:

ret = gpio_pin_set_dt(&lled0, onoff);

break;

case 1:

ret = gpio_pin_set_dt(&lled1, onoff);

break;

case 2:

ret = gpio_pin_set_dt(&lled2, onoff);

break;

case 3:

ret = gpio_pin_set_dt(&lled3, onoff);

break;

case 4:

ret = gpio_pin_set_dt(&lled4, onoff);

break;

case 5:

ret = gpio_pin_set_dt(&lled5, onoff);

break;

case 6:

ret = gpio_pin_set_dt(&lled6, onoff);

break;

case 7:

ret = gpio_pin_set_dt(&lled7, onoff);

break;

default:

ret = FAILURE;

}

return ret;

}
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 umeshdj over 3 years ago in reply to umeshdj

As per PS, Pins 27 to 42v(GPIO P0.22 to P0.30) which are located near the radio should be used for low drive low frequency only. I am using it to drive LEDs. I guess this could be an issue but why does it work very well till the device node is not provisioned?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Edvin over 3 years ago in reply to umeshdj

ok, I can't tell exactly what the issue is based on this snippet. Low drive low frequency should be fine for running LEDs. The limitation is that you shouldn't use it for signals that change very fast, such as PWM or high speed SPI and so on.

Is it mainly LED7 that is not working? Are you sure that LED7 is properly initialized? I see from your comments that:

umeshdj said:
int ledonoff(int ledno, /*leds - 1 to 6*/

Perhaps you forgot to initialize LED7 after adding it?

Did you try to add some logging, or to perform a debug session to see what the return value from gpio_pin_set_dt is, and that the switch case is actually reached with the correct ledno?

If so, is there any way for me to reproduce what you are seeing on a DK?

There are no known issues that GPIOs are not working properly after the device is provisioned.

Best regards,

Edvin
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 umeshdj over 3 years ago in reply to Edvin

ledonoff(LED7, LED_ON) does not fail. However LED7 does not turn on after provisioning. I tried it in main() function as well as below

while (1) {

if (false == provisioned) {

printk("main_thread: provisioning in progress\n");

ret = ledonoff(LED7, val); /*turn on/off provisioning LED*/

k_msleep(SLEEP_TIME_MS);

val = (val == LED_ON) ? LED_OFF : LED_ON;

detect_touch();

for (i = 0; i < 6; i++) {

if (true == get_key_status(i)) {

clr_key_status(i);

toggle_sw_status(i);

}

}

/* k_msleep(SLEEP_TIME_KS); */

}

else {

printk("main:device provisioned\n");

ret = ledonoff(LED7, LED_ON); /*turn on provisioning LED*/

if (FAILURE == ret) {

printk("Failed to turn on LED7");

return;

}

}

}

I am able to reset the node and LED7 starts blinking after reset. I would suggest you reproduce this problem in nRf52-DK with LED and 220ohm resistor connected on P0.25. Please try with BLE mesh generic on/off server sample
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

0 Edvin over 3 years ago in reply to umeshdj

Can you please zip and send the application that you are using to reproduce this? Why do I need a 220ohm resistor?

I am certain that the GPIOs doesn't stop working after being provisioned, as we have several samples using the GPIOs after the provisioning. Sure you didn't mix up the LED_ON LED_OFF polarity? Perhaps it turns the LED off? I also see that you return after the LED is set to LED_ON. Where does it return to? Do you configure the LED directly after this, perhaps?

Just to verify that it is in fact not the provisioning that is breaking this, what if you comment out the line:

 if (false == provisioned) {

And everything in the "else" bracket, and just try to print a message if the device is provisioned. Something like:

    while (1) {
        //if (false == provisioned) {
            printk("main_thread: provisioning in progress\n");
            if (provisioned) {
                printk("provisioned here");
            }
            ret = ledonoff(LED7, val); /*turn on/off provisioning LED*/
            k_msleep(SLEEP_TIME_MS);
            val = (val == LED_ON) ? LED_OFF : LED_ON;

            detect_touch();

            for (i = 0; i < 6; i++) {
                if (true == get_key_status(i)) {
                    clr_key_status(i);
                    toggle_sw_status(i);
                }
            }
            /* k_msleep(SLEEP_TIME_KS); */
        //}

        //else {
        //    printk("main:device provisioned\n");
        //    ret = ledonoff(LED7, LED_ON); /*turn on provisioning LED*/
        //    if (FAILURE == ret) {
        //        printk("Failed to turn on LED7");
        //        return;
        //    }
        //}
    }

Does the LED keep blinking? And does the log say "provisioned here" at some point after it has been provisioned?

Best regards,

Edvin

0 umeshdj over 3 years ago in reply to Edvin

LED keep blinking and RTT log says it is provisioned. Please check your inbox. I have sent you following

1. source files

2. board support files

3. schematic
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 umeshdj over 3 years ago in reply to Edvin

LED keep blinking and RTT log says it is provisioned. Please check your inbox. I have sent you following

1. source files

2. board support files

3. schematic
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

0 Edvin over 3 years ago in reply to umeshdj

I didn't receive any files. But this suggests that there is no issue with the GPIOs then, don't you agree? Since on that test, it continued to blink.

Waiting for updates/application files.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 umeshdj over 3 years ago in reply to Edvin

I found that the problem is with the sample I used in my project \zephyrproject\zephyr\samples\boards\nrf\mesh\nRF805SensorBLEMesh.

Another sample \zephyrproject\zephyr\samples\boards\nrf\mesh\onoff_level_lighting_vnd_app code works well. I tested it on nRF52-DK. I used P0.25 to connect an LED and a resister to VDD. The LED turns on after provisioning and turns off after reset. I am attaching the modified sample code.OnOffLevelLightingVndApp.zip
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel