pelioniot/atmel-rf-driver

atmel-rf-driver's Issues

Compile error #1113 on driverAtmelRFInterface.cpp by armcc

driverAtmelRFInterface.cpp", line 50: Error: #1113: Inline assembler not permitted when generating Thumb code

__asm__ volatile ("nop");
^
I modified the local code as below to fix:

#if defined(__CC_ARM)
        __nop();
#else
    __asm__ volatile ("nop");
#endif

DEVICE_I2C requirement in atmel-rf-driver

Recently in cd49e2e the build guard for DEVICE_I2C has been introduced. Most devices use this driver with the AT24MAC chip, but this is not a necessity. You can also run this radio (and the driver) without that chip and provision the MAC in a different way and pass it to the driver via NanostackRfPhyAtmel::set_mac_address(uint8_t *mac).

Cannot open source input file "nanostack/platform/arm_hal_phy.h": No such file or directory

I am following the procedures from here:
https://docs.mbed.com/docs/building-an-internet-connected-lighting-system/en/latest/4_connectivity/

The mbed-os version is 5.1. I got this error:
Cannot open source input file "nanostack/platform/arm_hal_phy.h": No such file or directory

Can't get frame received interrupt

On NUC472 platform, atmel-rf-driver could work in mbed OS 3.0, however it can't get any frame received interrupt in mbed OS 5.0 .
So, I measured I2C, SPI & IRQ pins. I2C & SPI read/write 1st 36 bytes are the same with K64F, thus pins are fine. More,rf_if_interrupt_handler() & rf_handle_tx_end() are invoked, it reveals IRQ pin also working fine. I tried to add 25000ns delay inrf_if_spi_exchange(), K64F also suffered "no received interrupt" symptom.

I suspect the timing of sending SPI data sequence into RF was changed in RTOS version and it seems impact atmel RF behavior. Should I tune any parameter in this driver to fulfill NUC472 platform ?

Do not hard-code pins in the driver

The pins of the driver are hard-coded at the moment:
https://github.com/ARMmbed/atmel-rf-driver/blob/master/source/at24mac.cpp#L33
https://github.com/ARMmbed/atmel-rf-driver/blob/master/source/driverAtmelRFInterface.cpp#L24 ff.

