Coap server not working on a third party module

[kaushalyasat]

Hi, 

I am building the CoAP client and sever example programs on a third party module (Reytac MDBT50Q). I am using Reytac dev board  MDBT50Q-DB-40. Unfortunately the example apps doesnt seem to work. I am using NRF Connect SDK 2.0.0. I tried the apps on Nordic nRF52840 Dev Kits and they work. I am using the same nrf52840dk_nrf52840.dts file with the Reytac module. 

The Reytac dev board doesn't have the HFX oscillator on the dev board, probably it is available in the module itself. The dev board has a 32.7kHz crystal and is oscillating Vpp ~100mV. Dont know if this is too low. I couldnt find a spec for the LFXO in the datasheet.

When I look into the power supply on Dev board, I see VDDH tied to 3V3 and 10uH inductor between VDD and DCH. I reckon this means the power path would be 3V3->VDDH->REG0 DC/DC->REG1 (LDO or DC/DC)->System Power. I couldnt find the code section which handles the power control registers in coap client app. 

1. Is 100mV LFXO acceptable?
2. Where is power register configuration happens in coap client/server apps?

Thanks,

[Håkon Alseth]

Hi,

 

Is 100mV LFXO acceptable?

This is usually enough. The real voltage is higher (probably > 200 mVpp), because when you're probing the pin, you're also loading it with the pin-probe.

Where is power register configuration happens in coap client/server apps?

CONFIG_BOARD_ENABLE_DCDC sets the DCDC, and here's the 32k clock control choices:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/kconfig/index.html#CONFIG_CLOCK_CONTROL_NRF_SOURCE

 

I do not have experience with the dev board in question, but the module itself comes without an external LFCLK.

If you have problems booting up, you can try to set this and see if that works:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

 

Kind regards,

Håkon

[kaushalyasat]

Hey Håkon,

Thanks heaps for the info. 

I will try CONFIG_BOARD_ENABLE_DCDC. How do you specify REG0 or REG1? 

The modules dont come with internal LFCLK, but the dev board that they are mounted on has it. The module boots up and I can see the pairing LED blinking when I press pairing request button. Only issue is I cant make the client pair with it. The same client pairs with the server programmed to a nRF52840 DK. I assume this may be caused by the differences in hardware interfacing, but still cant figure out what. 

This is the dev board schematic.

Cheers,

[kaushalyasat]

CoAP session-2.pcapngThanks Håkon,

I have this one module, the Minew  MS88SF2, which shows this problem. It has both crystals built in. 

What I have tried.

1. Programmed a nRF52840 DK as a CoAP server.

2. Programmed a Minew  MS88SF2 as a CoAP client. 

3. Started a paring process but pairing always fails. 

I have changed the nrf52840dk_nrf52840.dts slightly in the buttons section as the Minew doesnt have the buttons as same as nRF DK. The new buttons section is 

	buttons {
		compatible = "gpio-keys";
		button0: button_0 {
			gpios = <&gpio0 10 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;	/* 11 changed to 10  to suit Minew module */
			label = "Push button switch 0";
		};
		button1: button_1 {
			gpios = <&gpio0 12 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 1";
		};
		button2: button_2 {
			gpios = <&gpio0 24 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
			label = "Push button switch 2";
		};
		button3: button_3 {
			gpios = <&gpio0 26 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;	/* 25 changed to 26 to suit Minew module */
			label = "Push button switch 3";
		};
	};

Other than that I am using the same nrf52840dk_nrf52840.dts. 

Following is how the Minew module connected to my second nRF DK.

nRF52840 DK	Minew DK	Notes
P29-1	VCC	3V
GND	GND
P29-4	SWDIO
P29-5	SWCLK
P29-7	P0.18	RESET
	P0.10	SW1 input for CoAP Server/Client. Internal pullup used.
	P0.12	SW2 input for CoAP Server/Client. Internal pullup used.
	P0.24	SW3 input for CoAP Server/Client. Internal pullup used.
	P0.26	SW4 input for CoAP Server/Client. Internal pullup used.

I have also attached a wireshark session I logged. The first section is for the Minew module and from about line # 200 onwards is using a successful session with a RayTac module.

Can you think of any reason why Minew module behaves this way? Only think I can think of is the same DTS that does not align with Minew.

4. One other thing I have tried is to disable the DCDC_HV in prj.conf. This is because the Minew module internally has VDD and VDDH connected. Still no luck. 

5. I dont get any messages from the client app even from nRF52840 DK. Why is this?

Thanks again,

[kaushalyasat]

Hi,

