In the RTT log:

00> [000] Sensor Action: Device booted
00> assertion "is_fs_init_completed" failed: file "...stack\framework\components\fs\fs.c", line 314, function: fs_file_stat

It happens at this point in sensor.c:

void bootstrap()
{
    log_print_string("Device booted\n");

    d7ap_init();

    alp_layer_init(NULL, false);   <<<--- Here !

    init_user_files();

Swapping the order of the alp_layer_init and d7ap_init calls - so that alp_layer_init comes first - seems to fix it.

SHA-1: 42d6bbf

Since all warnings are now treated as errors, the following warnings will cause compile errors and can not be used until the stack fixes these (minor) issues:

• "-Wshadow"
• "-Wextra" which results in: -Werror=sign-compare errors

Current implementation

process_async() parses incoming ALP actions and builds a response. If the ALP data contains ALP_OP_RETURN_FILE_DATA, this is copied to the response and the response is marked as 'unsolicited'. The response is then passed to the app callback via transmit_response_to_app(). The app may then handle the unsolicited data before the response is sent.

Unhandled data is echoed back

Any item that is not explicitly handled by the app remains in the fifo and is sent out as part of the response: apps must handle them, ortherwise they message is simply repeated back to the sender. I think that is not as intended?

Differentiating between unsolicited ALP_OP_RETURN_FILE_DATA and response to incoming ALP_OP_READ_FILE_DATA

What makes parsing from the callback extra tricky is that you can't just pop everything from the queue: anything that is popped and is not an unsolicited response is then missing from the response. What makes this especially difficult is that incoming ALP_OP_READ_FILE_DATA is parsed and translated into ALP_OP_RETURN_FILE_DATA before the callback is called.

It seems there is no way to know whether an ALP_OP_RETURN_FILE_DATA command is an incoming unsolicited request (that must be handled) or a response to an incoming ALP_OP_READ_FILE_DATA (that must not be handled since the framework has already done so).

Example

A client sends an ALP command consisting of two actions:

alp_append_return_file_data_action(command, FILE_ID_TO_SEND, 0, sizeof(to_send), (uint8_t*)&to_send);
alp_append_read_file_data_action(command, FILE_ID_TO_REQUEST, 0, 8, false, false);

The receiver then receives this data, parses the READ_FILE_DATA action into a RETURN_FILE_DATA response and calls the application callback alp_command_result_cb.

The application then sees two ALP_OP_RETURN_FILE_DATA actions. In case FILE_ID_TO_SEND and FILE_ID_TO_REQUEST are the same, the application cannot determine if the action must be parsed or must not be parsed..

See: https://groups.google.com/g/dash7-ap-oss/c/uWwnjiImqQM/m/GCZKSORVAQAJ

This is indeed a known issue with the RTT Logging. When it goes to sleep, it can repeat some logging. You can circumvent this issue by using FRAMEWORK_SCHEDULER_LP_MODE=255. This mode will actually keep the processor active at all times and logging will be very responsive and will not repeat itself. However, your program can react differently as it's not going to sleep and your power consumption will be a lot higher so this is purely for debugging

RTT v2.54 (November 2019) added SEGGER_RTT_GetAvailWriteSpace() - which, perhaps, could be used to defer sleeping until all logs have been sent?

See also: https://community.st.com/s/question/0D53W000014wcE5SAI/how-to-get-segger-rtt-to-work-with-sleep-modes-on-stm32

I believe that the way the UID is read on the STM32 platform is buggy.

From stm32_common_system.c:

uint64_t hw_get_unique_id()
{
  return (*((uint64_t *)(UID_BASE + 0x04U)) << 32) + *((uint64_t *)(UID_BASE + 0x14U));
}

The manual RM0376 section 33.2 states that there are 3 32 bit words that make up the UID, but it is ok to read them in different ways. So Making a 64 bit ID is fine.

The 3 words are:

• 0x1FF8 0050 - WAF_NUM + LOT_NUM[55:32]
• 0x1FF8 0054 - LOT_NUM[31:0]
• 0x1FF8 0064 - uniqueIDbits

Now, hw_get_unique_id() only uses the latter two words, however because of the cast (uint64_t *) they are read as 64 bit unsigned integers. this means we're reading 32 bits past the 0x1FF8 0054 value into undefined memory. Since we then shift left 32 bits, we get rid of those undefined bits. However we do the same for 0x1FF8 0064, which is not shifted. So the higher 32 bits of the UID is a combination of UID_BASE + 0x04U and UID_BASE + 0x018U.

I understand fixing this is not easy since there are already devices out there that use this format for UID. So far we have not encountered conflicting UIDs, but I am not sure if uniqueness is guaranteed with the current implementation.

Hi, I am back working on DASH7! I am testing compatibility with the WGATE-WRT gateway by Wizzilab.

Therefor I am either trying to connect the sensor_push app with the WGATE-WRT gateway. Or create a gateway that accepts one of the wizzilab demo devices.

According to Wizzilab, their gateway is configured with the following Access Profile:

AP2 (default, endpoint -> gateway)

modulation = FSK
rate = 55 kbps
bandwidth = 200 kHz
coding = FEC + whitening
rate = 1/2
TX power = 14 dBm (e.i.r.p)
scan period = 1/32 s (gateway scan)
channels = 868.1 MHz, 868.5 MHz, 869.075 MHz
duty = 3% per channel

The channel frequencies correspond to channel indices 200, 216, 239. I am trying to create the FS that is compatible with these settings:

/*! \file d7ap_fs_data.c

wizzilab_channel_header = ChannelHeader(
  channel_class=ChannelClass.NORMAL_RATE,
  channel_coding=ChannelCoding.FEC_PN9,
  channel_band=ChannelBand.BAND_868
)

# AP0
wizzilab_ap0 = AccessProfile(
  channel_header=wizzilab_channel_header,
  sub_profiles=[SubProfile(subband_bitmap=0x01, scan_automation_period=CT.compress(0))] * 4,
  sub_bands=[SubBand(eirp=14, channel_index_start=208, channel_index_end=208)] * 8
)

# AP2
wizzilab_ap2 = AccessProfile(
  channel_header=wizzilab_channel_header,
  sub_profiles=[SubProfile(subband_bitmap=0x05, scan_automation_period=CT.compress(0))] * 4,
  sub_bands=[
      SubBand(eirp=14, channel_index_start=200, channel_index_end=200),
      SubBand(eirp=14, channel_index_start=216, channel_index_end=216),
      SubBand(eirp=14, channel_index_start=239, channel_index_end=239),
      SubBand(eirp=14, channel_index_start=200, channel_index_end=200),
      SubBand(eirp=14, channel_index_start=200, channel_index_end=200),
      SubBand(eirp=14, channel_index_start=200, channel_index_end=200),
      SubBand(eirp=14, channel_index_start=200, channel_index_end=200),
      SubBand(eirp=14, channel_index_start=200, channel_index_end=200)
      ]
)

system_files = [
..
  (AccessProfileFile(0, wizzilab_ap0),                       sys_file_prop_perm),
..
  (AccessProfileFile(2, wizzilab_ap2),                        sys_file_prop_perm),
]

Then in the gateway I am selecting access class 0x21

void bootstrap()
{
  modem_interface_init(PLATFORM_MODEM_INTERFACE_UART, PLATFORM_MODEM_INTERFACE_BAUDRATE, (pin_id_t) 0, (pin_id_t) 0);
  d7ap_init();
  // listening on
  d7ap_fs_write_dll_conf_active_access_class(0x21);

And in the sensor_push app I am trying to send on 0x21

static alp_interface_config_t itf_config = (alp_interface_config_t){
  .itf_id = ALP_ITF_ID_D7ASP,
  .d7ap_session_config = {
    .qos = {
        .qos_resp_mode = SESSION_RESP_MODE_PREFERRED,
        .qos_retry_mode = SESSION_RETRY_MODE_NO
    },
    .dormant_timeout = 0,
    .addressee = {
        .ctrl = {
            .nls_method = AES_NONE,
            .id_type = ID_TYPE_NOID,
        },
        .access_class = 0x21,
        .id = { 0 }
    }
  }
};

However, in both directions I have no luck so far. Do you know if I am missing anything still?
When testing the gateway, I am running the unsolicited_response_logger.py.

Also I realized wizzilab is running D7A 1.2 vs 1.1 of this stack. Is that compatible?

I am working on a project where I use the stm32l0xx TSC peripheral. This specific file appears to be missing in CMakeLists.txt:

Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_tsc.c

Some other files are commented-out as well:

https://github.com/MOSAIC-LoPoW/dash7-ap-open-source-stack/blob/81742d70b00124335af5174a311f864e34077f31/stack/framework/hal/chips/stm32l0xx/CMakeLists.txt#L56-L80

I could make a pull-request to fix this. Or is there a reason that these files were excluded?

[ 83%] Building C object apps/noise_logger/CMakeFiles/noise_logger.elf.dir/noise_logger.c.obj
...stack\apps\noise_logger\noise_logger.c:32:10: fatal error: userbutton.h: No such file or directory
 #include <userbutton.h>
          ^~~~~~~~~~~~~~
compilation terminated.

There is, indeed, no such file anywhere in the source tree.

Source tree cloned from GitHib this morning; SHA-1: 42d6bbf

CMake command line:
cmake ..\stack\ -DFRAMEWORK_CONSOLE_ENABLED=y -DPLATFORM_USE_NUCLEO_IKS01A2_SHIELD=y -DAPP_GATEWAY=y -DAPP_SENSOR_PUSH=y -DAPP_SENSOR_ACTION=y -DAPP_SENSOR_PULL=y -DAPP_NOISE_LOGGER=y -DAPP_SIMPLE_LEDS=y -DAPP_SNIFFER=y -G "MinGW Makefiles"

I am trying to run the Sensor Push example on a new B_L072Z_LRWAN1 board and it fails on the fs_init when it is trying to verify a magic number from eeprom.

The expected magic number is 0xc234, but I am reading 0x0.

Does that mean some eeprom initialization went wrong? Or does this code expect some previously prepared eeprom?

The same thing happens when running the gateway example. I am following instructions from the Getting Started Guide. However I am flashing the firmware using onboard stlink + openocd + gdb.

The generated platform_defs.h is as follows

//Warning: This file is automatically generated by CMake. Do NOT EDIT this file directly !!
#ifndef __PLATFORM_DEFS_H__
#define __PLATFORM_DEFS_H__
#define PLATFORM "B_L072Z_LRWAN1"
#define PLATFORM_CONSOLE_UART 1
#define PLATFORM_CONSOLE_LOCATION 0
#define PLATFORM_CONSOLE_BAUDRATE 115200
#define PLATFORM_MODEM_INTERFACE_UART 0
#define PLATFORM_MODEM_INTERFACE_BAUDRATE 115200
#define PLATFORM_NUM_LEDS 4
#define PLATFORM_NUM_BUTTONS 1
#define PLATFORM_NUM_DEBUGPINS 2
#define PLATFORM_SX127X_USE_RESET_PIN
#define PLATFORM_SX127X_USE_DIO3_PIN
#define PLATFORM_SX127X_USE_VCC_TXCO
#define PLATFORM_FS_SYSTEMFILES_IN_SEPARATE_LINKER_SECTION
#define USE_STM32L0XX
#define USE_STM32_COMMON
#define USE_SX127X
#define PLATFORM_B_L072Z_LRWAN1
#endif //__PLATFORM_DEFS_H__

The backtrace from gdb:

(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=file@entry=0x801583c "/dash7-ap-open-source-stack/stack/framework/components/fs/fs.c",
    line=line@entry=174, func=func@entry=0x8015714 <__func__.9436> "_fs_verify_magic",
    failedexpr=failedexpr@entry=0x80157f4 "memcmp(expected_magic_number, magic_number, FS_MAGIC_NUMBER_SIZE) == 0")
    at /dash7-ap-open-source-stack/stack/framework/hal/platforms/B_L072Z_LRWAN1/libc_overrides.c:72
72	    __BKPT (0); // break into debugger, when attached
(gdb) bt
#0  __assert_func (file=file@entry=0x801583c "/dash7-ap-open-source-stack/stack/framework/components/fs/fs.c",
    line=line@entry=174, func=func@entry=0x8015714 <__func__.9436> "_fs_verify_magic",
    failedexpr=failedexpr@entry=0x80157f4 "memcmp(expected_magic_number, magic_number, FS_MAGIC_NUMBER_SIZE) == 0")
    at /dash7-ap-open-source-stack/stack/framework/hal/platforms/B_L072Z_LRWAN1/libc_overrides.c:72
#1  0x0800bb18 in _fs_verify_magic (expected_magic_number=expected_magic_number@entry=0x2000048c <incomplete sequence \302>)
    at /dash7-ap-open-source-stack/stack/framework/components/fs/fs.c:174
#2  0x0800bb78 in _fs_init_permanent_systemfiles (permanent_systemfiles=permanent_systemfiles@entry=0x20000510 <d7ap_filesystem>)
    at /dash7-ap-open-source-stack/stack/framework/components/fs/fs.c:99
#3  0x0800bf3e in fs_init (provisioning=0x20000510 <d7ap_filesystem>)
    at /dash7-ap-open-source-stack/stack/framework/components/fs/fs.c:90
#4  0x08001d26 in d7ap_fs_init () at /dash7-ap-open-source-stack/stack/modules/d7ap/d7ap_fs.c:96
#5  0x080019aa in d7ap_init () at /dash7-ap-open-source-stack/stack/modules/d7ap/d7ap.c:46
#6  0x080001b4 in bootstrap () at /dash7-ap-open-source-stack/stack/apps/sensor_push/sensor_push.c:124
#7  0x0800c742 in scheduler_run () at /dash7-ap-open-source-stack/stack/framework/components/scheduler/scheduler.c:369
#8  0x080064e2 in main () at /dash7-ap-open-source-stack/stack/framework/hal/platforms/B_L072Z_LRWAN1/platf_main.c:117

The HTS221 temperature sensor code in the Sensor Push, Pull, and Action examples doesn't work: apart from the initial toggling of SCK, there is no activity on the I2C bus.

This is because the final thing i2c_init does is to disable the clock to the I2C controller:

  I2C_CLK_DISABLE((uint32_t)(i2c_ports[idx].i2c));

  return &handle[idx];
}

and there is nothing in the rest of the code to re-enable it.

A fix is to add i2c_acquire(hts221_handle) and i2c_release(hts221_handle) around anything which requires I2C.

Having done that, I do see activity on the bus, and get temperature readings.

Using SHA-1: 42d6bbf

Channel selection in EZR32 is wrong

Tested on f01a62d using default gateway and sensor_pull apps (and default AccessProfiles) .

The file em_msc.c is in the happy gecko library folder but not in CMakeLists.txt in stack\framework\hal\chips\efm32hg
By adding "emlib/src/em_msc.c" To the ADD_LIBRARY (${CHIP_LIBRARY_NAME} OBJECT I solved the issue. I don't know it is excluded for a reason? But em_msc.c is required for the implementation of flash EEPROM emulation.

This is an issue I ran into earlier but haven't reported yet I just continued in C.
When trying to build an application with the stack using C++ for the B-L072Z-LRWAN1 it crashes before calling the bootstrap function. I had to figure this out using a debugger. The debugger doesn't give much information about the crash. The code does compile it just crashes runtime. I've also added a picture of the callstack the debugger shows and the local variables of the __hardfault_handler function of stm32_common_system.c where the reason of the crash is "optimized out".

extern "C"
{
  #include "d7ap.h"
  #include "d7ap_fs.h"
  #include "log.h"

  void bootstrap()
  {
    d7ap_fs_init();
    d7ap_init();
    log_print_string("Test");
  }
}

stack in the __hardfault_handler function

Hello! Building of example in ubuntu 20.04 fails. I'm trying to run the make command but it gets stuck at approximately 88 or 90% and the error: "/usr/bin/objcopy: Unable to recognise the format of the input file `gateway.elf'
make[2]: * [apps/gateway/CMakeFiles/gateway.elf.dir/build.make:106: apps/gateway/gateway.elf] Error 1
make[2]: * Deleting file 'apps/gateway/gateway.elf'
make[1]: * [CMakeFiles/Makefile2:1634: apps/gateway/CMakeFiles/gateway.elf.dir/all] Error 2
make: * [Makefile:84: all] Error 2", is printed.

The metadata section occupies 3068 bytes, as seen below:

section                               size         addr
.d7ap_fs_metadata_section            0xbfc    0x8080000

This results from (dash7-ap-open-source-stack > stack > fs > d7ap_fs_data.c) :

__attribute__((used)) uint8_t d7ap_fs_metadata[4 + 4 + (255 * 12)] LINKER_SECTION_FS_METADATA = {...

Since the header type used is only 9 bytes (#define FS_FILE_HEADER_SIZE sizeof(fs_file_t)), I don't think it's necessary to claim 12 bytes per header in the metadata section:

typedef struct __attribute__((__packed__))
{
    uint8_t blockdevice_index; // the members of fs_blockdevice_types_t are required, but more blockdevices can be registered in the futute
    uint32_t length;
    uint32_t addr;
} fs_file_t;

I believe the size is confused with sizeof(d7ap_fs_file_header_t), which is equal to 12 and corresponds to the header size for the header defined in the ALP spec Table 5.1.6.1: File Header.

So we could limit the allocated bytes in the metadata by changing the line above in d7ap_fs_data.c to:

__attribute__((used)) uint8_t d7ap_fs_metadata[4 + 4 + (256 * 9)] LINKER_SECTION_FS_METADATA = {...

I also changed the 255 to 256, which probably was a mistake that went unnoticed due to the overhead introduced by the 12 bytes per header allocation.

Doing so frees 756 EEPROM bytes, which is likely a welcome change for a scarce resource.

All of the above can of course be ignored (except the 255 -> 256 change) if the 12 byte allocation per system file header is RFU.

What are your thoughts on this? Is this is a warranted change? If so, can I send in a pull request?

The EZR32LG timer has the LFXO hard-coded as the oscillator source for the RTC. I am bringing up a platform that does not have an external low-frequency crystal. The startLfxoForRtc() function in ezr32lg_timer.c should use the HW_USE_LFXO macro definition in platform.h to select the oscillator source for the timer. (This is not such a big deal, I have simply changed the function to use LFRCO).

Additionally, the HW_USE_HFXO macro is used in the __ezr32lg_mcu_init() function to select the oscillator source for the MCU. The file ezr32lg_mcu.c does not include platform.h (nor does any of its includes) and so never sees the HW_USE_HFXO definition, and always defaults to the HFRCO. Should the hal/chips/ezr32/CMakeLists.txt file include configuration parameters for oscillator selection?

There are some places in the code where an object is declared on the stack in a function, passed into some struct as some pointer and then the object goes out of scope. Isn't this rather dangerous since the object goes out of scope?

For example, in trans.c

static void nwl_rx_callback(nwl_rx_res_t* result)
{
...
    case D7AQP_COMMAND_TYPE_NA2P_REQUEST:
    {
        switch (query_result.d7aqp_command.command_code & 0x0F)
        {
            case D7AQP_OPCODE_ANNOUNCEMENT_FILE:
            {
                D7AQP_Single_File_Return_Template sfr_tmpl;
                sfr_tmpl.return_file_id = data->payload[pointer++];
                sfr_tmpl.file_offset = data->payload[pointer++];
                sfr_tmpl.isfb_total_length = data->payload[pointer++];
                sfr_tmpl.file_data = &data->payload[pointer];

                pointer += sfr_tmpl.isfb_total_length - sfr_tmpl.file_offset;

                query_result.d7aqp_command.command_data = &sfr_tmpl;
            }
        }
        break;
    }
...
    trans_rx_query_callback(&query_result);
...
}

So, in the above case, sfr_tmpl goes out of scope outside of the switch and then the callback is called. Am I making sense here? Or is there something I don't know about MSP430 programming?

In the example, I've observed that the requester receives a response from the responder but the response is empty (all 0's). I dug into it a little bit and noticed that trans_tx_query is not consuming the payload in the file template.

void trans_tx_query(D7AQP_Command* command, uint8_t subnet, uint8_t spectrum_id, int8_t tx_eirp)
{
...
    switch (command->command_code & 0x70)
    {
        // Response
        case D7AQP_COMMAND_TYPE_RESPONSE:
        {
            switch (command->command_code & 0x0F)
            {
                case D7AQP_OPCODE_ANNOUNCEMENT_FILE:
                {
                    break;
                }
            }
            break;
        }
...
}

The same behavior happens on the rx side as well. Or am I misunderstanding the code?

After a while UART sends rubish, this is more present on 10Mhz.

example:

00> [000] Sensor Action: Device booted
00> 
00> 
00> [001] tried to start an interface (231) that is not registered
00> 
00> [002] temp -6400 dC
00> 
00> [003] tried to start an interface (231) that is not registered
00> 
00> [004] temp -6400 dC
00> 

It really isn't that cold on my bench!

In execute_sensor_measurement:

  temperature = __builtin_bswap16(temperature); // need to store in big endian in fs
  d7ap_fs_write_file(SENSOR_FILE_ID, 0, (uint8_t*)&temperature, SENSOR_FILE_SIZE, ROOT_AUTH);

  log_print_string("temp %i dC", temperature);

The log_print_string needs to come before the __builtin_bswap16 - then we get a sensible value:

00> [000] Sensor Action: Device booted
00> 
00> 
00> [001] temp 230 dC
00> 
00> [002] tried to start an interface (230) that is not registered
00> 
00> [003] temp 230 dC
00> 
00> [004] tried to start an interface (230) that is not registered
00> 
00> [005] temp 231 dC
00> 
00> [006] tried to start an interface (231) that is not registered
00> 
00> [007] temp 230 dC

SHA-1: 42d6bbf

Hello,

I'm interested on DASH7, but it seems this repository is only about the End Device side, right ?

Is there any repository or ressource for the gateway hardware and software as well ? I know the WizziGate (https://wizzilab.com/wiki/#!wizzikit/../hardware/wizzigate_wrt.md) but I haven't found any other solution to build the gateway and server side...

I'm looking for something like LoRaWAN for example, on which there are several solutions to build a gateway and there are also several open-source or closed servers. In my opinion this highly participate to the adoption of the standard... To be more accurate I would like to add DASH7 gateway capability to an existing product. Best solution for me is mini-pcie cards and in any case I'm not interested by the WizziGate solution.

Thanks for any feedbacks!
Joel

Previously you could provide a callback to alp_init_args which was used for example in he gateway example to blink a LED. However this callback is not called anymore. But the gateway example still uses it.

https://github.com/MOSAIC-LoPoW/dash7-ap-open-source-stack/blob/12c5046aa1183e548e06db76b1911fd56538c641/stack/apps/gateway/app.c#L79

Was this removed on purpose? If so, Is there a new method to provide hooks to the framework to do anything on certain events?

Can somebody please give the sketch (image) of EZR-USB pinout, as pins are not marked on PCB?

I flashed the star endpoint and gateway sketches onto a pair of wizzimotes. Connected the gateway via ftdi and can see some information via PyLogger. When I try to get pylogger_rss working, I never get the sync code hence it stays in the while loop indefinitely.

Also, pylogger has some suspicious looking outputs so I suspect maybe something is going on with our USB setup? Relatively new to dash7 and so far have enjoyed your implementation.

10:55:00.163738 STRINGReceived Query from :46a420730023002;
10:55:00.167826 STRINGRSS: -24 dBm
10:55:00.169753 STRINGNetto Link: -34 dBm
10:55:00.171786 STRINGD7AQP File Announcement received
10:55:00.175732 STRING - file 0x0 starting from byte 0
10:55:00.178832 DATA 0047
10:55:00.179717 STK: DLLDLL restart channel scan series
10:55:00.182843 STK: DLLDLL Starting channel scan series
10:55:00.186732 STRINGphy_rx
10:55:00.194805 ERROR'utf8' codec can't decode byte 0xdd in position 19: invalid continuation byte

Commit 86f779e seems to introduce behaviour that interferes with "normal" output.

Up to commit c729596, output of sensor_push looks like:

[005] AC specifier=0 channel=0
[006] recv response @ 98 dB link budget from:
[007] 00 0B 57 00 00 09 12 83
[008] Command completed successfully

After commit 86f779e, the output is partly mangled:

[001] AC specifier=0 channel=0
[003] 00 0B 57 00 00 09 12 83␀␀k bu(␡␀ 0␡␀ ��␀
[004] Command completed successfully

Hello,
can somebody please provide a compliation instructions. I have tried to compile the project:

drasko@Lenin:~/dash7/dash7-ap-open-source-stack/stack/build$ cmake ..
-- The C compiler identification is GNU 5.2.1
-- The CXX compiler identification is GNU 5.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error at framework/hal/platforms/CMakeLists.txt:39 (MESSAGE):
  There are no supported platforms for the selected toolchain


-- selected platform: 
CMake Error at framework/hal/platforms/CMakeLists.txt:62 (STRING):
  string no output variable specified


CMake Error at framework/hal/platforms/CMakeLists.txt:65 (ADD_SUBDIRECTORY):
  add_subdirectory given source
  "/home/drasko/dash7/dash7-ap-open-source-stack/stack/build/framework/hal/platforms/platform"
  which is not an existing directory.


CMake Error at framework/CMakeLists.txt:120 (TARGET_INCLUDE_DIRECTORIES):
  Cannot specify include directories for target "PLATFORM" which is not built
  by this project.


CMake Error at framework/CMakeLists.txt:130 (TARGET_COMPILE_DEFINITIONS):
  Cannot specify compile definitions for target "PLATFORM" which is not built
  by this project.


-- Configuring incomplete, errors occurred!
See also "/home/drasko/dash7/dash7-ap-open-source-stack/stack/build/CMakeFiles/CMakeOutput.log".
drasko@Lenin:~/dash7/dash7-ap-open-source-stack/stack/build$ 

Obviusly, some PLATFORM should be defined somewhere... What are the options that should be provided to cmake?

Instructions found here: http://mosaic-lopow.github.io/dash7-ap-open-source-stack/doxygen/md_gettingstarted.html are confusing as they are using GUI. Can somebody please provice command line options.

Hello folks,

I have a custom board that uses the Dash 7 stack on the master branch. The board works most of the time and TX/RX is fine. However, there are occasions where the TX frequency is ~435 MHz instead of 433 MHz and hence my receiver is unable to pick up the transmission. I was thinking that it was a hardware issue but I don't hit this problem with the sample 433 MHz configuration in the Smart RF studio. I tried replicating some of the registers (replicating the full set caused a hang somehow... my guess is because of the rising/falling edges in the interrupt handler) from the Smart RF studio but the transmitted frequency was still 435 MHz (http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/228/7888.no_5F00_rx.png).

Has anyone else hit this issue? I really hope that I won't have to switch to Simpliciti :(

Firstly the whole codebase needs reformatting to be consistent
Next workflow should be added which enforces formatting

Hi,

I'm trying to compile d7ap_test in Simplicity Studio and getting errors relating to missing file framework_defs.h included form debug.h. I couldn't fine that file anywhere in your repo. Am I missing something?

Thanks.

I just updated a project to the latest version of the stack (commit dc6307c) and now I keep hitting assertion fails in timer_fired() at line 405

assert(NG(timers)[NG(next_event)].f != 0x0);

Before it crashes it seems to hang (the code seems to loop here) for quite a long time in void HAL_PWR_EnterSTOPMode(uint32_t Regulator, uint8_t STOPEntry) , specifically on the last line:

  CLEAR_BIT(SCB->SCR, SCB_SCR_SLEEPDEEP_Msk);

Some debug output before it crashes:

Program: start
measurement took 287 ms
[001] sleep (mode 1) @ 2129
[002] EXTI->PR 0
[003] wake up @ 2319
measurement took 288 ms
[004] sleep (mode 1) @ 2623
[005] EXTI->PR 0
[006] wake up @ 6960
[007] sleep (mode 1) @ 10352
[008] EXTI->PR 0
[009] wake up @ 41134
[010] sleep (mode 1) @ 41141
[011] EXTI->PR 0

Some notes:

• This is a project with a relatively fast repeating measurement task @ 2Hz. Which is much faster than once per hour we did in another project. Not sure if that could be a trigger for this timer assertion.
• If I do not disable the Watchdog, it keeps working for much longer (a few minutes), however in the end it still crashes at the same place

I am not really sure yet how to debug this further, any suggestions on what steps to take, or what debug output could be useful?

I am trying to compile the project, but I am hitting the linking error:

drasko@Mali:~/dash7-ap-open-source-stack/build$ cmake ../stack/         -DTOOLCHAIN_DIR=../gcc-arm-none-eabi-4_9-2015q3/         -DCMAKE_TOOLCHAIN_FILE=../stack/cmake/toolchains/gcc-arm-embedded.cmake         -DPLATFORM=EFM32GG_STK3700         -DPLATFORM_EFM32GG_STK3700_RADIO=cc1101         -DAPP_D7AP_TEST=on
-- Cross-compiling using gcc-arm-embedded toolchain
-- Cross-compiling using gcc-arm-embedded toolchain
-- detected supported platforms: EFM32HG_STK3400EFM32GG_STK3700matrix_tp1089ifest
-- selected platform: EFM32GG_STK3700
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/arm-none-eabi-gcc
-- Configuring done
-- Generating done
-- Build files have been written to: /home/drasko/dash7-ap-open-source-stack/build
drasko@Mali:~/dash7-ap-open-source-stack/build$ make
Scanning dependencies of target CHIP_CC1101
[  1%] Building C object framework/hal/platforms/platform/chips/cc1101/CMakeFiles/CHIP_CC1101.dir/cc1101.c.obj
[  2%] Building C object framework/hal/platforms/platform/chips/cc1101/CMakeFiles/CHIP_CC1101.dir/cc1101_interface.c.obj
[  4%] Building C object framework/hal/platforms/platform/chips/cc1101/CMakeFiles/CHIP_CC1101.dir/cc1101_interface_spi.c.obj
[  4%] Built target CHIP_CC1101
Scanning dependencies of target CHIP_EFM32GG
[  5%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/CMSIS/device/src/system_efm32gg.c.obj
[  6%] Building ASM object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/CMSIS/device/src/startup_gcc_efm32gg.s.obj
[  8%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_assert.c.obj
[  9%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_adc.c.obj
[ 10%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_system.c.obj
[ 12%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_cmu.c.obj
[ 13%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_emu.c.obj
[ 14%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_gpio.c.obj
[ 16%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_usart.c.obj
[ 17%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_rtc.c.obj
[ 18%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_dma.c.obj
[ 20%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_int.c.obj
[ 21%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_lcd.c.obj
[ 22%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_timer.c.obj
[ 24%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_i2c.c.obj
[ 25%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/emlib/src/em_wdog.c.obj
[ 27%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/kits/common/drivers/dmactrl.c.obj
[ 28%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/kits/common/drivers/gpiointerrupt.c.obj
[ 29%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/kits/common/drivers/segmentlcd.c.obj
[ 31%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/kits/common/drivers/cdc.c.obj
[ 32%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/kits/common/bsp/bsp_bcc.c.obj
[ 33%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/kits/common/bsp/bsp_stk.c.obj
[ 35%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/efm32gg_adc.c.obj
[ 36%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/efm32gg_mcu.c.obj
[ 37%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/efm32gg_uart.c.obj
[ 39%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/efm32gg_spi.c.obj
[ 40%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/efm32gg_atomic.c.obj
[ 41%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/efm32gg_timer.c.obj
[ 43%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/efm32gg_system.c.obj
[ 44%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/efm32gg_gpio.c.obj
[ 45%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/efm32gg_pins.c.obj
[ 47%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/efm32gg_i2c.c.obj
[ 48%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/efm32gg_watchdog.c.obj
[ 50%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/usb/src/em_usbd.c.obj
[ 51%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/usb/src/em_usbdch9.c.obj
[ 52%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/usb/src/em_usbdep.c.obj
[ 54%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/usb/src/em_usbdint.c.obj
[ 55%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/usb/src/em_usbh.c.obj
[ 56%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/usb/src/em_usbhal.c.obj
[ 58%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/usb/src/em_usbhep.c.obj
[ 59%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/usb/src/em_usbhint.c.obj
[ 60%] Building C object framework/hal/platforms/platform/chips/efm32gg/CMakeFiles/CHIP_EFM32GG.dir/usb/src/em_usbtimer.c.obj
[ 60%] Built target CHIP_EFM32GG
Scanning dependencies of target PLATFORM
[ 62%] Building C object framework/hal/platforms/platform/CMakeFiles/PLATFORM.dir/stk3700_main.c.obj
[ 63%] Building C object framework/hal/platforms/platform/CMakeFiles/PLATFORM.dir/stk3700_leds.c.obj
[ 64%] Building C object framework/hal/platforms/platform/CMakeFiles/PLATFORM.dir/stk3700_userbutton.c.obj
[ 66%] Building C object framework/hal/platforms/platform/CMakeFiles/PLATFORM.dir/stk3700_sensors.c.obj
[ 67%] Building C object framework/hal/platforms/platform/CMakeFiles/PLATFORM.dir/stk3700_debug.c.obj
[ 68%] Building C object framework/hal/platforms/platform/CMakeFiles/PLATFORM.dir/stk3700_lcd.c.obj
[ 70%] Building C object framework/hal/platforms/platform/CMakeFiles/PLATFORM.dir/stk3700_usb_descriptors.c.obj
[ 71%] Building C object framework/hal/platforms/platform/CMakeFiles/PLATFORM.dir/stk3700_usb.c.obj
[ 72%] Building C object framework/hal/platforms/platform/CMakeFiles/PLATFORM.dir/libc_overrides.c.obj
[ 72%] Built target PLATFORM
Scanning dependencies of target FRAMEWORK_COMPONENT_scheduler
[ 74%] Building C object framework/components/scheduler/CMakeFiles/FRAMEWORK_COMPONENT_scheduler.dir/scheduler.c.obj
[ 74%] Built target FRAMEWORK_COMPONENT_scheduler
Scanning dependencies of target FRAMEWORK_COMPONENT_shell
[ 75%] Building C object framework/components/shell/CMakeFiles/FRAMEWORK_COMPONENT_shell.dir/shell.c.obj
[ 75%] Built target FRAMEWORK_COMPONENT_shell
Scanning dependencies of target FRAMEWORK_COMPONENT_node_globals
[ 77%] Building C object framework/components/node_globals/CMakeFiles/FRAMEWORK_COMPONENT_node_globals.dir/ng.c.obj
[ 77%] Built target FRAMEWORK_COMPONENT_node_globals
Scanning dependencies of target FRAMEWORK_COMPONENT_random
[ 78%] Building C object framework/components/random/CMakeFiles/FRAMEWORK_COMPONENT_random.dir/random.c.obj
[ 78%] Built target FRAMEWORK_COMPONENT_random
Scanning dependencies of target FRAMEWORK_COMPONENT_fifo
[ 79%] Building C object framework/components/fifo/CMakeFiles/FRAMEWORK_COMPONENT_fifo.dir/fifo.c.obj
[ 79%] Built target FRAMEWORK_COMPONENT_fifo
Scanning dependencies of target FRAMEWORK_COMPONENT_log
[ 81%] Building C object framework/components/log/CMakeFiles/FRAMEWORK_COMPONENT_log.dir/log.c.obj
[ 81%] Built target FRAMEWORK_COMPONENT_log
Scanning dependencies of target FRAMEWORK_COMPONENT_timer
[ 82%] Building C object framework/components/timer/CMakeFiles/FRAMEWORK_COMPONENT_timer.dir/timer.c.obj
[ 82%] Built target FRAMEWORK_COMPONENT_timer
Scanning dependencies of target FRAMEWORK_COMPONENT_crc
[ 83%] Building C object framework/components/crc/CMakeFiles/FRAMEWORK_COMPONENT_crc.dir/crc.c.obj
[ 83%] Built target FRAMEWORK_COMPONENT_crc
Scanning dependencies of target framework
[ 85%] Building C object framework/CMakeFiles/framework.dir/framework_bootstrap.c.obj
Linking C static library libframework.a
Error running link command: No such file or directory
framework/CMakeFiles/framework.dir/build.make:209: recipe for target 'framework/libframework.a' failed
make[2]: *** [framework/libframework.a] Error 2
CMakeFiles/Makefile2:90: recipe for target 'framework/CMakeFiles/framework.dir/all' failed
make[1]: *** [framework/CMakeFiles/framework.dir/all] Error 2
Makefile:72: recipe for target 'all' failed
make: *** [all] Error 2
drasko@Mali:~/dash7-ap-open-source-stack/build$ 

Is OSS7 stack based on Dash7 Mode 2 specification as described here: http://www.indigresso.com/wiki/doku.php?id=dash7_mode_2:main, http://www.slideshare.net/peburns/dash7-mode-2-summary, and if not what is the difference? Is this MOde 2 now official spec?

The HAL-ed microcontroller's GPIO-modules should provide an interface for enabling and disabling the GPIO (clock) functionality: e.g. hw_gpio_enable and hw_gpio_disable. These should apply reference counting to track the modules that actively use the GPIO functionality, and if possible automagically actually disable e.g. the clock when no GPIO activity is required.

Hi,

i encounter assertion fail in timer_fired(). After a lot test, there are two case:

case 1:

[68495] [PHY] READ FIFO 59
[68496] 1E 11 AE 46 32 30 39 00 2C 00 30 20 01 42 37 34 34 00 3B 00 44 88 AC 00 5D 01 40 00 02 FA 24
[68497] [PHY] RX done (0 dBm)
[68498] [DLL] guard channel
[68499] [DLL] packet received @ 2354664 , RSSI = 0
[68500] [NONE] Packet queue mark received 0x20001688, slot 0assertion "NG(timers)[NG(next_event)].f != 0x0" failed: file "/Users/sam/dash7-ap-open-source-stack/stack/framework/components/timer/timer.c", line 342, function: timer_fired

case 2:

[381941] [NONE] packet len 15
[381942] 0F 01 6E 90 28 04 00 32 20 40 00 02 00 00 37
[381943] [DLL] Packet LENGTH 15, TX DURATION 43
[381944] [DLL] Switched to DLL_STATE_CSMA_CA_STARTED
[381945] [DLL] Tca= 415 with Tc 464 and Ttx 43
[381946] [DLL] Adjusted Tca= 394 = 8747425 - 8747404
[381947] [DLL] slot duration: 43 t_offset: 0 csma ca mode: 1
[381948] [DLL] Switched to DLL_STATE_CCA1assertion "NG(next_event) != NO_EVENT" failed: file "/Users/sam/dash7-ap-open-source-stack/stack/framework/components/timer/timer.c", line 348, function: timer_fired

There is only one place to change the NG(next_event) and it is in configure_next_event(). But configure_next_event() is only called in an atomic context.

So i doubt that sometimes configure_next_event() was called in a non-atomic context. The only possibility is that atomic context has been disabled in some cases caused by atomic nested.

I made a pull request deal with irq nest counter for stm32 platform.

i will do some more test on it.

The issue: Task scheduling is not thread safe when attempting to schedule them from the interrupt service routine (ISR). If the ISR tries to schedule a task, the device gets stuck in an infinite loop.

The image below shows where it gets stuck:

Hardware used: B-L072Z-LRWAN1. Connect PA0 and PA8 pins together.

Code to reproduce:
The code below should alternate the output of PA8 every half a second. When the pin goes high, ISR is triggered on the rising edge and drive_output_low_task() should be scheduled. However, the MCU gets stuck in an infinite loop when attempting to schedule the task from ISR.

#include "hwgpio.h"
#include "stm32_common_gpio.h"
#include "scheduler.h"
#include "timer.h"
#include "log.h"
#include "debug.h"
#include "framework_defs.h"
#include "platform.h"

#ifdef FRAMEWORK_USE_POWER_PROFILE
	#error "This example can't be used in combination with use_power_profile as the filesystem is not initialized here"
#endif

#define TASK_DELAY ((timer_tick_t)(0.5 * TIMER_TICKS_PER_SEC))

const pin_id_t PIN_INT = PIN(GPIO_PORTA, 0);
const pin_id_t PIN_OUT = PIN(GPIO_PORTA, 8);

// function prototypes
static void drive_output_high_task ();
static void drive_output_low_task ();

static inline void drive_output_high () {hw_gpio_set(PIN_OUT);}
static inline void drive_output_low ()	{hw_gpio_clr(PIN_OUT);}

static void drive_output_high_task ()
{
	drive_output_high();
	log_print_string("Output HIGH");
}

static void drive_output_low_task ()
{
	drive_output_low();
	log_print_string("Output LOW");
	timer_post_task_delay(&drive_output_high_task, TASK_DELAY);
}

static void drive_output_low_ISR (void *arg)
{
	timer_post_task_delay(&drive_output_low_task, TASK_DELAY);
}

static void init_pins ()
{ 
	// setup output pin to simulate external interrupt source
	hw_gpio_configure_pin(PIN_OUT, true, GPIO_MODE_OUTPUT_PP, true);
	hw_gpio_clr(PIN_OUT);

	// configure interrupt pin
	hw_gpio_configure_pin(PIN_INT, true, GPIO_MODE_IT_RISING, false);
	hw_gpio_configure_interrupt(PIN_INT, GPIO_RISING_EDGE, &drive_output_low_ISR, NULL);
	hw_gpio_enable_interrupt(PIN_INT);
}

// ----------------------------------------------------------------------------
// MAIN
// ----------------------------------------------------------------------------

void bootstrap()
{
	log_print_string("Device booted at time: %d\n", timer_get_counter_value());

	init_pins();

	sched_register_task(&drive_output_high_task);
	sched_register_task(&drive_output_low_task);

	timer_post_task_delay(&drive_output_high_task, TASK_DELAY);
}

Hi,

I am looking forward to experiment with DASH7 for an industrial use case, however in the README it states the following:

"This implementation focuses on completeness, correctness, ease of use and understanding. Performance and code size are less important aspects."

What is the performance that we should be expecting (in terms of bps/delay of nodes/gateways or even number of supported devices)? Are there any publicly available results?

Best regards,

I am trying to understand how DASH7 over LoRa is supposed to work with this stack.

From this discussion, It looks like I would need to configure a Channel Profile with Channel Header with the PHY_CLASS_LORA Channel Class (=0x01)

lora_channel_header = ChannelHeader(
  channel_class=ChannelClass.LORA,
  channel_coding=ChannelCoding.FEC_PN9,
  channel_band=ChannelBand.BAND_868
)

So I can run this through the python tools, place it in eeprom and then make sure my application will use the correct access profile through d7ap_fs_write_dll_conf_active_access_class();

So far so good I think.

However, when I search the code base for PHY_CLASS_LORA. I only find one place where it is used: phy_calculate_tx_duration in phy.c. And I am not sure how that would result in LoRa modulation being applied by the SX1276.

From the SX1276 datasheet it looks like you need to put it into LoRa mode by setting the LongRangeMode bit to 1, i.e. writing 0x80 to the RegOpMode register. Which I also cannot find in the code (sx127x.c).

So I am probably missing something as to how this would work. Should I somehow use the lorawan module or the netdev driver?

I ran into a bug where the B-L072Z-LRWAN1 board would reset when sending a message using access class 1 to normal rate. the code below would cause the board to reset using access class 0x11 in the session config.

dae_access_profile_t profile;
d7ap_fs_read_access_class(1, &profile);
profile.channel_header = (channel_header_t)
{
  .ch_class = PHY_CLASS_NORMAL_RATE,
  .ch_coding = PHY_CODING_FEC_PN9,
  .ch_freq_band = PHY_BAND_868
};
d7ap_fs_write_access_class(1, &profile);

d7ap_send(args); 

Since 7bcf4a7,
I cannot receive frames sent by sensor_push anymore.
Reverting just that commit, fixes the issue for me.
I am using two B-L072Z-LRWAN1 boards with Murata sx1276 radios.

[ 98%] Building C object apps/sniffer/CMakeFiles/sniffer.elf.dir/sniffer.c.obj
...stack\apps\sniffer\sniffer.c:45:10: fatal error: alp_cmd_handler.h: No such file or directory
 #include "alp_cmd_handler.h"
          ^~~~~~~~~~~~~~~~~~~
compilation terminated.

I guess this is another "no longer used" example?

Or is there a plan?

platf.main.c has a reference to d7ap_volatile_files_data

However since this example only does LEDs, d7ap module does not get linked. Creating this mismatch which fails at the linker stage.

Workaround:

Adding

// The userfiles are only stored in RAM for now
uint8_t d7ap_volatile_files_data[FRAMEWORK_FS_VOLATILE_STORAGE_SIZE];

to simple_leds/app.c makes it compile and link again. But I am too new to this code base to know the best solution, maybe some preprocessor magic in platf_main.c?

Hi,

I encounter a asser fail while doing some test, sensor_pull on B-L072Z-LRWAN1 platform.

Below is the last lines log:

[3866] [PHY] READ FIFO 59
[3867] 1E 11 AE 46 32 30 39 00 2C 00 30 20 01 42 37 34 34 00 3B 00 44 88 C2 00 5D 01 40 00 02 7B B6
[3868] [PHY] RX done (0 dBm)
[3869] [DLL] guard channel
[3870] [DLL] packet received @ 147557 , RSSI = 0
[3871] [NONE] Packet queue mark received 0x20001688, slot 0assertion "((int32_t)fire_delay) > 0" failed: file "/Users/sam/dash7-ap-open-source-stack/stack/framework/components/timer/timer.c", line 301, function: configure_next_event

Then i check the source, it is in file timer.c function configure_next_event():

#ifndef NDEBUG	    
			//check that we didn't try to schedule a timer in the past
			//normally this shouldn't happen but it IS theoretically possible...
      fire_delay = (next_fire_time - timer_get_counter_value() - timer_info->min_delay_ticks);
			//fire_delay should be in [0,COUNTER_OVERFLOW_INCREASE]. if this is not the case, it is because timer_get_counter() is
			//now larger than next_fire_event, which means we 'missed' the event
			assert(((int32_t)fire_delay) > 0);
#endif 

If the LPTIM counter increase 1 between two pieces of code framed by red line in the picture, the assert will failed. right?

I change the code below and test it no assert failed here again.

#ifndef NDEBUG	    
			//check that we didn't try to schedule a timer in the past
			//normally this shouldn't happen but it IS theoretically possible...
      fire_delay = (next_fire_time - timer_get_counter_value() - timer_info->min_delay_ticks) + 1;
			//fire_delay should be in [0,COUNTER_OVERFLOW_INCREASE]. if this is not the case, it is because timer_get_counter() is
			//now larger than next_fire_event, which means we 'missed' the event
			assert(((int32_t)fire_delay) > 0);
#endif

I don't know if this modification is correct, I hope I can discuss it with you.

The SI4460 code assumes the hw_radio_packet_t struct is packed, but the packed attribute was removed in commit 761cf7c in September 2015. As a result, three padding bytes are added to the end of the struct, and members of an enclosing struct (e.g. packet_struct_t in the radio_ping app) begin on a word boundary.

The SI4460 calculates the length of data to transmit correctly, but assumes that hw_radio_packet_t is packed and loads the Tx FIFO with the contents of the data flexible array member, which points to the length byte, the three padding bytes, then the remainder of the enclosing struct. The last three bytes of data are not transmitted.

When the packed attribute was removed, it was replaced with a comment regarding alignment on Cortex-M0, so this might be a tricky one to fix. It should also be noted that the requirement for hw_radio_packet_t to be packed also requires all enclosing structs to be packed, which includes structs defined at the app layer. As the requirement for packing is implicit, this may be a source of bugs for the unaware.

I ran into a bug where it's not possible to schedule a message from the unscollicited response callback. The message was sent in a function that was scheduled in the unsollicited response callback. In the scheduled function the d7ap_send function was called and returned code 0 (SUCCESS) the message would be scheduled but never send. When scheduling the function with the timer_post_task_delay function the message would be sent.

Hi,

When compiling lorawan_node app (--DLORAWAN_NODE=y), I get :

Scanning dependencies of target lorawan_node.elf
[ 93%] Building C object apps/lorawan_node/CMakeFiles/lorawan_node.elf.dir/lorawan_node.c.obj
/home/riad/dash7-ap-open-source-stack/stack/apps/lorawan_node/lorawan_node.c:23:24: fatal error: timeServer.h: No such file or directory
 #include "timeServer.h"
                        ^
compilation terminated.
make[2]: *** [apps/lorawan_node/CMakeFiles/lorawan_node.elf.dir/build.make:63: apps/lorawan_node/CMakeFiles/lorawan_node.elf.dir/lorawan_node.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1797: apps/lorawan_node/CMakeFiles/lorawan_node.elf.dir/all] Error 2