DesignSpark Electrical Logolinkedin
Menu Search
Ask a Question

*WINNING ENTRY* Cypress Design Challenge - premises entry system

Two types of board firmware are used:

'Bell Push Switch' boards: the plan is to ultimately use two switches as inputs. There are two free pins on the CYBT-213043-MESH boards: P12 and P13. P12 can be a doorbell push switch, normally open. P13 can be a reset switch 'alarm cancel' mounted nearby to cancel the latched door press event.

'Bell Alarm' boards use P12 as a PWM output to drive an audible warning device e.g. piezo loudspeaker. P13 could be an inverted phase output to get more sound. The bell push switch message is received and generates a ding-dong sound. This continues until either an alarm cancel message is received or the Bell Alarm board's user button is pressed, or a timeout occurs.

This latching function means that even a very brief press of the door-bell causes full activation.

Ideally, units will be powered by coin cells and a Bell unit could be taken into the garden for example and linked by a mains-powered BLE-Mesh relay device, so if the RS delivery van arrives, all is not lost!

Sadly, this project is going very wrong. There are a few minor typing errors in the documentation such as '32K Cyrstal' in the schematic and 'wiced_hal_gpio_configurePin' in the WICED BT 1.4 API Reference Guide. Mesh Client has a button marked 'Confgiure'. Last night's work ended in failure: I could get the green LED on the bell push board to mimic the state on 'onoff' as set by the doorbell push-button release (P12) and cleared by releasing the USER button (as I am using that to clear the alarm until P13 is wired), OR I could get the bog-standard OnOff code to toggle the state of the green LED on the other board, the Bell Alarm, by pressing the USER button. But tie the two bits of code together and the bell push board would not send messages to the far end.

The IDE also came up with an invalid path message...

What does not help is the length of time taken to test each modification of the code. It has to compile, get downloaded to the target board via USB, then the board must be provisioned, and that all takes loads of time. At least it is not as long as programming EPROMs in the old days at 50ms/byte, thankfully.

Anyway, I will start the project again and see if the invalid path goes. It may have happened when I renamed an element.

3:26 open new project based on BLE_Mesh_OnOffSwitch. BellSwitch2.

3:29 Launch BellSwitch2 Build + Program. Fire up Laptop.

3:30 FW downloaded. Start Mesh Client on laptop. Network: BELL1NET. Open. Scan Unprovisioned. 

3:32 Mesh Client fails: Network closed...

Reopen network.

Scan Unprovisioned. Find Switch. Provision. Takes 20 seconds.

User switch on OnOffSwitch board toggles state of green led on Bell Alarm board running BLE_Mesh_LightDimmable software. OK, we have a working state and no invalid paths. Yippee.

Fire up monitor ports. Each USB port has two numbers, The higher one seems to be the one to see WICED_BT_TRACE printout. I use RealTerm at 921600Bd on Port21 for the Bell Push board.

Pressing, and releasing, the user button results in a message such as 'interrupt_handler: pin:26 value:1 (or 0) current_time:NNNNNNNNN'.

A monitor port on the Bell Alarm board gives, at 921,600Bd, Port 22, on a release of the BellPush User button:

dimmable light unknown msg:38

app msg handlermesh light srv set level element:0 present actual:0 linear:0 remaining_time:0

set_brightness:0

company_id:ffff opcode:8203

or after a toggle change state, the same but with:

app msg handlermesh light srv set level element:0 present actual:65535 linear:65535 remaining_time:0

set_brightness:100

Both monitor ports also display pool size/cur/max/total every so often.

Software mods to Bell Switch:

static void process_bell_button_push(uint8_t element_idx); // for the real bell push switch
static void button_interrupt_handler2(void* user_data, uint8_t pin); // function prototypes

wiced_bt_cfg_settings.device_name = (uint8_t *)"BellSwitch"; // was Switch, simple rename!

    // try to get pin 12 as interrupt input with pull-up...in mesh_app_hardware_init()
wiced_hal_gpio_configure_pin(WICED_P12, (GPIO_INPUT_ENABLE|GPIO_PULL_UP|    GPIO_EN_INT_BOTH_EDGE), GPIO_PIN_OUTPUT_LOW);
wiced_hal_gpio_register_pin_for_interrupt(WICED_P12, button_interrupt_handler2, NULL);

