KW41Z host-controlled example THCI

[gbh]

Hello,

I'm trying to use the ble_thread_host_controlled_device demo in the KW41Z connectivity software package. I'm able to build and flash the boards, and I've been able to get a network set up using the remote interface. Ping works, UDP echo works, but I haven't been able to send data back and forth between the devices using sockets, or at least I haven't been able to receive it. I've attached logs from both boards. So far I've only tried to control the devices using the Test Tool. I haven't made any changes to any of the build flags. I've only made changes to the .cproj file in order to get the project to build.

The attached logs go roughly as follows:

Several GetAttribute and other status requests to show the boards are connected to the same network and commissioned.

EchoUDP commands from both sides.

Set up UDP datagram sockets bound to port 60 on each side

Module A sends "ABC" to module B

Receive on module b returns no data.

What am I doing wrong here? Is there a more instructive guide I missed in the stack documentation, or am I just failing to understand sockets?

I tried following the code through the debugger, but stepping was leading to strange behavior, so I wasn't able to follow it very effectively. Is that something to do with FreeRTOS? I'm pretty new to that as well. I've only used FreeRTOS on an ESP8266, with no debugger.

As a side note, I want to mention that the project files generated by the project cloner had invalid relative paths. They escaped out to one directory higher than they should have (an extra ..\). They also didn't have the ProjDirPath variable in them, which I think is required, but I didn't test it without. I cloned the project to a drive other than the windows install drive (the SDK is installed on C: as well). I also had very strange issues with gcc returning paths that were missing a single character (e.g. "/middleware/wirless/" - missing an 'e' in wireless) and saying it couldn't find files. The actual paths were correct other than the issue I mentioned above. I worked around this in one project by adding another ../parentDirectory/ to the path somewhere. This happened with KDS 3.1 and 3.2.

Thanks,

Ben

Original Attachment has been moved to: module_b.log.zip

Original Attachment has been moved to: module_a.log.zip

[jc_pacheco]

Hello Ben, 

This seems to be an issue with the clock on your custom board, I'm unable to reproduce using the FRDM hardware. 

Can you please double check the System Clock and Bus clock: 

CLOCK_GetCoreSysClkFreq();
CLOCK_GetBusClkFreq();‍‍‍‍

And you can also measure the frequency using a CLKOUT pin (PTB3 -> Mux_ALT4  or   PTB0 -> Mux_ALT7), by default you'll get OSCERCLK DIV2 but you can select Bus Clock as the CLKOUT output with SIM_SOPT2 ->CLKOUTSEL register value = 0x02.

GpioSetPinMux(gpioPort_B_c, 3u, pinMux_Alt4_c);‍‍

A way to reduce the Commissioning time is to use Out-of-band commissioning, which will not exchange the key from the commissioner but use the pre-configured network settings.

See app_thread_config.h -->  

#define THR_DEV_IS_OUT_OF_BAND_CONFIGURED FALSE --> TRUE
‍‍‍

The 32K XTAL is generally used for low power but can be used for system clk as you can see by default. If you are not using low power, it's ok to remove it and use the 32MHz XTAL, The 32MHz XTAL used in the FRDM-KW41Z is the Q22FA12800092 as you can see in the design files BOM.

Hope this helps.

-JC

[gbh]

I went back to the FRDM board with the stock ble_thread_host_controlled_device firmware, and only defined CLOCK_INIT_CONFIG=CLOCK_RUN_32 in the project properties. This yields the same behavior on the FRDM board that I was seeing from my custom boards. For reference, the label on the back of one of my FRDM boards lists 700-29102 REV A2, SCH-29102 REV A3.

I checked the return from the GetFreq methods and read 32000000/16000000 with the CLOCK_RUN_32 flag set, and 47972352/23986176 with the default clock config. The measurements on the OSCOUT pin matched these values as well, and my board behaves the same way.

With my new clock configuration on my custom board, I read 40000000/20000000, and the frequency output also matches.

I had seen the out-of-band commissioning feature of the Thread protocol. I'm more interested in speeding up the DTLS handshake, if it's possible.

