Issues with custom board and long periods of time

RE: Issues with custom board and long periods of time

Bjørn Kvaale — Fri, 29 Mar 2019 15:11:33 GMT

Great to hear!

RE: Issues with custom board and long periods of time

Jackes5 — Fri, 29 Mar 2019 14:46:22 GMT

Oh, I see now. Yes, it was the solution, the device has been working perfectly for 2 days in a row, something that has never happened before. Thank you so much!

RE: Issues with custom board and long periods of time

Bjørn Kvaale — Fri, 29 Mar 2019 10:54:22 GMT

1) The sdk_config.h configures the clock accuracy PPM for the softdevice & the nrf_mesh_config_examples.h sets the PPM for the mesh stack. These two stacks are separate from each other, so they will have different config files & will be initiated separately.

2) Was the solution to change the PPM value in nrf_mesh_config_examples.h to another value? If this was the solution, then I am guessing there may have been some kind of clock drift over time that led to this error.

RE: Issues with custom board and long periods of time

Jackes5 — Thu, 28 Mar 2019 15:14:14 GMT

I applied what I found in this link yesterday after the latest finding, and the problem hasn't continued so far to this morning.

I consider my problem solved, but I want further know these things:

1.) Why are they 2 files: "sdk_config.h" and "nrf_mesh_config_examples.h" that alter the clock configurations? I vaguely remember having to edit these files in Keil uVision but not in Segger for the custom board to work.

2.) Why did the error happen after hours of inactiviy, why not immediately... What was the Softdevice doing in those two unknown functions?

RE: Issues with custom board and long periods of time

Bjørn Kvaale — Thu, 28 Mar 2019 15:00:26 GMT

You can use the addr2 line function to figure out where the error is occuring.

RE: Issues with custom board and long periods of time

Jackes5 — Wed, 27 Mar 2019 20:44:49 GMT

Alright, I got something new from the debugger... After random periods of time (usually more than an hour), the debugger halts with 2 lines of: "UNKNOWN FUNCTION AT 0x0023DE0" and "UNKNOWN FUNCTION AT 0x00008C8". It no longer appears in nRF Connect, while the client does.

RE: Issues with custom board and long periods of time

Jackes5 — Wed, 27 Mar 2019 14:56:36 GMT

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.

RE: Issues with custom board and long periods of time

Bjørn Kvaale — Wed, 27 Mar 2019 14:38:29 GMT

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?

RE: Issues with custom board and long periods of time

Jackes5 — Mon, 25 Mar 2019 15:14:11 GMT

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!

RE: Issues with custom board and long periods of time

Jackes5 — Thu, 21 Mar 2019 14:47:54 GMT

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

RE: Issues with custom board and long periods of time

Bjørn Kvaale — Thu, 21 Mar 2019 14:36:01 GMT

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.