Point to point communication using 802.15.4 between nRf52840 and CC2530?

[dd_microlynx]

Where to start? Is it possible?

I need to send data between the two chips using 802.15.4.

There is no need to form a network.

I was looking at the Wireless Uart example in SDK 15. It looks like what we need, but I am not sure how to add more functionality.

Is it by updating the "m_transition_table"?

We need to change the 15.4 channels with UART commands.

Thanks

[Edvin]

Hello,

This should be possible. I suggest you look into the SDK for Thread and Zigbee. It is found here.

Then you can look through a couple of the examples inside the thread folder. You need to decide on a protocol. Maybe you can use the set "simple_coap_server" and "simple_coap_client"?

 

Best regards,

Edvin

[dd_microlynx]

Hi,
Thanks for the fast response.

The CC2530 is already in the field and we can't change the protocol.

It uses 802.15.14 MAC layer only. Both radios have fixed addresses and PAN ID and need to send a messages to each other and get acknowledge.

The communication is not slotted CSMA/CA point to point, that is why I was thinking the Wireless UART is a good place to start.

Regards

[dd_microlynx]

Hello, 

It looks promising so far. Both radios are able to communicate but the nRf52840 throws an error under some conditions.  I can't debug the problem because I don't have the source files. 

Here is snapshot from the call stack:

[Edvin]

Hello,

What do you mean with "don't have the source files"? Do you use the SoftDevice in addition to the 802.15.4?

 

Can you try the following:

Define "DEBUG" in your preprocessor defines,

Disable Optimization (Set to -O0)

Set a breakpoint in app_error_weak.c on line 90 (NRF_LOG_ERROR("End of error report") ), and then add p_info to your watchlist.

 

Try to debug, and see if this breakpoint is hit. If it does, what is the function that returned the err_code that was passed into the APP_ERROR_CHECK(err_code); that the p_info is referring to? And what is the err_code?

 

Best regards,

Edvin

[dd_microlynx]

Hello, 

I was thinking that the problem was in a file that is part of the 802.15.4 library, that is what I meant with " I don't have the source files".  The problem was that we handle the 15.4 packet structure differently so I was able to fix it by modifying mcps_data_ind() function.

Now I have another question:

How can I use both UARTE on the chip. The reason I'm asking is that hal_uart.h says" /**< UART module number. By now zero is the only option.*/" .

Does this mean that with the provided drivers we can instantiate only UARTE0 ?

Some of our applications require both UARTs working.

Thanks

[Edvin]

Hello,

Sorry for the late reply. I assume that it is possible to use both of the UARTs with the 802.15.4 driver, but I am not sure exactly how. I have forwarded your question to someone who has worked with these drivers, and I will let you know as soon as I hear back from them. Again, sorry for the delay.

 

BR,

Edvin

[Edvin]

Hello,

Received a response today:

The 802.15.4 library uses some old uart hal files that was built for an older SDK when the nRF52 only supported one physical UART, so in this API, it is only possible to use one physical UART at the time. 

The suggested solution is to use one UART using the 802.15.4 driver, and another using the later versions of nrf_drivers for UART, found in some of the later SDKs (preferably SDK15).

 

Best regards,

Edvin