Riot: gnrc_minimal on nRF52DK do not work anymore

[Citrullin]

Description

The gnrc_minimal example do not work on the nrf52832 anymore

I worked on another branch on the gnrc networking on BLE. So, I checked the old branch and it works fine there. (Last commit on the old branch: 60008cbb2e6afbf3a39116192fcac02b5454e87b)

I also tried to use the nordic ble package without the gnrc packages. Simple ble advertising test.
Just add the nordic package to your Makefile

USEPKG += nordic_softdevice_ble

Add this to your main

    puts("Hello World!");

    printf("You are running RIOT on a(n) %s board.\n", RIOT_BOARD);
    printf("This board features a(n) %s MCU.\n", RIOT_MCU);

    ble_stack_init();
    ble_advertising_init("RIOT BLE");
    ble_advertising_start();

and import ble-core.h

This also does not give you any feedback. No ble advertising, no serial console message. So, I guess the problem is somewhere placed in the ble library wrapper or maybe even in the library itself.

Steps to reproduce the issue

1. Checkout the master branch (commit: e3e2b6df153925b16e083f0cea631f10922e2d28)
2. Connect the nRF52 DK board to an USB-to-UART adapter and to your J-Link
3. Open the serial monitor. With term, platformio device monitor, screen or something else.
4. Flash the gnrc_minimal example with a J-Link.

Expected results

Do the same as before, but check out the commit: 60008cbb2e6afbf3a39116192fcac02b5454e87b

Result in the serial console:

main(): This is RIOT! (Version: 2018.10-devel-413-g60008-[SOME_HOSTNAME]-HEAD)
RIOT network stack example application
My address is [SOME_ADDRESS]

Actual results

Empty serial console, no message appears.

Versions

Installed compiler toolchains

-----------------------------
             native gcc: gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
      arm-none-eabi-gcc: arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
                avr-gcc: missing
       mips-mti-elf-gcc: missing
             msp430-gcc: missing
   riscv-none-embed-gcc: missing
                  clang: missing

Installed compiler libs
-----------------------
   arm-none-eabi-newlib: "3.0.0"
    mips-mti-elf-newlib: missing
riscv-none-embed-newlib: missing
               avr-libc: missing (missing)

Installed development tools
---------------------------
                  cmake: cmake version 3.10.2
               cppcheck: missing
                doxygen: missing
                 flake8: missing
                    git: git version 2.17.1
             coccinelle: missing

[PeterKietzmann]

@Citrullin 1. your title states gnrc_networking but your description says gnrc_minimal. Please correct the wrong one. 2. When you say "advertise" do you mean BLE advertisements or simply the serial output? 3. AFAIK there are different BLE applications in examples/. What do you try to do with BLE and the above mentioned applications?

@haukepetersen, @SemjonKerner please help!

[SemjonKerner]

Thx for the ping.
I can reproduce that gnrc_minimal has no output on master and correct output on 60008cb.
We might have found a similar problem with gnrc_minimal a week ago. @haukepetersen suspects the ble softdevice to be a bit unreliable atm...

And please adapt the title, as Peter said, took me a minute..

[Citrullin]

@PeterKietzmann Better now?

[SemjonKerner]

@PeterKietzmann Better now?

Uhm not really, @Citrullin please specify gnrc_minimal in the title. I am pretty sure that gnrc_networking is working on nrf52dk on master. I was wrong

[Citrullin]

@SemjonKerner I flashed gnrc_minimal, gnrc_networking, gnrc_networking_mac. All of them result in the same behaivour. But okay, I just add gnrc_minimal in the headline & description. I am on commit 7cb1049eefefdfcd801efac59a7c1658fb429077

[PeterKietzmann]

I flashed gnrc_minimal, gnrc_networking, gnrc_networking_mac

So it's not a specific application, it's the network device, most likely the nordic softdevice package. Can you try to build like USEMODULE=nrfmin make ...?

I also tried to use the nordic ble package without the gnrc packages

And what was the outcome?

Just out of interest: Why don't you give nimble a chance? Are there missing features?

[Citrullin]

And what was the outcome?

Checked Bluetooth with my smartphone: No device and the serial console is also empty.

So it's not a specific application, it's the network device, most likely the nordic softdevice package. Can you try to build like USEMODULE=nrfmin make ...?

make USEMODULE=nrfmin BOARD=nrf52dk flash results in

/home/citrullin/git/RIOT/cpu/cortexm_common/vectors_cortexm.c: In function 'nmi_default':
/home/citrullin/git/RIOT/cpu/cortexm_common/vectors_cortexm.c:138:16: error: 'PANIC_NMI_HANDLER' undeclared (first use in this function)
     core_panic(PANIC_NMI_HANDLER, "NMI HANDLER");
                ^~~~~~~~~~~~~~~~~

