Coap server not working on a third party module

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,

  • Hi,

     

    Based on your description, your design is powered via VDDH ("VCC2" in your schematic), while the DK is powered via VDD_NRF by default.

    kaushalyasat said:
    But this puzzles me. You say if 1.8V it may be problematic to program the chip, but 1.8V is the default setting. This means when the nRF52840 chip is powered the first time, it will have 1.8V on VDD rail. Is there any other external pin setting which overrides this?

    No, it is not problematic for the nRF itself, it can be problematic for your design, as you've set 3.3V to the programming connector, which implies that this is the VDD_NRF voltage, as seen from the debugger/programmer side. However, since you are powering via VDD_H, the VDD_NRF is by default set to 1.8V.

     

    If you are able to successfully debug and program, then the above is no restriction for you.

     

    Were you able to sniff the traffic using the previously linked 802.15.4 sniffer?

     

    Kind regards,

    Håkon

  • Thanks Håkon,

    Ok I see your point. That make sense.

    Yes I did manage to setup the sniffer and sniff out the CoAP packets on wireshark. Even more strangely, now I can see the client sever connection is working!!! I dont know how. I hate these self healing problems. I couldn't recreate the sever no connection issue again. 

    Following is a capture from wireshark. Please let me know if things are as they should be.

    CoAP session-1.pcapng

    I am moving onto my next stage as my time is limited. But once the dust settles, I will recreate he projects from scratch to see if I see this problem again. 

    Thanks for all your help Håkon.

  • Hi,

     

    kaushalyasat said:

    Thanks Håkon,

    Ok I see your point. That make sense.

    Yes I did manage to setup the sniffer and sniff out the CoAP packets on wireshark. Even more strangely, now I can see the client sever connection is working!!! I dont know how. I hate these self healing problems. I couldn't recreate the sever no connection issue again. 

    Following is a capture from wireshark. Please let me know if things are as they should be.

    CoAP session-1.pcapng

    I am moving onto my next stage as my time is limited. But once the dust settles, I will recreate he projects from scratch to see if I see this problem again. 

    Thanks for all your help Håkon.

    Always happy to help out!

    I'm glad to hear that it started working again. Please let me know if you run into similar issues in the future.

    Hope you have a wonderful day!

     

    Cheers,

    Håkon

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

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

Related