Issues with custom board and long periods of time

[Jackes5]

Hey all!

I have a problem with my custom board using the nRF52832 with Softdevice 6.0 and SKD 15.0.0 working on Windows 10 in SEGGER with the BMD-300. I have the following problem: I have 2 custom boards working with the light switch examples, one is the client and the other is the server. Both work well with the light switch examples for hours or even days when I'm constantly using them, such as pressing the button and seeing the light turn on/off; but if I let them idle for long periods of time, usually by not touching them until a day after I leave the office, both the server and the client are put in weird state (I think it's deep sleep) and cannot be turned on again unless I press the button for the client (interrupt/reset)...but I cannot do something for the server as it only has a light and keeps itself in that state.

The code I use is the light switch proxy examples, there's nothing changed. I tried to fix my issue by commenting out the line (void)sd_app_evt_wait(); but I still have the same problem. I don't know where they are put into sleep mode, if they are put in that state in the first place. No error lines are printed on the debugger, no softdevice nor application nor mesh assert, nothing.

I don't know what to do, I just want the example to run forever, even if I don't touch the button for a week, of course until the battery is depleted.

Thanks!

[Bjørn Kvaale]

There are no timeouts in the nRF Mesh SDK. This would not make sense, as mesh networks need to be active most of the time to listen for incoming messages. You could try increasing the debugging level to get more debugging information & see if you receive an assert or something similar. Otherwise, you could also implement a heartbeat message, where you periodically (every minute or so) send a message throughout the network (e.g. from the client to the server). You could also send a generic on off publish set message from the client to the server that runs periodically. Another option would be to blink a LED from the main loop periodically. Any of these could help you debug the issue to see if you receive an assert or not.

[Jackes5]

Alright, I'll increase the detail level of the debugger ... I too think it's an assert somewhere

[Jackes5]

Hello, I connected the chip to the debugger to see what happens when I increase the level of detail.... The red square represents the "error" I'm trying to resolve: the chip appears to be active because it accepts input from the RTT Viewer and it processes it as it should (only printing the input in this case), no assert appears but it seems it cannot process the messages from the client, perhaps its antenna is down?

After a reset it shows it can handle the data comming from the client again, as shown in the green square.

I let the chip running the whole weekend to discover it doesn't go to sleep as I initially though! That's nice to know!

[Bjørn Kvaale]

I do not fully understand what the difference is between the red & the green box. Are you pressing the button on the custom server board, but are not able to send messages from the server to the client (i.e. log outputs Button 1 pressed, Button 2 pressed)? I thought your server board does not have any buttons.

I understand that in the red box you are not able to receive any messages from the client, whereas when you reset the server board, you are able to receive messages (green box). Is this correct?

[Jackes5]

For the first paragraph, yes. The custom server board has no buttons. I got those messages by sending through the RTT input.

For the second paragraph, yes. The server accepts and process the input from RTT (only prints the number with this instruction "__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Button %u pressed\n", button_number);", the only line in the function "button_event_handler") but it cannot handle the client messages. After a reset it works again as it should.