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,

[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,

[kaushalyasat]

Hi Edvin,

I managed to solve it. The issue was when I created the custom module based on nrf52840dk, I have missed the nrf52840dk_nrf52840.overlay file ( I had a similar file but it was all blank in my custom board def folder). After I moved this as nrf52840dk_nrf52840_Minew.overlay to my board folder, everything is working. 

I can see the packet transmission in wireshirk as well. 

Thanks you for all your help.

Cheers,