My next issue is communicating with the KW41z over SPI. What's the protocol for this? I've got the FSCI messages basically implemented, copying the windows/linux driver logic, and comparing that output to the output of the test tool. How are the responses returned by the KW41z, though?

Thanks,

Ben

[jc_pacheco]

Can you describe the exact procedure to reproduce this in the FRDM-KW41Z boards? I'm unable to reproduce.

The commissioning procedure takes some time due the 6LoWPAN and DTLS encryption processing, I'll check if there's a way to try to reduce the time.

Could you please keep each topic as a separate community post? This way we can keep a better track of any issues/questions.

[gbh]

I cloned the project (ble_thread_host_controlled_device) for KDS, made the changes as described in the first post in this thread (fixing paths in .cproject) and then defined CLOCK_INIT_CONFIG=CLOCK_RUN_32 in Project Properties/"C/C++Build"/Tool Settings/Cross ARM C Compiler/Preprocessor. I then flashed the firmware to a KW41z FRDM board using the OpenSDA interface with the J-Link driver. From there, I used the test tool to create a network on that board, add expected joiner (selected, all 0xFF, 7, 'kinetis'), sync steering data,and attempted to join with my other KW41z FRDM board, which had the stock ble_thread_host_controlled_device firmware running on it. The joiner sends a hello, which is responded to with a HelloVerifyRequest, including a cookie. The joiner sends the cookie back in another ClientHello, but the board with the modified firmware never never sends a ServerHello.

New post created here for the SPI questions: MKW41z connectivity software THCI interface over SPI 

[jc_pacheco]

Hello Ben, 

For the record, KW2xD has its own sniffer firmware, please look for it at C:\NXP\Test Tool 12\images. I'll take a look at the logs and get back to you.

-JC

[gbh · Accepted solution]

Hey JC,

Got it figured out, at least partially. I put my modified firmware on the FRDM board and found that it performed the same way my custom board did. Switching back to the initial clock configuration had it performing like the unmodified firmware. I went through the default configuration and updated it to generate a 40MHz core clock from my external 32MHz xtal. The FRDM board and my custom board now send the ServerHello command, but it still looks like there's a less severe version of the same problem there.

The traces I collect from the unmodified firmware when joining a FRDM board to another FRDM board's created network don't typically have any retries. However, when running at 40MHz, the SeverHello and the ClientKeyExchange flights are both retried, and followed very quickly by what seem like they must be responses to the original requests, based on the time between the retry and the message. I've attached a trace that shows the DTLS handshake between my custom boards running at 40MHz.

What it seems like to me is that there's something assumed about the speed of the cryptographic operations required for those two messages which causes a retry to be sent, and then perhaps there's a bug in the stack around handling a retried ClientHello, which prevents any ServerHello from being sent, but maybe that's more conjecture than the devs would care to hear :smileyhappy:. In any case, I need to understand what the issue is here.

I take it the recommended hardware configuration for this part is to use the 32.768kHz oscillator to generate a 48MHz clock, but can it then run without the main oscillator? I'd prefer not to mount both.

I noticed there's a ~7s delay between some of the message flights in the DTLS handshake when running at the 48MHz clock. Is this typical for thread devices? How can we reduce the amount of time it takes to set up a network?

Also, I thought I saw a mention of a library that implements the control side of the THCI, but I haven't been able to find it. I found the HomeKit SDK, but that appears to be for BLE with the kw40.

Thanks,

Ben

[HastiGondaliya]

Hello @jc_pacheco and @gbh,

I'm using KW41Z as a host (using hybrid_ble_thread_host_controlled_device demo) and end-device/REED (using hybrid_ble_thread_router_wireless_uart demo) for the thread network. I'm able to create the thread network, join the network. I'm also able to send and receive data over the socket successfully.

I want to do this communication with DTLS as shown in "

custom_leader_custom_joiner_retries.pcapng.zip

" logs.

