Problem executing simple program on Thingy91

[AdBee]

Hello,

I recently acquired a Thingy91 board in order to make a hardware prototype. I already have experience developing with the nRF52840 so I took inspiration from my working project.

First I flashed the straight out "Hello World" sample from the v2.9.0 SDK to the nRF9160 using a J-Link external probe and the "west flash" command with success. I could launch the program and read "Hello World" from a serial terminal.

Then I tried to create a basic setup project by copying what worked on my nRF52840 project. These basic functionalities includes:

_ Versionning

_ Using sysbuild with MCUBOOT

_ Signing firmware with an ECDSA 256 key.

The project successfully built and flashed, but unfortunately, didn't execute. No output can be read from the serial terminal anymore, not even the early logs from the bootloader.

What's a bit worrisome is that I can't manage to get back to a state where things worked. When I try to flash the basic "Hello World" sample again, the program doesn't launch anymore (no output on the serial terminal).

Any idea what could be going on and how to fix this ? I tried switching to the most recent v3.0.1 SDK but with no success.

I'm adding the .tar.gz of the project.

thingy_minimal.tar.gz

Here is my build configuration:

And the output when I flash:

Flashing build_prod to 801051622
west flash -d /home/abourgaud/repos/haugenplus_official/user-node/application/build_prod --dev-id 801051622