Just out of interest: Why don't you give nimble a chance? Are there missing features?

Do we also have the IPv6 stack for nimble? As easy as gnrc? I am currently working with nimble to get mesh networking running. Eventually it would also be nice to have direct addressable devices with IPv6 there. Maybe this does not need to be directly on the device. It would be fine to have a gateway which takes care of it and routes the data to the correct device. But first things first. :) I have still some issues with the compiling.

[Citrullin]

@PeterKietzmann I looked more into the topic and I have to say that I also would prefer NimBLE with the IPSP service. NimBLE does not support the IPSP service at the moment. I have seen that some people are currently working on the nrf52840 ieee802.15.4 driver. Which is really nice and removes the overhead of Bluetooth. On the other hand Bluetooth >= 4.2 is still used a lot. So it would be still worth it to invest the time to implement 6LoWPAN on it. Maybe this issue is a nice reminder to remove the support for the proprietary nordic library and move completely to nimBLE.

[cladmi]

I was going to post an issue. I just found about the same thing while executing examples/default on nrf52dk. examples/gnrc_networking also does not print anything.

[cladmi]

By bisecting from master to 60008cbb2e6afbf3a39116192fcac02b5454e87b I found the commit introducing the issue was 64489e8b444efde859e9f048b17707e5da88a983

Commenting the FEATURES_OPTIONAL += periph_hwrng it correctly prints in example/default.

[Citrullin]

@cladmi I also checked the old version, It looks like it didn't work for a while now. Even if you get an IP address, the actual connection does not work. In one version, I connect via Bluetooth to the device, getting weird character and it crashes. In another version, I connect via Bluetooth to it, setup the 6LoWPAN stack on my linux machine, try to get the IP address with ifconfig and it just stops, no feedback. I try Zephyr at the moment though. I need some stable and simple to use setup for our sending data to the tangle documentation.

[haukepetersen]

The problem could be caused by RIOT's random module now using the hwrng as seed generator. This is probably not a good idea in conjunction with the SoftDevice, as the SoftDevice 'claims' the RNG peripheral for itself (Restricted access).

Now why exaclty the periph_hwrng peripheral is selected in the first place for this build is something I have not yet figured out...

[kaspar030]

Now why exaclty the periph_hwrng peripheral is selected in the first place for this build is something I have not yet figured out...

Maybe #10974?

[haukepetersen]

yes, I did read the ifeq for a ifneq, so the FEATURE_OPTIONAL line in the Makefile.dep does include that feature in our case.

[haukepetersen]

Now about fixing this: Seems to me the cleanest approach is to put an ifdef around the hwrng_read() function in cpu/nrf5x_common/periph/hwrng.c and map the read() function to use the SoftDevice API for getting random numbers if the SoftDevice is build in. But on a quick glance I failed to find the correct API description to do this...

[haukepetersen]

For reference, the softdevice doc (although in this case its for the S140): it defines the RNG peripheral as Restriced and this is defined as:

Restricted: The hardware peripheral is used by the SoftDevice and is outside the application sandbox. When the SoftDevice is enabled, it shall only be accessed through the SoftDevice API. Through this Application Programming Interface (API), the application has limited access.

[PeterKietzmann]

yes, I did read the ifeq for a ifneq, so the FEATURE_OPTIONAL line in the Makefile.dep does include that feature in our case.

IMO that was intended?!

Seems to me the cleanest approach is to put an ifdef around the hwrng_read() function in cpu/nrf5x_common/periph/hwrng.c

The fix should definitely be applied next to the platform, not in sys/random. Ideally, dependent on the SoftDevice. Is it possible to exclude the HWRNG feature via Makefile in case SoftDevice is required?

[miri64]

Since this is referencing gnrc_minimal: Here is the solution that solved my problem in #11067 ;-) https://github.com/RIOT-OS/RIOT/pull/11067#issuecomment-470487587

[Citrullin]

Since this is referencing gnrc_minimal: Here is the solution that solved my problem in #11067 ;-) #11067 (comment)

Thanks. I will try this. Maybe that was just my problem when I was on the old commits. :)

[danpetry]

@Citrullin have you tested the fix at all yet?

[PeterKietzmann]

@Citrullin please try with #11559

[cladmi]

@MrKevinWeiss I updated the milestone to the release. It is an important fix to mention that examples/default and examples/gnrc_minimal work again on nrf52dk.

[MrKevinWeiss]

Thanks!