Query related to MDEK1001 given on-board-package examples


I am trying to dig into MDEK1001 given on-board-package examples.
In examples like dwm-simple.c the code structure is different, for example, it does not have main() function but it has app-entry function and similarly there are many things which I am unable to understand.
Also, the code section that I have sent below in dwm_user_start function, I am unable to find the definition of functions like : dwm_shell_compile(), dwm_le_compile(), dwm_serial_spi_compile(), dwm_thread_create(). I can see there declaration in dwm.h but cannot find its definition anywhere.

void dwm_user_start(void)
uint8_t hndl;
int rv;

//Disabling ble by default as softdevice prevents debugging with breakpoints (due to priority)

/* Create thread */
rv = dwm_thread_create(THREAD_APP_PRIO, app_thread_entry, (void*)NULL,
		"app", THREAD_APP_STACK_SIZE, &hndl);

/* Start the thread */


It would be of great help if someone could explain it.

Thanks & Regards

1 Like

I am really lost how to use these on-board-package examples. I am able to flash the dwm-simple.c but the output gets stuck
in while(1) at dwm_evt_wait(&evt);
I am unable to understand how to configure my boards and how many number of dwm1001-dev modules are required here, I am really lost how to test these given on-board examples.
Please someone help.

Thanks & regards

Hi @Asmita

First I’ll talk about your second post

On document Gateway Quick Development Guide you have all instructions to setup a DRTLS systems. You need at least 6 boards DWM1001-DEV:

  • 1 Initiator
  • 3 Anchors
  • 1 Tag
  • 1 Gateway

To setup the Gateway you’ll need a Raspberry Pi 3 Model B.

Following the instructions, at end you will see your tag and anchors on your screen.

Now, that you are with your DRTLS working fine, let’s move to your first post.

Please, see my question about this here [1]. I want to connect others sensors and one button on the board and change messages with gateway through MQTT server. To do this you have a “space” on the flash memory for a user program. To do this see examples below DWM1001\Source_Code\DWM1001_on_board_package directory. In my post [1], @Weibo_Pan give a very detailed explanation.

To do everything working together in your board, please see document DWM1001 Firmware
User Guide.

Finally about functions dwm_shell_compile(), dwm_le_compile(), dwm_serial_spi_compile(), I also don’t know (yet) why they are there and what exactly they do. For now, I’m just using it as a “dogma” :slight_smile: It will be great if anyone can explain it to us.

All the best

[1] Sending Accelerometer data, and data from other sensors through MQTT - #2 by Weibo_Pan

Hi guys,

@programonauta Thank you for sharing your experience. Very glad that the info helps :slight_smile:

For the functions ending with _compile(), they are options of the components being used by the PANS library. For example,

  • If you do dwm_shell_compile(), then UART shell function will be included in your build. Otherwise the shell function won’t be there and the occupied flash will be released.

  • If you do dwm_serial_spi_compile(), then serial and SPI functions will be included in your build. Otherwise the serial and SPI functions won’t be included, the occupied flash will be released and the occupoied peripheral external ports will be released. If you check Table 2 on Page 30 of DWM1001-API-Guide.pdf (included in folder DWM1001_DWM1001-DEV_MDEK1001_Sources_and_Docs_v9\DWM1001\Product_and_Design_Documents), you can see from row 35 that UART0 and SPI2 will be released.

  • Similarly, dwm_ble_compile, dwm_le_compile and dwm_serial_uart_compile do the same things.
    We’ll add the info of the usage of these functions in the next release of documents (or maybe just add comments in the code).

For the dwm_thread_create(), this is a thread operation based OS. If you go to line 1049 of file dwm.h in folder dwm\include, you can see many other thread operations and their brief introduction. The PANS system is based on eCOS. It is similar to many other OS such as FreeRTOS. For a simple usage, you can treat app_thread_entry() as your main(), and use dwm_user_start() as your pre-configuration step. If you don’t need to change the configurations, you can leave dwm_user_start() untouched.

Best regards,

1 Like


Thanks @Weibo_Pan and @programonauta for deatailed explaination. I am now able to somewhat figure out what’s going in the background. I am successfully able to setup and get appropriate output as per quick start development guide using anchor, tag, gateway setup.
I am also successfully able to test the APIs as given in DWM1001 API Guide.
I am now going through the document

I want to expand my system in hospitals. Now, I am trying to understand DWM1001_System_Overview.pdf for scalability feature. It says maximum number of anchors at a time can be 30 but if 31st anchors try to join , it can only join if any slot is available

I am trying to understand the document “DWM1001_System_Overview” as on


I am struggling to understand its few concepts.

  1. As given on page18 of document " The Beacons are sent every superframe and Almanacs every 120th superframe. " why is it so that the Beacons are sent every superframe and Almanacs every 120th superframe?

  2. In section 5 of this document, in scalability section in Figure 10, we see that superframe data seen by anchor N, sees Q at seat number 0, I am confused that whether Q is now acting as an initiator for anchor N?

kindly put forward your views.

Thanks & regards

1 Like

Hi Asmita,