-- west flash: rebuilding
[0/6] Performing build step for 'application'
ninja: no work to do.
[1/6] Performing build step for 'mcuboot'
ninja: no work to do.
[3/6] Completed 'application'
[5/6] No install step for 'mcuboot'
[6/6] Completed 'mcuboot'
WARNING: Specifying runner options for multiple domains is experimental.
If problems are experienced, please specify a single domain using '--domain <domain>'
-- west flash: using runner nrfjprog
-- runners.nrfjprog: Flashing file: /home/abourgaud/repos/haugenplus_official/user-node/application/build_prod/mcuboot/zephyr/zephyr.hex
[ ######               ]   0.000s | Erase file - Check image                               [ ####                 ]   0.000s | Check image validity - Initialize device info          [ ########             ]   0.000s | Check image validity - Check region 0 settings         [ ############         ]   0.000s | Check image validity - block 1 of 3                    [ ################     ]   0.007s | Check image validity - block 2 of 3                    [ #################### ]   0.028s | Check image validity - Finished                        [ #############        ]   0.000s | Erase file - Erasing                                   [ ######               ]   0.000s | Erasing non-volatile memory - block 1 of 2             [ #############        ]   0.553s | Erasing non-volatile memory - block 2 of 2             [ #################### ]   0.000s | Erasing non-volatile memory - Erase successful         [ #################### ]   1.291s | Erase file - Done erasing                                                          
[ ######               ]   0.000s | Program file - Checking image                          [ ####                 ]   0.000s | Check image validity - Initialize device info          [ ########             ]   0.000s | Check image validity - Check region 0 settings         [ ############         ]   0.963s | Check image validity - block 1 of 3                    [ ################     ]   0.361s | Check image validity - block 2 of 3                    [ #################### ]   0.004s | Check image validity - Finished                        [ #############        ]   0.000s | Program file - Programming                             [ ######               ]   0.000s | Programming image - block 1 of 2                       [ #############        ]   0.147s | Programming image - block 2 of 2                       [ #################### ]   0.000s | Programming image - Write successful                   [ #################### ]   0.330s | Program file - Done programming                                                    
[ ######               ]   0.000s | Verify file - Check image                              [ ####                 ]   0.000s | Check image validity - Initialize device info          [ ########             ]   0.000s | Check image validity - Check region 0 settings         [ ############         ]   1.224s | Check image validity - block 1 of 3                    [ ################     ]   0.459s | Check image validity - block 2 of 3                    [ #################### ]   0.004s | Check image validity - Finished                        [ #############        ]   0.000s | Verify file - Verifying                                [ ######               ]   0.000s | Verifying image - block 1 of 2                         [ #############        ]   0.144s | Verifying image - block 2 of 2                         [ #################### ]   0.000s | Verifying image - Verify successful                    [ #################### ]   0.304s | Verify file - Done verifying                                                       
-- runners.nrfjprog: Board with serial number 801051622 flashed successfully.
-- west flash: using runner nrfjprog
-- runners.nrfjprog: reset after flashing requested
-- runners.nrfjprog: Flashing file: /home/abourgaud/repos/haugenplus_official/user-node/application/build_prod/application/zephyr/zephyr.signed.hex
[ ######               ]   0.000s | Erase file - Check image                               [ #####                ]   0.000s | Check image validity - Initialize device info          [ ##########           ]   0.000s | Check image validity - Check region 0 settings         [ ###############      ]   0.000s | Check image validity - block 1 of 2                    [ #################### ]   0.028s | Check image validity - Finished                        [ #############        ]   0.000s | Erase file - Erasing                                   [ ##########           ]   0.000s | Erasing non-volatile memory - block 1 of 1             [ #################### ]   0.000s | Erasing non-volatile memory - Erase successful         [ #################### ]   1.510s | Erase file - Done erasing                                                          
[ ######               ]   0.000s | Program file - Checking image                          [ #####                ]   0.000s | Check image validity - Initialize device info          [ ##########           ]   0.000s | Check image validity - Check region 0 settings         [ ###############      ]   0.531s | Check image validity - block 1 of 2                    [ #################### ]   0.002s | Check image validity - Finished                        [ #############        ]   0.000s | Program file - Programming                             [ ##########           ]   0.000s | Programming image - block 1 of 1                       [ #################### ]   0.000s | Programming image - Write successful                   [ #################### ]   0.402s | Program file - Done programming                                                    
[ ######               ]   0.000s | Verify file - Check image                              [ #####                ]   0.000s | Check image validity - Initialize device info          [ ##########           ]   0.000s | Check image validity - Check region 0 settings         [ ###############      ]   0.685s | Check image validity - block 1 of 2                    [ #################### ]   0.002s | Check image validity - Finished                        [ #############        ]   0.000s | Verify file - Verifying                                [ ##########           ]   0.000s | Verifying image - block 1 of 1                         [ #################### ]   0.000s | Verifying image - Verify successful                    [ #################### ]   0.402s | Verify file - Done verifying                                                       
Applying system reset.
Run.
-- runners.nrfjprog: Board with serial number 801051622 flashed successfully.

Thank you for your time,

AdBee

[Øyvind]

Hello, 

The Nordic Thingy:91 USB connector is connected to the USB interface of the nRF52840 SoC. This enables PC communication and battery charging. The nRF52840 comes preprogrammed with the Connectivity Bridge application which  acts as a USB composite device, exposing two UART interfaces to a USB host as two CDC ACM devices.

Did you reprogram the nRF52840? I.e. build for thingy91/nrf52840?

Also, I see that you are building you project for the thingy91/nrf9160 and not the thingy91/nrf9160/ns. The latter is needed in order to communicate with the nRF91 modem from the application core. See Developing with the Thingy:91 for more information.

Kind regards,
Øyvind

[AdBee]

Hello,

Thank you for your fast reply.

I think by using the thingy91/nrf9160 board instead of the thingy/nrf9160/ns, I may have overwritten some useful default partitions.

Following your link, I reinstalled all default images using the nRFConnect for Desktop, reflashed my own code with the thingy/nrf9160/ns board and it appears that it solved my problem.

I have further questions though:

1/ When I switch off/on the device using the SW1 switch, my program doesn't restart from scratch as expected, but rather seems to resume to where it was. How is it ? Is there a bootloader configuration that somehow saves PC and other registers ? Is it possible to change this behavior so that my program actually restarts at every power on ? It is unclear to me how the peripherals behave when their parameters are not explicitly set by my init functions.

2/ With regards to the partitions: I am used to customize them in a pm_static file to enable features such as nvs or BLE settings. But with this "ns" setup it seems that a lot of things are done under the hood that I shouldn't break. How can I customize partitions in this environment ?

Thank you for your time,

AdBee

[Øyvind]

AdBee said:

1/ When I switch off/on the device using the SW1 switch, my program doesn't restart from scratch as expected, but rather seems to resume to where it was. How is it ?

Could you provide logs from the application of what you are describing? This does not sound correct. What program are you running on the device?

AdBee said:

How can I customize partitions in this environment ?

The Thingy:91 uses its own partition layout, have a look at Partition layout. This uses e.g. nrf\boards\nordic\thingy91\thingy91_pm_static_lwm2m_carrier.yml

You could have a look at nrf\boards\nordic\thingy91\thingy91_nrf9160_partition_conf.dts

/*
 * Default Flash planning for thingy91_nrf9160.
 *
 * Zephyr build for nRF9160 with ARM TrustZone-M support,
 * implies building Secure and Non-Secure Zephyr images.
 *
 * Secure image will be placed, by default, in flash0
 * (or in slot0, if MCUboot is present).
 * Secure image will use sram0 for system memory.
 *
 * Non-Secure image will be placed in slot0_ns, and use
 * sram0_ns for system memory.
 *
 * Note that the Secure image only requires knowledge of
 * the beginning of the Non-Secure image (not its size).
 */

Let me know how that works for you.

Kind regards,
Øyvind

[AdBee]

Could you provide logs from the application of what you are describing? This does not sound correct. What program are you running on the device?

Sure. I am running this very basic program which logs the version of the app and then logs "HI" forever.

#include <stdio.h>
#include <zephyr/kernel.h>
#include <zephyr/logging/log.h>
#include <zephyr/sys/printk.h>

#include "app_version.h"

LOG_MODULE_REGISTER(MAIN, CONFIG_APP_LOG_LEVEL);

int main(void) {
  k_sleep(K_MSEC(100));

  LOG_INF("Hello World! %s\n", CONFIG_BOARD_TARGET);
  LOG_INF("START VERSION %s \n", APP_VERSION_STRING);

  while (true) {
    k_sleep(K_MSEC(1000));
    LOG_INF("HI \n");
  }

  // Run forever
  k_sleep(K_FOREVER);
}

This is what I see when I first flash the program:

*** Booting My Application v0.1.0-unstable-eaf0d677a29f ***
*** Using nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
[00:00:00.370,269] <inf> MAIN: Hello World! thingy91/nrf9160/ns

[00:00:00.376,708] <inf> MAIN: START VERSION 0.1.0-unstable 

[00:00:01.383,026] <inf> MAIN: HI 

[00:00:02.386,993] <inf> MAIN: HI 

[00:00:03.390,960] <inf> MAIN: HI 

[00:00:04.394,927] <inf> MAIN: HI 

[00:00:05.398,895] <inf> MAIN: HI

And this is what I see when I switch the device off/on:

[00:03:42.256,561] <inf> MAIN: HI 

[00:03:43.260,528] <inf> MAIN: HI 

    <-- Restart here 

[00:00:02.387,359] <inf> MAIN: HI 

[00:00:03.391,326] <inf> MAIN: HI 

[00:00:04.395,294] <inf> MAIN: HI

In this version the early logs don't print.

Now I am aware that log printing cannot be trusted 100% since they are not processed by the main thread but by the one that runs the default work_queue. On occasions there may be some delay/some loss (though I have CONFIG_LOG_MODE_IMMEDIATE=y in my .conf file which should somehow help a little). Still I have never witnessed an absence of early logs with a program that simple and that runs on such a low frequency when working with my previous nRF52840 project. So I am a bit surprised here.

The Thingy:91 uses its own partition layout, have a look at Partition layout. This uses e.g. nrf\boards\nordic\thingy91\thingy91_pm_static_lwm2m_carrier.yml

You could have a look at nrf\boards\nordic\thingy91\thingy91_nrf9160_partition_conf.dts

From my understanding, the pm_static files override the partitions that are defined in .dts files. Does the existence of the later file means that pm_static files are not used by default, but only if configs such as CONFIG_THINGY91_STATIC_PARTITIONS_FACTORY are provided ?

Say that I provide a custom pm_static file with CONFIG_THINGY91_NO_PREDEFINED_LAYOUT. Since I am using an external programmer and not the USB, I can overwrite the whole partition (size 0x100000) safely, right ? Won't this mess up the "connectivity bridge" that is deployed on the nRF52840 ? To what point does the "connectivity bridge" make assumptions about the partitions of the nRF9160 ?

Thank you for your support,

AdBee

[AdBee]

I have an additional question.

I am trying to interact with the LTE-M/GNSS module by using AT-commands.

First I flashed the AT-Client module and verified that I could send AT command through the serial terminal.

Now I am trying to send said AT-commands programmatically.

Taking inspiration from the AT Client sample and this page here is what I have:

#include <modem/nrf_modem_lib.h>
#include <stdio.h>
#include <string.h>
#include <zephyr/kernel.h>
#include <nrfxlib/nrf_modem/include/nrf_modem_at.h>
#include <zephyr/drivers/clock_control.h>
#include <zephyr/drivers/clock_control/nrf_clock_control.h>
#include <zephyr/drivers/uart.h>

/* To strictly comply with UART timing, enable external XTAL oscillator */
void enable_xtal(void) {
  struct onoff_manager *clk_mgr;
  static struct onoff_client cli = {};

  clk_mgr = z_nrf_clock_control_get_onoff(CLOCK_CONTROL_NRF_SUBSYS_HF);
  sys_notify_init_spinwait(&cli.notify);
  (void)onoff_request(clk_mgr, &cli);
}

int main(void) {
  int err;

  printk("The AT host sample started\n");

  err = nrf_modem_lib_init();
  if (err) {
    printk("Modem library initialization failed, error: %d\n", err);
    return 0;
  }
  enable_xtal();
  printk("Ready\n");
  err = nrf_modem_at_printf("AT+CFUN?");
  printk("%d\n", err);
}

Unfortunately I am having an error while linking the library:

/path/to/home/repos/sandbox/at_client_sample/src/main.c:12:10: fatal error: nrfxlib/nrf_modem/include/nrf_modem_at.h: No such file or directory
   12 | #include <nrfxlib/nrf_modem/include/nrf_modem_at.h>

I am unfamiliar with the build pipeline in the nrf toolchain and how I am supposed to properly do this, but I assume I might as well compile the nrfxlib library myself and then reference it as an external library in the CMakeLists.txt. So I ran:

cd ~/ncs/v2.9.0/nrfxlib
cmake .

And got:

CMake Error at CMakeLists.txt:14 (add_subdirectory_ifdef):
  Unknown CMake command "add_subdirectory_ifdef".

Since the command was not recognized, I though my cmake version might be outdated, but from my googling "add_directory_ifdef" isn't a native Cmake command but rather something defined by Zephyr/the NRF toolchain. I am a little puzzled at what to do. Any input ?

[AdBee]

Any update ?

EDIT: With regard to my last question, I found out that the nrfxlib library is already compiled in the packaged v2.9.0 SDK (as "west list" reveals). The correct way to import it is to call #include <nrf_model_at.h>. I would suggest updating this doc and this one which are misleading about it.

[Øyvind]

Hello, my apologies for the late reply. 

AdBee said:

The correct way to import it is to call #include <nrf_model_at.h>. I would suggest updating this doc and this one which are misleading about it.

Yes, I see what you man, which can be somewhat confusing. The best way is often to look at our samples in our SDK, but of course the documentation should reflect the code base. I will report internally.

AdBee said:

I am trying to interact with the LTE-M/GNSS module by using AT-commands.

Have you successfully been able to send AT commands programmatically? 

AdBee said:

Does the existence of the later file means that pm_static files are not used by default, but only if configs such as CONFIG_THINGY91_STATIC_PARTITIONS_FACTORY are provided ?

The build system should pick up on the file automatically. Have a look at Configuring static partitions in the partition manager. This is a KConfig symbol defined in nrf/boards/nordic/thingy91/Kconfig

config THINGY91_STATIC_PARTITIONS_FACTORY
	bool "Factory Thingy:91 partition layout"
	help
	   The default Thingy:91 partition layout used in the factory firmware. This ensures
	   firmware updates are compatible with Thingy:91 when flashing firmware over USB or over
	   the air.

Kind regards,
Øyvind

[AdBee]

Yes, I see what you man, which can be somewhat confusing. The best way is often to look at our samples in our SDK, but of course the documentation should reflect the code base. I will report internally.

I don't think there is a sample to demonstrate this functionnality, or at least I didn't find it.

Have you successfully been able to send AT commands programmatically? 

Yes with the nrf_modem_at_printf() function and the correct include it appears to work.

The only remaining question I have is about the absence of early logs. I assume it is because the hook that redirects outputs from the nRF9160 to the nRF52840 serial is set after some delay rather than at program start. Correct ?

Thank you for your support,

AdBee