nRF52832 Radio

RE: nRF52832 Radio

xiaobai — Thu, 11 Mar 2021 02:06:36 GMT

I'm really sorry. I checked out the problem on our side.The reason is that one of my previous engineers modified the values of PACKET_STATIC_LENGTH macros and PACKET_BASE_ADDRESS_LENGTH macros in Radio_config.h file without notifying me, so that I did not deliberately check these values when I migrated the official SDK, resulting in the wrong radio setting at last. I am really sorry for the trouble!

RE: nRF52832 Radio

Jørgen Holmefjord — Wed, 10 Mar 2021 14:35:31 GMT

Sorry for the slow reply. I'm still looking into your issue, should get back to you in a few days.

Best regards,
Jørgen

RE: nRF52832 Radio

xiaobai — Sat, 06 Mar 2021 09:35:40 GMT

Hello, are you still there?I do not know how the situation is still the same, or still can not receive information, also can not send out the message.The HEX file generated by the project I uploaded is downloaded to DK52832.

RE: nRF52832 Radio

xiaobai — Wed, 03 Mar 2021 02:39:35 GMT

This is the log of the radio project that can receive and receive normally in my project. I can search the device with the bluetooth address of ff:ff:ff:ff:ff:ff via the NRF Connect tool on my mobile phone.

The above figure is the log of the project I downloaded from git to nRF52832 development board (with printing added). The original intention of this routine is the same as that of my above routine, both of which want to send and receive BLE broadcast through radio simulation.However, I found that this routine not only sent the phone is not scanned, but also received the error.

RE: nRF52832 Radio

xiaobai — Wed, 03 Mar 2021 02:28:02 GMT

I used this routine mainly because I wanted my label to use RADIO to simulate and receive BLE broadcast packets. However, when I downloaded the HEX file generated by this project into the nRF52832 development board, I found through the tool that the development board did not seem to send out my simulated broadcast packets, and the broadcast packets received were wrong.

RE: nRF52832 Radio

hmolesworth — Tue, 02 Mar 2021 16:51:01 GMT

The code in main.c assumes a low-frequency 32kHz crystal is fitted to the module/board; is that the case? If not then this will stop any BLE operation, in which case just change to non-crystal mode.

    /* Start low frequency crystal oscillator for app_timer(used by bsp)*/
    NRF_CLOCK->LFCLKSRC = (CLOCK_LFCLKSRC_SRC_Xtal << CLOCK_LFCLKSRC_SRC_Pos);

RE: nRF52832 Radio

Jørgen Holmefjord — Tue, 02 Mar 2021 16:17:56 GMT

Still not sure I understand what is failing. I ran your code on two DKs, one nRF52 DK (with nRF52832) and one nRF52840 DK. Both seems to be sending and receiving packets, and printing something to the UART terminal.

If I run both kits at the same time, the logging is much faster, which I assume is because the kits are receiving packets from each other.

RE: nRF52832 Radio

xiaobai — Mon, 01 Mar 2021 11:19:10 GMT

The above is based on the Radio of the official 15.2 SDK. Could you please help me to have a look at the reason why Radio related functions cannot be used in this SDK

RE: nRF52832 Radio

xiaobai — Mon, 01 Mar 2021 11:15:35 GMT

gitee.com/.../nrf_radio_test.git

RE: nRF52832 Radio

Jørgen Holmefjord — Mon, 01 Mar 2021 10:11:43 GMT

If you can upload the full project and source codes, I can try to run and debug it.

Writing down the code from your screenshots will take too much time.

RE: nRF52832 Radio

xiaobai — Mon, 01 Mar 2021 02:44:16 GMT

As you said, it is true that I used the library function to initialize the clock, but even if I changed the initialization of the clock and radio to register operation, they still could not be sent out.The screenshot above is the project I modified in the Radio routine of the official SDK15.2 version. Radio is used to simulate the sending and receiving of broadcast packets, but both sending and receiving failed.Could you please help me to see which side caused the problem? Thank you.

RE: nRF52832 Radio

Jørgen Holmefjord — Fri, 26 Feb 2021 15:04:44 GMT

Hi,

You are right that most of the code you have posted writes directly to the registers and should not be affected by the SDK version. However, the clock_init function seems to use the SDK driver, and may be affected.

What exactly is not working after migrating to the later SDK versions? Does it not send/receive packets? Do the application crash? Is there any error codes from the clock drivers?

What was the original SDK version of the project?

Was this written for the same chip variant as you are running it on?

Best regards,
Jørgen