Hard-coding the pins in the driver, makes it hard to re-use the driver. At the moment you cannot compile this driver against a different target than the K64F. E.g. the F429 does not announce the Arduino Pins (related to ARMmbed/target-st-stm32f429i-disco#17 ).

It would be better to use symbolic names given to the driver from the application's or target's config.

Can't build driver when FEATURE_COMMON_PAL is missing - no mention of this in the docs

FEATURE_COMMON_PAL needs to be in mbed_app.json, otherwise on build you get the error "fatal error: platform/arm_hal_interrupt.h:".

Can you add this to the docs? I couldn't find mention of it.

Please talk to @janjongboom if you need more information about the build error.

driverRFPhy.c general for all RF

For RF solution, it needs RF driver and base-band code with HW independent scenario or control (for ex: hopping). So far, sal-stack-nanostack seems cover base-band code.
In driverRFPhy.c, except rf_init_phy_mode() & rf_scale_lqi(), other functions seem general for all RF.
Do you consider to isolate driverRFPhy to let RF driver concisely ?

Monitor underrun with a counter

Please consider being able to monitor the underrun condition.

https://github.com/ARMmbed/atmel-rf-driver/blob/28ab8d6450074c378881e028def1e54faf731e99/source/NanostackRfPhyAtmel.cpp#L1106

ACK are missed on STM boards because of SPI exchange that are no fast enough

I'm opening this issue in continuity of this one where we identified the source of the probleme : ARMmbed/mbed-os#4246

The problem is detailled in the last comments, starting with the comment of kjbracey-arm of may the 11th.

To summarize:

After sending a frame to the ATMEL buffer, the MCU should wait for a TRX_END interrupt, indicating that the transfer is done.
When this interrupt is detected, the MCU should change the state of the ATMEL 6LoWPAN chip to RX_AACK_ON within the 192µs, in order to be ready to receive the ACK.

But on STM MCU that we used (STM32L476ZG, NUCLEO_L476RG, NUCLEO_F401RE) the Time between 2 SPI exchange (CMD and response for example) is about 3 times longer on ST boards that the K64F.
Because of that we manage to realize the turnover in about 300µs which is too much ! So all the ACK are missed and the chip send every frame 5 times before giving up.

Bellow are some screenshot of the first SPI transaction that happen just after the TRX_END interrupt (when the board try to answer a PING). As you can see it is faster on the K64F. We can also see that it depends more on the systemcoreclock than the SPI frequency:

• K64F at 120 MHZ, with SPI at 7.5 MHz:
  
• STM32L476 at 60MHz, with SPI at 7.5MHz:
  
• STM32L476 at 80MHz, with SPI at 5MHz:
  

Cannot compile for Cortex-M0 on GCC

Compile [  4.1%]: NanostackRfPhyAtmel.cpp
/var/folders/84/tqqdqp696j73582q658x7pkx0l_yxp/T//ccbnV0ER.s: Assembler messages:
/var/folders/84/tqqdqp696j73582q658x7pkx0l_yxp/T//ccbnV0ER.s:459: Error: instruction not supported in Thumb16 mode -- `subs r0,r0,#1'

CC: @kjbracey-arm

atmel-rf-driver not coexisting without having .mbedignore -file

Same issue as with STM-Spirit1-RF - you can't have the atmel-rf-driver existing in the compilation path w/o an .mbedignore file without hitting compilation issues. This seems to be due to Nanostack missing, but if I'm not using any of these - the mbed_app.json in those cases should not need to have the NANOSTACK feature.

A compilation of mbed-os-example-client with K64F using the wifi-esp8266-v4.json will reproduce this.

gb-cam-ci-mbed-gw-build:~/mbed/mbed-os-example-client> mbed compile -m K64F -t GCC_ARM
Building project mbed-os-example-client (K64F, GCC_ARM)
Scan: .
Scan: env
Scan: mbed
Scan: FEATURE_STORAGE
Scan: FEATURE_COMMON_PAL
Scan: FEATURE_LWIP
Compile [  0.2%]: NanostackRfPhyAtmel.cpp
[Fatal Error] NanostackRfPhyAtmel.cpp@18,44: nanostack/platform/arm_hal_phy.h: No such file or directory
[ERROR] ./easy-connect/atmel-rf-driver/source/NanostackRfPhyAtmel.cpp:18:44: fatal error: nanostack/platform/arm_hal_phy.h: No such file or directory
 #include "nanostack/platform/arm_hal_phy.h"
                                            ^
compilation terminated.

[mbed] ERROR: "/usr/bin/python" returned error code 1.
[mbed] ERROR: Command "/usr/bin/python -u /home/jankii01/mbed/mbed-os-example-client/mbed-os/tools/make.py -t GCC_ARM -m K64F --source . --build ./BUILD/K64F/GCC_ARM" in "/home/jankii01/mbed/mbed-os-example-client"
---

Cannot open source input file "nanostack/platform/arm_hal_phy.h": No such file or directory

Hello,
When following the example https://docs.mbed.com/docs/building-an-internet-connected-lighting-system/en/latest/ I am getting the error "Cannot open source input file "nanostack/platform/arm_hal_phy.h": No such file or directory ". I am trying to connect the K64F via ethernet but when I try to compile the project it fails.

Any ideas how to fix this?
Thank you.

NanostackRfPhyAtmel.cpp warnings

Description

Mbed OS 5.9.1 (and earlier)
IAR ANSI C/C++ Compiler V7.80.1.28/LNX for ARM

08:50:40 [Warning] NanostackRfPhyAtmel.cpp@386,14: [Pe177]: function "rf_tx_power_set" was declared but never referenced
08:50:40 [Warning] NanostackRfPhyAtmel.cpp@1377,29: [Pe177]: function "rf_ack_wait_timer_stop" was declared but never referenced
08:50:40 [Warning] NanostackRfPhyAtmel.cpp@2011,28: [Pe177]: function "rf_tx_power_get" was declared but never referenced
08:50:40 [Warning] NanostackRfPhyAtmel.cpp@2023,0: [Pe177]: function "rf_enable_antenna_diversity" was declared but never referenced

Allow other ways of providing the MAC

In https://github.com/ARMmbed/atmel-rf-driver/blob/4fb763e3a34c8ad501c111c1e007854349ae18ed/source/driverRFPhy.c#L118
it is required to read the MAC from a very specific chip, that is on the example shields:

    if (0 != at24mac_read_eui64(atmel_MAC))
        return -1; //No MAC

For other hardware, that does not have the same chip providing the MAC, you therefore require to fork atmel-rf-driver and modify it. The only modification required is to comment/delete the two lines above and set the MAC before calling rf_device_register().

Please allow for an MBED_CONF_* config value to disable this fragment. Then we do not need to fork this repo.

Missing mbed_lib.json

The mbed_lib.json file is missing in the repository after refactoring the atmel rf driver. In order to build the border router (thread or 6lowpan) for Raspberry Pi HAT, radio reset pin needs to be re-configured to a different pin. When mbed_lib.json was available, i was able to re-configure the radio reset pin using mbed_app.json, which is not possible anymore. Is there a particular reason why mbed_lib.json is removed? or the is the library config is moved to a different place?

Cannot open file driverRFPhy.h

Problem

The PR : #40 removed driverRFPhy.h, which is relied upon by mbed-os, this breaks the examples being used for techcon.

Error: Cannot open source input file "driverRFPhy.h": No such file or directory in "extras/mbed-os.lib/features/FEATURE_COMMON_PAL/nanostack-hal-mbed-cmsis-rtos/arm_hal_random.c", Line: 20, Col: 26

Solution

?? Please make your change backwards compatible or at least make sure it merges with mbed-os. As of right now you have broken our 6lopan example code.