void button_interrupt_handler2(void* user_data, uint8_t pin)
{
    uint32_t value = wiced_hal_gpio_get_pin_input_status(pin);
    uint32_t current_time = wiced_bt_mesh_core_get_tick_count();
    uint32_t button_pushed_duration;
    if (value == button_previous_value)
    {
        WICED_BT_TRACE("interrupt_handler2: duplicate pin:%d value:%d current_time:%d\n", pin, value,       current_time);
        return;
    }
    button_previous_value = value;
    WICED_BT_TRACE("interrupt_handler2: pin:%d value:%d current_time:%d\n", pin, value, current_time);
    process_bell_button_push(ONOFF_SWITCH_ELEMENT_INDEX);
}
 
I expect you can have multiple input pins registered to one interrupt handler, but it is not obvious how to do that.
 

void process_bell_button_push(uint8_t element_idx) // This is a MAKE i.e. push
{
    static uint8_t onoff = 0;
    wiced_bt_mesh_onoff_set_data_t set_data;
    onoff = 1; // send a 1 state to set an alarm
    set_data.onoff           = onoff;
    set_data.transition_time = WICED_BT_MESH_TRANSITION_TIME_DEFAULT;
    set_data.delay           = 0;
    WICED_BT_TRACE("Green led ON! ");
    // turn on the green led
    wiced_hal_gpio_set_pin_output(LED_GREEN,0);
    wiced_bt_mesh_model_onoff_client_set(element_idx, &set_data);
}


Does it work??? NO! Scan Provisioned displays the UUID numbers but no following text. So, rename BellSwitch back to Switch and try again. At least there is no invalid path...1 min 20secs later it is provisioned.

Well, button presses did cause the green led to go on and off on the Bell Alarm board, but after a few minutes, it stopped working. 

I could connect to the BellAlarm with Mesh Client and toggle the LED state, again seeing unknown msg:38 on the monitor port.

But the comms between the two boards has mysteriously failed.

Tried this:

    wiced_hal_gpio_clear_pin_interrupt_status(WICED_P12);

Retry: 1min 24 secs to load and provision.

Now try:

    wiced_hal_gpio_clear_pin_interrupt_status(26); // Pin 26 is the USER button?

But that fails to remove the problem of comms giving up after a few minutes. The monitor port on the BellSwitch board comes up with odd messages: it is detected as Unprovisioned and attempting to re-provision it results in a Provision end failed message from Mesh Client. There are some mesh_application_init messages so something is falling over when the User button is pressed.

It could be that WICED_P12 is not evaluating as expected by the clear interrupt process. Or something else!

Sometimes several presses of 'Provision and configure' are required to restore operation.

A swift thought: maybe the line:

    wiced_hal_gpio_register_pin_for_interrupt(WICED_P12, button_interrupt_handler2, NULL);

is causing the User button's ISR to get lost? 2 minutes later, aha! That works, so I need a way of registering two interrupts, but the documentation is not helpful enough.

As a stab in the dark, I have used one interrupt handler registered to the two pins 12 and 26. That seems to work, but only for a while!

    wiced_platform_register_button_callback(WICED_PLATFORM_BUTTON_1, button_interrupt_handler, NULL, GPIO_EN_INT_BOTH_EDGE);

    wiced_hal_gpio_register_pin_for_interrupt(WICED_P12, button_interrupt_handler, NULL);

Well, it is now the day of the deadline for project submission and I have not been able to get the Switch board operating reliably. It does seem to make itself unprovisioned for some unknown reason.

    wiced_hal_gpio_clear_pin_interrupt_status(pin); // APRW Pin 12 or 26, try this in the ISR...

Sadly, it still dies after a while. Mysterious. So, I cannot sort out the other end. There seem to be useful hci functions to run PWM and timers.

I much prefer dsPICs and MPLAB-X. I have never had any trouble with that IDE but that could have been because in the early days of MPLAB-X I ran it under Ubuntu Linux. Other people had loads of trouble especially if they used Windows. However, someone forked up the Wi-Fi drivers in Ubuntu and I had to go over to Win 10, by which time all the problems with MPLAB-X and Windows had been solved ;-)

Editor's Note

Congratulations Al the Timelord on your entry to the Cypress Semiconductor Design Challenge, in partnership with DesignSpark. The judges have awarded you the runner-up prize! Well done and thank you for taking part.

Radamec robotics

22 Sep 2019, 11:06