WIP: tests/ieee802154_hal: extend radio hal test

[LarsKowoll]

Contribution description

This PR adds multiple functions for the IEEE 802.15.4

• spam: Sends as fast and as many packets as specified in the parameters
• reply: The receiver sends the package back as soon as possible
• enable_prints: Prints interesting stuff. e.g. received packet. May has to be disabled due to timer issues caused by the printing
• test_channel: Sends and receive on different channels
• check_last_packet: Checks if the last packet matches to the expect sender

Testing procedure

There will be a automated test in riotctrl.

For manual testing you need two boards and flash it with tests/ieee802154_hal

Usage of the function spam:
Call spam on board with the parameters
spam <address_board2> <length_of_the_payload> <number_of_packets>

If you call spam with the parameters spam <address_board2> 5 3 1
The device will send a packet to device2 every 1 ms with a payload of 3 Chars in total 5 packets will be send.

You can set device2 in reply mode, means it will sends every packet back he receives, by calling the function reply. Just make sure to be easy on the delay otherwise the radio won't be able to handle this. You may disable the printing by calling the function enable_prints.

Issues/PRs references

None

[LarsKowoll]

With the following constellation the radios crash for unknown reasons:

Two remote-revb, one as a sender and the other one as a receiver in reply mode.
If I call the spam function with these parameters on the sender "spam 5 100 5" the sender will crash with the following output

Context before hardfault:
r0: 0x00000003
r1: 0x00000000
r2: 0x00000001
r3: 0x00000000
r12: 0x20000f53
lr: 0x00201def
pc: 0x00202220
psr: 0x21000000

FSR/FAR:
CFSR: 0x00000000
HFSR: 0x80000000
DFSR: 0x00000002
AFSR: 0x00000000
Misc
EXC_RET: 0xfffffffd
Active thread: 2 "event"
Attempting to reconstruct state for debugging...
In GDB:
set $pc=0x202220
frame 0
bt

ISR stack overflowed by at least 16 bytes.

If I replace the sender with a nrf52840dk and call spam again ("spam 5 100 0"), the receiver prints sometimes the following:

RFCORE_ASSERT(RFCORE_XREG_RXFIFOCNT > 0) failed at line 74 in rfcore_read_byte()!
RFCORE_SFR_RFERRF = 0x00

Using two nrf52840dk over IoT-Lab the receiver will crash with the following output, the sender however can catch one packet if printing is disabled at the receiver

0x9e5
*** RIOTInside isr 1

[jia200x]

Awesome!!

If I call the spam function with these parameters on the sender "spam 5 100 5" the sender will crash with the following output

This could be either the fact that the Radio HAL API is not being respected by the Radio HAL test or that something in the driver is wrong (for both radios). We haven't tried spam testing without sending ACK's in the middle, so this puts the radio in lots of stress. I will investigate

[jia200x]

Do we need to enforce socat here?

[LarsKowoll]

Yes, because when running the test over Release-Specs the output, without socat, will be:

['> ', '[PEXPECT_PROMPT+']
Exception 

I guess it is something related to RIOT Ctrl

[jia200x]

I will try to reproduce the issue here

[LarsKowoll]

Closed in favor of #16591