To answer your questions:

  1. In the superframe (as introduced in Section 4.1), there are 30 slots for the beacons, but only 2 service slots. i.e. every Anchor would have a chance to use its beacon slot in EVERY superframe. However, they have to queue for the turn of using the service slots. While in the mean time, the IOT uplink, IOT downlink and join requests all share the same 2 service slots. That makes the queue quite long. So every Anchor has to wait 120 superframes to its own turn of using the service slots for sending Almanac.
  2. There is only one initiator in this figure, i.e. Anchor A. Anchor Q is also using seat 0 for its beacon, but its time is based on other anchors, e.g. N or M.
    clock_level is used to identify how far away the Anchor is from the Initiator. The Initiator always has clock_level = 0. The following level of Anchors based on it will have clock_level=1, 2, 3 and so on. The Anchor with a higher clock_level will adjust it’s time according to the timestamps from the anchors with a lower clock_level. In the case shown in Figure 10, Anchor N will see Q with a clock_level = 4, and in the meantime, the flag_initiator=0. Thus, N will know who Q is and will not take it as the initiator.

Best regards,

1 Like

Hi @Weibo_Pan

I have a question here, in the document Gateway Quick Deployment Guide, Chapter 2 the instruction is flash the board with PANS software. I did this and configure all stuffs through serial interface using TeraTerm.

In the document DWM1001 Firmware User Guide, section 4.2 there is a detailed instruction how to combine the user application with PANS software and flash to board.

I unboxed a board and just build and run a program, based on examples provided (a simple program that turn on leds on board). I didn’t flash PANS software as described on Gateway document, and after test my user application I didn’t followed instructions on section, i.e., edit genearte_example_hex.bat, to combine softdevice, bootloader, FW1 and customized FW2 and flash it to board using J-Lite.

But, it looks like the PANS is working as well: I get configure it through TeraTerm, configure the board as anchor, tag, gateway or initiator. I didn’t test this board in the DRTLS that I set up, but I imagine everything is working. So my question is: to use this board in the DRTLS system I still need to combine everything and flash it, following the instructions on section 4.2 of Firmware User Guide?


Ricardo Brandão

Hi Ricardo,

The firmware image is already in the chip. As was introduced in section 4.2.1, it consists of 5 parts: softdevice, bootloader, environment, FW1 and FW2.

By doing a “full reflash”, the environment part gets cleared, and the other 4 parts get updated. By following section of DWM1001 Firmware User Guide, or following Chapter 2 of Gateway Quick Deployment Guide, you actually do this “full reflash”.

By debugging-running the simple example with the provided SES project, part FW2 gets reflashed, while in the same time, the other parts are not changed. If you open your SES project and go to Project - Option - Debug - Loader, you’ll find the Flash addresses defined. You can take this as a partial reflash. Thus your node still works.

Best regards,

1 Like

Hi @Weibo_Pan

Some questions, just for clarification,

1 - AFAIU, I can use the environment part to store some custom data, like parameters, configurations, and so on, correct? If yes, what functions do I use to read and store data in the environment part?

2 - The environment part is cleared because there is no mention to 0x20000 in the Project - Options - Debug - Loader, nor in the generate_example_hex.bat. So, I supposed the “Build and Debug” / “Build and Run” commands on SES or Flash the result file of generate_example_hex.bat using J-Lite will erase all flash before flash the addresses provided. Correct?

3 - Is there anyway to preserve some data already stored in the environment? Like read it to a binary file before a full reflash and return it to the board setting the pair “file/address” in the Loader or generate hex script?

4 - Imagine I bought the board, unbox and just connect it through Serial Terminal, hit Enter twice and make all configuration using console commands. In which part the software that do all this job is located? I imagine it is located in FW2, correct?

5 - If yes, and if the program that I created in SES is flashed in FW2, I suppose the console, and all DRTLS functions is embedded in Decawave functions we must call in the dwv_user_start function (dwv_shell_compile, dwm_le_compile, and dwm_serial_spi_compile) correct?


Ricardo Brandão

Hi Ricardo,

  1. Correct. dwm_nvm_usr_data_set and dwm_nvm_usr_data_get
  2. and
  3. there is a ‘erase’ command in J-Link tools. Upon called, the whole flash will be erased. If not, the content in the environment will remain until overwritten by other command. generate_example_hex.bat will generate the image with environment untouched. Writing an image generated by this script will not overwrite the environment. And thus, the environment data will be preserved.
    I’m actually not so sure whether “Build and Debug” / “Build and Run” in the SES tool will erase the environment part.
  4. Yes, PANS is basically running on FW2.
  5. I’m not sure if I understand you correctly. If you would like to use the functions shell, le and spi, then the functions ( dwv_shell_compile , dwm_le_compile , and dwm_serial_spi_compile ) must be called in dwm_user_start.

Best regards,

Hi @Weibo_Pan

When I talk “all DRTLS functions” I mean the UWB functions, calculate position, send and receive data, and so on, i.e. which of these functions ( dwv_shell_compile , dwm_le_compile , and dwm_serial_spi_compile ) I must use to make the board works as a tag, anchor, initiator or gateway? Or which of these functions I can omit and the board continue works as a tag, anchor, initiator, or gateway?

And if I omit dwv_shell_compile, for instance, I will lost the possibility to configure the board through serial terminal, correct? In this case I must configure through C functions?



Hi Ricardo

To make the DRTLS work, you only need dwm_le_compile. The others are optional.

The shell is the terminal like console that provides convenience of configuration. The serial SPI is used for API purpose.

Correct. And then you need to use other enabled methods, i.e. except the C functions, you may use BLE or SPI APIs, if they are enabled.

Best regards,

1 Like