Acknowledged message status not received in light switch sample

RE: Acknowledged message status not received in light switch sample

The Gribble — Fri, 04 Jan 2019 14:26:23 GMT

That was exactly it, thank you!

You're a star, I could have stared at that for ever!

Cheers,

Ben.

RE: Acknowledged message status not received in light switch sample

Edvin — Fri, 04 Jan 2019 13:22:57 GMT

Hello Ben,

I see. I think (not 100% sure) that the Fanstel BT832X boards doesn't have an LFXTAL, which is optional. However, all of the BLE and Mesh examples from our SDKs (which are tailored for the Nordic Semiconductor Development Kits (DKs) are configured to use an external LFXTAL. Go to the sdk_config.h file, and search for "NRF_SDH_CLOCK_LF_SRC".

In the provisioner example it should be found around line 12220 - 12263.

Use the following settings to use the internal RC oscillator instead of an external LFXTAL.

NRF_SDH_CLOCK_LF_SRC 0
NRF_SDH_CLOCK_LF_RC_CTIV 16
NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
NRF_SDH_CLOCK_LF_ACCURACY 1

Note that you need to change the sdk_config.h files for all the projects (it is not a common file for all the projects, even though the name may suggest so).

The LFCLK settings are a bit hard to discover if you are not aware of them, as the software has no way of noticing that there is no physical XTAL.

Try changing these settings, and see if that helps.

BR,

Edvin

RE: Acknowledged message status not received in light switch sample

The Gribble — Fri, 04 Jan 2019 13:02:25 GMT

Hi again Edvin,

Looking into it further the BT832X module seems to be the root of the problem - if I run a single PCA10040 board with the light switch client program then I can reliably provision it using the mobile app, while the BT832X version fails every time at 75%, with a Vector Catch if it's in the debugger.

We've got our own PCB with a BT832X module on it and that's failing in exactly the same way.

I'll try the Fanstel technical support with this too, but have you got any ideas for what the problem might be? I kind of assumed that they should be pretty much identical.

Many thanks,

Ben.

RE: Acknowledged message status not received in light switch sample

The Gribble — Fri, 04 Jan 2019 12:34:00 GMT

Hi Edvin, thanks for getting back to me!

I've been using Segger to erase the chips before programming (erase all from the target menu) but I'll try doing it from the command line in case it helps. Interesting result trying to check the server logs - I'm getting a vector catch in the server code at instruction 08C8. I'm afraid I'm a bit new to ARM development, is there a simple way to see where the catch has occurred?

Here's the log from the client before the catch, anyway:

<t:          0>, main.c,  321, ----- BLE Mesh Light Switch Client Demo -----
<t:      11756>, main.c,  288, Initializing and adding models
<t:      16626>, main.c,  361, Device UUID : 0059CCAA000000006E678ADCD0173719

The only other thing I can think of that might be significant is that two of the boards I'm using are Fanstel EV-BT832X boards rather than the nordic ones, they're using the same nRF52832 chip but could that make a difference?

Many thanks,

Ben.

RE: Acknowledged message status not received in light switch sample

Edvin — Fri, 04 Jan 2019 09:58:42 GMT

Hello Ben,

I just tested with SDK for Mesh v3.0.0, and I couldn't reproduce your issue.

The issue may be that you have some old data stored in the flash of the nrf on the device that you are trying to provision, causing some issues with the provisioning. You should check the log output on the device that you are trying to provision as well.

Please make sure that you:

1 - erase the flash of the nrf before programming it.

2 - program the correct pojects to all your development boards. Make sure you use the S132 project and softdevice, and not the S140 ones.

use e.g. Nordic Command line tools, open a CMD terminal and type "nrfjprog -e" before programming the DKs. Let me know if you are having problems doing this. You can alternatively use nRFgo Studio to erase the chips.

I suppose that you use Segger Embedded Studio, and if you do, Segger should upload the correct softdevice for you. If you use nrfjprog to program the devices, make sure that you program the correct version of the softdevice (S132 v 6.1.0).

If it still doesn't work, can you check the log for the client or server? (the one that you are trying to provision).

Best regards,

Edvin