How this DTLS handshaking and communication can be done in hybrid_ble_thread_host_controlled_device and hybrid_ble_thread_router_wireless_uart?

Can you please share some detail on this?

[gbh]

Hey JC,

I got the sniffer working with the KW2xD last night and took a few traces. One shows a successful commissioning session with my custom board joining the FRDM leader/commissioner, one shows my custom board as the leader/commissioner and the FDRM is unable to join, and a third where I joined my custom board to the FRDM's network and then established that custom board as the commisioner, and a second FRDM board is unable to join the network.

In both cases where my device is performing commissioning, a hello verify request is sent by the commissioner, and responded to by the joiner, but there's no server hello. I don't see any difference in the DTLS packets, and the cookie matches on the hello, so I'm trying to figure out why the server doesn't continue the session.

I've verified in the debugger that the expected joiner is found on my custom board by looking at the APP_MeshcopValidateJoinerAddrCb function in app_thread_callbacks.c, and the LED flash rate makes it look like the firmware knows how the clock is configured; my board toggles the LED at 4.99Hz, the FRDM board toggles at  4.96Hz, and the app specifies a toggle period of 100ms, so that all seems to make sense.

BTW, I'd recommend indicating using the test tool for flashing in your writeup here: Use KW24D512 as Sniffer in Wireshark. It took me a bit to figure that out and I managed to apparently brick one of my KW24 boards in the process; cmsis-dap port doesn't show up as a USB device at all, much less enumerate

[jc_pacheco]

Hello Ben,

By default the Project Cloner uses "MyProject_01" as project name and "C:\Temp" as destination path.
If too longer strings (paths) are used, then KDS will not be able to understand the relative paths due to Windows OS Longer File Name Limitation. This is a known issue with Windows OS.
Same issue will be found on multiple IDE's.

Regarding the sockets:

There's a known bug that will be fixed in the upcoming maintenance release where the data received by the firmware on FSCI (Test tool) is incorrect. Nevertheless, I'm attaching the expected procedure to create and send UDP data through a socket when this is released.

Meanwhile you can verify the usage of sockets using the SHELL demo and enabling the "#SOCK_DEMO" macro at config.h. 

Regards,

JC

[gbh]

Hey JC,

I'm working with the sockets again on my device, and I'm wondering what the exact nature of the error is in the test tool. I've compared the commands you sent with the commands the test tool is sending, and they look the same other than the addresses, socket indices, payloads, and (obviously) the checksums. Can you offer a bit more detail on that issue? 

Also, I assume I need to poll the receive in order to actually get data back. Is that correct?

Thanks,

Ben

[gbh]

Thanks for the response, JC. If I understand you correctly, the FSCI implementation in the stack itself is fine. I'm ultimately going to control the MKW41Z on my board with a K64, does the FSCI implementation there have the same issue?

I haven't had a chance to look at the shell demo, but I now have a custom board in-house with the MKW41Z512VHT4 on it, and I'm trying to get back to the point where I'm able to join it to the same network as one of my FRDM boards, but I'm having some issues with it. I'm able to create a network on the KW41-FRDM board, and connect to it from my custom board, but it doesn't work the other way around, when my device behaves as a leader/commissioner. I hadn't changed any of the build flags, so I went through the definitions in the KDS project tonight and updated them to match my hardware, but nothing changed.

The KW41z on my board will create a network, establish itself as leader/commissioner, and responds with success to adding an expected joiner, syncing the steering data, and getting that expected joiner. The DTLS session starts as well, but ultimately fails with JoinerDtlsError. The documentation only suggests that this might be an incorrect PSKd, but I've verified that the expected joiner command specifies "kinetis" (all commands being sent to create the network and configure the commissioner on the custom board are identical to the ones sent to the FRDM board) and the FRDM board is running the app with only the build config modifications I made earlier (in my first post), not the other flag changes I made tonight (disabling LEDs, buttons, TSI, keyboard).