Only diff in these two boards(Raytac MDBT50Q DK and Minew MS88SF2 seems to be the power configuration. Retac is configured to be powered from VDDH and Minew is configured to be powered from VDD/VDDH tied together. 

As informed by Raytac, when we tie the VDD and VDDH, this disables REG0. I couldn't find this claim from datasheet. Can anyone confirm this claim?

If so, Minew is powered solely from REG1. This is why I used "CONFIG_BOARD_ENABLE_DCDC_HV=n" in my proj.conf, but sadly with no apparent result. I can confirm that DCDCEN is enabled and DCDCEN0 is disabled by debugging into the project.

Now I have no more ideas to throw at this. I can forget about Minew module and go ahead with Rayac module, but my question is working in the VDD/VDDH tied together mode, which doesnt seem to work for me.

Any help highly appreciated.

Thanks,

[Edvin]

Hello,

I tried having a look at the sniffer trace, but all the packets before ~200 are not decrypted properly when I open it in wireshark.

That goes for the packet above 93, except for the advertisements, and all the data request packets below 93. Is that the case for you as well? Do you know if the fe80::97b:a28b:5771:93bd is the minew device? And are you able to decrypt the packets in the log?

Or doesn't the Minew device affect the log at all, meaning the radio is silent from the Minew?

Best regards,

Edvin

[kaushalyasat]

Hey Edvin, Thanks for looking into this. 

I can see the "Expert Info (Warning/Undecoded): No encryption key set - can't decrypt" in some of the packets as well. 

But I found out something interesting in the debug terminal. 

When I connect P0.26 to GND, this happens.

[00:05:46.445,037] <inf> coap_client_utils: Send 'provisioning' request
[00:05:46.445,159] <err> os: ***** MPU FAULT *****
[00:05:46.445,190] <err> os:   Stacking error (context area might be not valid)
[00:05:46.445,220] <err> os: r0/a1:  0xaaaaaaaa  r1/a2:  0xaaaaaaaa  r2/a3:  0xaaaaaaaa
[00:05:46.445,251] <err> os: r3/a4:  0xaaaaaaaa r12/ip:  0xaaaaaaaa r14/lr:  0xaaaaaaaa
[00:05:46.445,251] <err> os:  xpsr:  0xaaaaaa00
[00:05:46.445,281] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
[00:05:46.445,281] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
[00:05:46.445,312] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
[00:05:46.445,312] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0xffffffff
[00:05:46.445,343] <err> os: fpscr:  0x00000000
[00:05:46.445,373] <err> os: Faulting instruction address (r15/pc): 0xaaaaaaaa
[00:05:46.445,404] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
[00:05:46.445,434] <err> os: Current thread: 0x20003880 (sysworkq)
[00:05:47.164,276] <err> fatal_error: Resetting system
uart:~$ *** Booting Zephyr OS build v3.0.99-ncs1  ***

What could this be?

[Edvin]

What is P0.26 doing in your application? Why did you try this? Do you see any logging without connecting P0.26 to GND? I see from your table that this is button4, so what does button4 do in your application? Does the same happen if you press button4 on the other module that is working?

BR,

Edvin

[kaushalyasat]

Hi Edvin, Thanks again. 

The reason for P0.26 is that in I dont have P0.25 in Minew module. So I changed the SW mapping in the DTS file. I created a custom board for the Minew module and changed the DTS file in that. To try to eliminate any uncertainties, I have removed all the other hardware interfaces apart from UART0 from the DTS as well. 

This stack overflow I see only when P0.26 is connected to GND.

In the other modules (Raytac and Nordic DK) I didn't have to modify the DTS as SW4 - P0.25 is available. Nothing like this happens in those, as the CoAP client/server was working with them.

Thanks,

[Edvin]

ok, let me rephrase my question. What does "button_3" do in your application, regardless of whether you are using the Raytac, Nordic or Minew module?

[kaushalyasat]

Use of "button_3' in the CoAP client is to send a provisioning request. This code is not mine, it is the CoAP client example project from the NRF connect SDK.

static void on_button_changed(uint32_t button_state, uint32_t has_changed)
{
	uint32_t buttons = button_state & has_changed;

    ...
    
	if (buttons & DK_BTN4_MSK) {
		coap_client_send_provisioning_request();
	}
}

 

This is where it is used to invoke in coap_client.c to call 'coap_client_send_provisioning_request ()' function.

[Edvin]

Are you sure whether any of the packets in the sniffer trace are actually from the device you are testing (which is failing), or can the issue be that there are no packets on the air at all?

I don't remember by heart what registers that are used, but can you please try to read out these registers:

nrfjprog --memrd 0x10000060

nrfjprog --memrd 0x10000064

nrfjprog --memrd 0x100000A4

nrfjprog --memrd 0x100000A8

And let me know what these return?

Best regards,

Edvin

[kaushalyasat]

I can assure that during the packet capture there were only one server and one client in operation. 

The register contents of the client (Minew module) are as follows.

Register	Contents	Notes
0x10000060	0x78FB6AA5	FICR.DeviceID[0]
0x10000064	0xBB6363D5	FICR.DeviceID[1]
0x100000A4	0xD72EEB40	FICR.DeviceAddress0
0x100000A8	0x9CE7ACC0	FICR.DeviceAddress1

Cheers,