One thing I did have to do on my custom board was set the CLOCK_INIT_CONFIG to CLOCK_RUN_32, as with the default value (CLOCK_RUN_48_24) was hanging in CLOCK_SetFeeMode (called from BootToFeeMode) while waiting for IREFST to change. My design is basically the same as the FRDM board, but without the DCDC components (running bypass), and with a 32MHz osc (the FRDM schematic says 32MHz, but has a 27.648MHz xtal mounted), at 10ppm tolerance/stability (50/NA on the FRDM part), and 10pF load. (I just now noticed that frequency discrepancy, I guess that's why it's hanging). I also see that the config I'm using now is BLPE, and the core clock is 32MHz, vs a comment that says the config for the FRDM board is 48MHz. Maybe that's the issue.

I've put a breakpoint in the APP_Commissioning_Handler while debugging from my board, which is a switch statement on the parameter code. Regardless of the value passed in, if I put a breakpoint in the case for the JoinerError and the JoinerDtlsError (a common case) it is always hit.

So is there any way I can get more detail on this DTLS failure? Or maybe I've missed a build flag I need to set to account for my different oscillator speed?

Thanks,

Ben

[jc_pacheco]

Hello Ben, 

Indeed, if you are using the 32MHz reference you should change to CLOCK_RUN_32. More details in this post: Change clock configuration when 32 kHz oscillator is not available 

If you are running in bypass mode, you should also change:

DCDC.h

#define gDCDC_Enabled_d    1 -->  0‍

board.h

#define APP_DCDC_MODE    (gDCDC_Mode_Buck_c)  -->  (gDCDC_Mode_Bypass_c)
‍

ON the DTLS failure, if you are running the exact same steps, how is the RF performance on your board?

Are you using out of band comissioning?

What commands did you set for permitting joiners?

If you are using THCI, did you confirm that the comissioner started successfully?

Can you please attach a wireshark log?

-JC

[gbh]

Hey JC,

I've made the DCDC changes you've suggested. No change in operation, but I don't know that that's an unexpected result.

I don't have a sniffer in house, but I just ordered the USB-KW41z to do this and I'll respond with that this weekend, if necessary. Unfortunately, it looks like the binaries for that sniffer application won't work with the FRDM board due to the different SDA uC. I've also got a couple of KW24-FRDM boards, but obviously, the KW41z binary won't work on that. So for now, I've attached logs from the test tool for now, one from each board in each configuration.

I don't really have much of an idea about my board's RF performance yet. I can tell you that I followed the KW41z reference design, with the exception that I have a chip antenna on my board. There is an etch keep-out under the antenna (as specified by the manufacturer), and the board was spec'd to be controlled 50 ohm impedance. My custom board is is mounted on a breakout board, which has a ground plane that isn't broken under the antenna. The bottom of my wireless board is about a quarter inch from the breakout board. I've tried moving the FRDM board around and changing the orientation of the antennas without any apparent change.

I'm using in-band commissioning at the moment. I'm really just getting started with this, and haven't made any modifications to the code, other than the build flags for the hardware configuration.

From what I've been able to verify in the source, it looks like data is getting to the stack OK from the test tool. I specifically verified the 'kinetis' string use for PSK is in the correct field in the THCI handler. Is it possible to get the source for the thread stack? It would be nice to be able to debug a bit more in depth to understand what's going on. We're planning on using BLE as well.

I've been reviewing my schematic and ran across some notes I made in the reference manual. In CH14, the diagram given for bypass differs from the one given in 3.4.4.3. In 3.4.4.3, it indicates that DCDC_CFG is to be pulled low along with PSWITCH for bypass, while 14.1.4 indicates that DCDC_CONFIG is meant to be pulled high, and PSWITCH is grounded. I noted that from looking at the FRDM board, the diagram in 14.1.4 is correct, and connected it to VCC on my board. I have also connected the VDD_1P5OUT to VCC, which also seems correct. VCC is 3.3v, by the way, and the supply looks clean.

I also noticed tonight that VDD_XTAL is not shown in the pinout, but the reference manual shows it connected to VCC. My best guess is that that's VDD_RF3, since that pin isn't referenced anywhere else.

Thanks,

Ben