Use of the USB CDC ACM interface together with the BT Mesh Stack on the nRF52840 dongle

RE: Use of the USB CDC ACM interface together with the BT Mesh Stack on the nRF52840 dongle

Edvin — Fri, 06 Sep 2024 11:41:09 GMT

Ok, I understand. I mixed them up.

Can you please upload the application that replicates this precisely without any modifications? As mentioned, the previous application was waiting for some event that didn't occur, and when I bypassed it, it seemed to work in my case.

So fi you can upload an application that will fail when programmed using the bootloader, then I can try to replicate it again.

BR,

Edvin

RE: Use of the USB CDC ACM interface together with the BT Mesh Stack on the nRF52840 dongle

uli_hn — Wed, 04 Sep 2024 23:15:41 GMT

Hello dear Edvin,

I would like to thank you once again!!! for your explanations on the use of RTT and the correct creation of conf files. I am now in perfect hands :-)

Only with my last statement you misunderstood me:

[quote userid="135837" url="~/f/nordic-q-a/114182/use-of-the-usb-cdc-acm-interface-together-with-the-bt-mesh-stack-on-the-nrf52840-dongle/500654"]The error I have found is that flashing the dongle via the nRF52 DK works, but not via the bootloader. And this has nothing to do with my project. My project works with the dongle as long as it is flashed via the nRF52 DK.
And that shouldn't really be the case, should it?[/quote]

I repeat again:

First build (my workaround):

I build my project ( without nRF5 bootloader configuration )
I flash this error-free built project with the nRF52 DK (and the correctly set voltage) via SWD to the dongle
Result: everything works !!!

Second build (as specified/intended by nordic):

I build my project ( this time with nRF5 bootloader configuration - the default setting )
I take a brand new dongle out of the packaging, plug it in and put it into bootloader mode
I flash this error-free built project via the generated hex file with the programmer onto the dongle
Result: the project does not work !!! The dongle keeps restarting itself.

When I read your explanation, you think that my workaround didn't work. But that is not correct. It's the opposite. The way nordic intended is the one that doesn't work!

I wanted to draw your attention to this error.
best wishes
Uli

RE: Use of the USB CDC ACM interface together with the BT Mesh Stack on the nRF52840 dongle

Edvin — Tue, 03 Sep 2024 09:23:17 GMT

[quote user="uli_hn"]... Do I have to switch anything off for this or are there dependencies that could then no longer work? Or do I just put this in and connect the RTT to the terminal under the "connected devices" in VS Code and it works?[/quote]

It should be plug and play. I prefer to use a standalone RTT terminal, such as J-Link RTT Viewer, which is usually part of the JLink bundle. You probably have it installed already.

The RTT log has no dependencies, other than that it takes a small amount of processing power, and some memory (RAM) for the log. Then it is the debugger that is being used to read the log from the internal memory, so no GPIOs or peripherals are needed for this. Please note, however, that you need to reconnect the RTT viewer every time you program the device, because building the application again can cause the location of this buffer to move, so you need to tell the RTT terminal that this has happened.

[quote user="uli_hn"]One more thing: I have applied your explanations. Renaming the .overlay files leads to the desired success. They are automatically found and analysed as "Found devicetree overlay" during compilation. However, this does not work for the .conf files. I have to enter them manually in the "KConfig fragments", otherwise the compilation process is cancelled due to missing dependencies.[/quote]

Sorry. What I said wasn't entirely correct. You can put the nrf52840dongle_nrf52840.conf in a folder named "boards", then it should be picked up, as long as you use the default prj.conf file. You can look at how this is done in the ncs\nrf\samples\peripheral_uart\ sample, where it has the boards folder containing the thingy prj.conf files. The folder structure needs to be correct in order for this to work, so if you just do it like it is done in this sample, it should be picked up.

To make things worse, there are also several ways to acheive the same, so there is no "one rule to rule them all", unfortunately. You can read a bit about it here and here.

But the rule of thumb is that you should check your build log when you want to add new .conf or .overlay files. Then you will see what files that are included in your build.

[quote user="uli_hn"]The error I have found is that flashing the dongle via the nRF52 DK works, but not via the bootloader. And this has nothing to do with my project. My project works with the dongle as long as it is flashed via the nRF52 DK.[/quote]

So you pointed to the nRF52840 dongle programming guide earlier. From there you can read that if you erase the bootloader, there are some things that you need to make sure in order for it to work properly. When building for the nRF52840 dongle in NCS then it will assume that the bootloader is still present, because this is the intended way to use the dongle. If the bootloader is not present, then there are a couple of things that you need to make sure, and it is probably best to do this by using a custom board, and copy a lot of it from the board files for the dongle.

The main thing is that there is no longer a bootloader, so you would need to move the start address of the application from 0x1000 to 0x0000 (because there is no longer an MBR programmed).

Then you would need to read the section: "Using an external debugger" in the nRF52840 Dongle programming tutorial.

The thing is that the bootloader used to set the correct VREGOUT for the dongle. If this is erased, I am not sure whether or not you will be able to re-program it at all using a DK, or if you need a proper external programmer. You can of course give it a go, but the DKs are not properly tested for programming devices running at a different voltage than itself. So if you re-program the bootloader (you will find it in the linked guide), and then use the bootloader to load your application, and the debugger to debug, you should be fine.

If you want to properly skip the bootloader, make sure that you have all your start addresses set correctly, and that you do the REGOUT thing from the guide at the very start of your application. I am not completely sure, but it may work if you do it at the top of main. If not, you would need something like this in your main.c file. This will be called earlier in the bootup process, before the main() function is reached.

static int set_regulator(void)
{
  if ((NRF_UICR->REGOUT0 & UICR_REGOUT0_VOUT_Msk) ==
    (UICR_REGOUT0_VOUT_DEFAULT << UICR_REGOUT0_VOUT_Pos))
{
    NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
    while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

    NRF_UICR->REGOUT0 = (NRF_UICR->REGOUT0 & ~((uint32_t)UICR_REGOUT0_VOUT_Msk)) |
                        (UICR_REGOUT0_VOUT_3V0 << UICR_REGOUT0_VOUT_Pos);

    NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
    while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

    // System reset is needed to update UICR registers.
    NVIC_SystemReset();
}
  return 0;
}

SYS_INIT(set_regulator, POST_KERNEL, 80);

Best regards,

Edvin

Best regards,

Edvin

RE: Use of the USB CDC ACM interface together with the BT Mesh Stack on the nRF52840 dongle

uli_hn — Sun, 01 Sep 2024 17:36:12 GMT

[quote userid="26071" url="~/f/nordic-q-a/114182/use-of-the-usb-cdc-acm-interface-together-with-the-bt-mesh-stack-on-the-nrf52840-dongle/500571"]

This means e.g. that it will not automatically pick up the board files (if you had any).

So the "correct" way to do this is to use a common prj.conf file that will be used for all your different builds. Then you can add your prj_dongle.conf as an extra KConfig file by using the "Extra KConfig fragments" option. Alternatively, if you would have named the other conf file <board_name>.conf, like this:

nrf52840dongle_nrf52840.conf,

then it will automatically be picked up as an extra KConfig fragment. The same goes for the .overlay files. If it was called nrf52840dongle_nrf52840.overlay, then the compiler will pick it up automatically.

Anyway, it is possible to add any files as extra KConfig fragments.

[/quote]

Hey Edvin,

One more thing: I have applied your explanations. Renaming the .overlay files leads to the desired success. They are automatically found and analysed as "Found devicetree overlay" during compilation. However, this does not work for the .conf files. I have to enter them manually in the "KConfig fragments", otherwise the compilation process is cancelled due to missing dependencies.

best uli

RE: Use of the USB CDC ACM interface together with the BT Mesh Stack on the nRF52840 dongle

uli_hn — Sat, 31 Aug 2024 17:05:35 GMT

[quote userid="26071" url="~/f/nordic-q-a/114182/use-of-the-usb-cdc-acm-interface-together-with-the-bt-mesh-stack-on-the-nrf52840-dongle/500572"]

CONFIG_USE_SEGGER_RTT=y

CONFIG_LOG_BACKEND_RTT=y

This way you can monitor the log without UART.

[/quote]

... Do I have to switch anything off for this or are there dependencies that could then no longer work? Or do I just put this in and connect the RTT to the terminal under the "connected devices" in VS Code and it works?

RE: Use of the USB CDC ACM interface together with the BT Mesh Stack on the nRF52840 dongle

uli_hn — Sat, 31 Aug 2024 16:57:44 GMT

Dear Edvin,

Firstly, thank you for your comments regarding conf's and overlays. I actually knew that, but somehow, due to laziness and rapid prototyping, these features crept in, although it is much more convenient to do it the way you described. I have now rebuilt it 😊

Regarding your issues: I had exactly the same problem (as described above). And the solution was not to change anything (in the code or in the settings), but simply not to interrupt the initialisation routines with debug breakpoints within the debug process. This applies to both: init serial interface and init BT Mesh!

Then everything runs smoothly. And the system works as it should. It receives data via the serial interface, analyses it and tries to send the analysis to the Mesh. In fact, I have now provisioned the dongle and the BT Mesh also receives all the data.

The error I have found is that flashing the dongle via the nRF52 DK works, but not via the bootloader. And this has nothing to do with my project. My project works with the dongle as long as it is flashed via the nRF52 DK.
And that shouldn't really be the case, should it?

Sunny regards Uli

RE: Use of the USB CDC ACM interface together with the BT Mesh Stack on the nRF52840 dongle

Edvin — Fri, 30 Aug 2024 11:57:42 GMT

Oh, and I enabled the RTT logging by adding these two to your prj.conf:

CONFIG_USE_SEGGER_RTT=y

CONFIG_LOG_BACKEND_RTT=y

This way you can monitor the log without UART.

RE: Use of the USB CDC ACM interface together with the BT Mesh Stack on the nRF52840 dongle

Edvin — Fri, 30 Aug 2024 11:56:14 GMT

Hello Uli,

Thank you for clarifying 🙂 This was the kind of information I was fishing for, what you did with the bootloader, but it seems like you are on top of things.

Some general hints:

The way you set up the different builds is not really how it is intended to be done. Although it may seem harmless to use prj_dongle.conf as the base configuration file, that will actually cause the rest of the project to fail. You see, if you set the base configuration file to prj_dongle.conf, it will also look for all the other files, such as board files, child image files ending in _dongle.*

This means e.g. that it will not automatically pick up the board files (if you had any).

nrf52840dongle_nrf52840.conf,

Anyway, it is possible to add any files as extra KConfig fragments.

Sorry that this took so long, but I needed to add a debug header to one of my nRF52840 dongles.

When I ran your application (both on DK and dongle) it stopped at

	LOG_INF("Wait for DTR");

	while (true) {
		uint32_t dtr = 0U;
		if ( (int_ret = uart_line_ctrl_get(uart_dev, UART_LINE_CTRL_DTR, &dtr)) ) {
		    LOG_ERR("Failed to retrieve line control for UART, ret code %d", int_ret);  // ENOTSUP = 134 -> Unsupported value | if API is not enabled // ENOSYS = 88 -> Function not implemented                                                                                      
	    }
        
		if (dtr) {
			break; // jump out of the while
		} 

        /* [else] Give CPU resources to low priority threads. */
		k_sleep(K_MSEC(100));
	}

I am not sure what is actually supposed to happen here. Perhaps I am using the wrong terminal or something. I read your last reply, and I understand that you did some changes, but I am not sure which ones.

If I break out of this while loop, then I get a Bus Fault:

00> Sensovo Dongle (Zephyr OS Build v3.3.99-ncs1-2) is initializing...
00> 
00> [00:00:00.701,019] <inf> serial: Wait for DTR
00> [00:00:00.701,019] <inf> serial: DTR set
00> [00:00:00.842,285] <err> usb_nrfx: Endpoint 0x81 is not enabled
00> [00:00:01.094,573] <inf> serial: Baudrate detected: 115200
00> [00:00:01.701,965] <err> os: ***** BUS FAULT *****
00> [00:00:01.701,995] <err> os:   Imprecise data bus error[0m
00> [00:00:01.701,995] <err> os: r0/a1:  0x00000000  r1/a2:  0x2000bc2c  r2/a3:  0x20004f04
00> [00:00:01.702,026] <err> os: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x0003ef5d
00> [00:00:01.702,026] <err> os:  xpsr:  0x61000000
00> [00:00:01.702,056] <err> os: Faulting instruction address (r15/pc): 0x0002396c
00> [00:00:01.702,087] <err> os: >>> ZEPHYR FATAL ERROR 26: Unknown error on CPU 0
00> [00:00:01.702,117] <err> os: Current thread: 0x20004cd0 (unknown)
00> [00:00:01.930,023] <err> fatal_error: Resetting system[0m

Is this what you are seeing as well?

Best regards,

Edvin

RE: Use of the USB CDC ACM interface together with the BT Mesh Stack on the nRF52840 dongle

uli_hn — Wed, 28 Aug 2024 18:11:29 GMT

Dear Edvin,

I played around a bit with the reproducibility of the problem. Because I also wanted to be able to check the process on the nRF52840 DK. On that I was already able to use our system (serial interface incl. BT Mesh) to analyse a transferred protocol:

But every time I started the debugger, the nRF52840 DK system ran into a ‘fatal error’ at the breakpoints during the initialisation of the serial interface.
On reflection, it occurred to me that the hardware of time-based systems such as UART requires certain response times during initialisation, which must not be undercut.
So I removed all breakpoints during the initialisation of the serial interface and came to exactly the initialisation point of BT Mesh that leads to the error as mentioned in the post above.
This allowed me to reproduce the same error on the nRF52840 DK as on the nRF52 DK with the nRF52840 dongle connected.
But I thought to myself that BT Mesh/BLE is also a time-based system and that certain response times or, in this case, a switch to another ‘worker’ is necessary at certain times.
So I started the debugger again on the nRF52 DK and found out that this system also runs through without errors, as long as the serial initialisation or the initialisation of BT Mesh is not interrupted.
On both systems (nRF52 DK with connected nRF52840 dongle & nRF52840 DK) the project can be compiled, debugged and executed without any problems

Sometimes it makes sense to take a look at the datasheet of the microcontroller and the exact specifications of the hardware, in particular the required/requested time intervals of the used systems (UART/BLE) 😉.

Now, however, I wanted to find out why the dongle cannot be started without debugging options or why it keeps resetting all the time after he is flashed.

To do this, I created a build on the nRF52 DK with the nRF52840 dongle connected, which does not contain any debugging options. This build was flashed to the dongle via the nRF52 DK.
(And even as a standalone dongle - also tested on other PC systems...)
this build works as it should on the nRF52840 dongle !!!

Maybe I had changed some tweak in the meantime (which I had meticulously made sure not to do) that made the dongle work. Okay, programming the dongle with the bootloader:

The nrf52840dongle_nrf52840.dts set back to #include ‘fstab-stock.dts’ and in the KConfig set BOARD_HAS_NRF5_BOOTLOADER setting back to default y
Then generated a presitina build and flashed the created zephyr.hex via the programmer to the dongle with the bootloader ( graviton_bootloader_mbr_v1.0.1-[nRF5_SDK_15.0.1-1.alpha_f76d012].hex ).
Error: the dongle is plugged into the USB port and keeps restarting - it probably keeps starting a reset

Could it have something to do with our project? We have modelled our BT Mesh project on your examples: Bluetooth Mesh Light, BT Mesh Light Switch, BT Mesh Chat. So I took your Bluetooth Mesh Light example project and simply added our serial interface (also derived from your CDC ACM example) to it. Same procedure as above:

prestina build via nRF52 DK flashed to connected nRF52840 dongle (nrf52840dongle_nrf52840.dts with #include ‘fstab-debugger.dts’ / BOARD_HAS_NRF5_BOOTLOADER default n)
=> works!
prestina build, zephyr.hex flashed to the dongle via the programmer (nrf52840dongle_nrf52840.dts with #include ‘fstab-stock.dts’ / BOARD_HAS_NRF5_BOOTLOADER default y)
=> does not work! Constant resets.

The only difference in both conf's is:

Bootloader => CONFIG_FLASH_LOAD_OFFSET=0x1000 & CONFIG_BOARD_HAS_NRF5_BOOTLOADER=y
nRF52 DK => CONFIG_FLASH_LOAD_OFFSET=0 & #CONFIG_BOARD_HAS_NRF5_BOOTLOADER is not set

The differences in the DTS are in the four partitions (boot, slot0, slot1, storage):
Bootloader / nRF52 DK

flash_controller: flash-controller@4001e000 {
	compatible = "nordic,nrf52-flash-controller";
	reg = < 0x4001e000 0x1000 >;
	partial-erase;
	#address-cells = < 0x1 >;
	#size-cells = < 0x1 >;
	flash0: flash@0 {
		compatible = "soc-nv-flash";
		erase-block-size = < 0x1000 >;
		write-block-size = < 0x4 >;
		reg = < 0x0 0x100000 >;
		partitions {
			compatible = "fixed-partitions";
			#address-cells = < 0x1 >;
			#size-cells = < 0x1 >;
			boot_partition: partition@1000 {
				label = "mcuboot";
				reg = < 0x1000 0xf000 >;
			};
			slot0_partition: partition@10000 {
				label = "image-0";
				reg = < 0x10000 0x66000 >;
			};
			slot1_partition: partition@76000 {
				label = "image-1";
				reg = < 0x76000 0x66000 >;
			};
			storage_partition: partition@dc000 {
				label = "storage";
				reg = < 0xdc000 0x4000 >;
			};
		};
	};
};

flash_controller: flash-controller@4001e000 {
	compatible = "nordic,nrf52-flash-controller";
	reg = < 0x4001e000 0x1000 >;
	partial-erase;
	#address-cells = < 0x1 >;
	#size-cells = < 0x1 >;
	flash0: flash@0 {
		compatible = "soc-nv-flash";
		erase-block-size = < 0x1000 >;
		write-block-size = < 0x4 >;
		reg = < 0x0 0x100000 >;
		partitions {
			compatible = "fixed-partitions";
			#address-cells = < 0x1 >;
			#size-cells = < 0x1 >;
			boot_partition: partition@0 {
				label = "mcuboot";
				reg = < 0x0 0x12000 >;
			};
			slot0_partition: partition@12000 {
				label = "image-0";
				reg = < 0x12000 0x75000 >;
			};
			slot1_partition: partition@87000 {
				label = "image-1";
				reg = < 0x87000 0x75000 >;
			};
			storage_partition: partition@fc000 {
				label = "storage";
				reg = < 0xfc000 0x4000 >;
			};
		};
	};
};

At this point, I'm at a bit of a loss. Could it have something to do with the CONFIG_HEAP_MEM_POOL_SIZE=4096 attribute that we have set?
Could it be that the access points have changed and the bootloader is not processing them correctly?

Perhaps you have already been able to take a look at it and get an overview.

I am curious about it
best regards
uli

RE: Use of the USB CDC ACM interface together with the BT Mesh Stack on the nRF52840 dongle

uli_hn — Tue, 27 Aug 2024 15:39:18 GMT

Hey Edvin,

don't worry, I wrote this post right before the weekend, so I don't expect to get an answer soon.

My debug environment is: VS Code & nRF Connect and a nRF52 DK. (I have also tried to use only the nRF52840 DK, but it crashes during serial initialisation or the debugger hangs.)

At the place of system crash i mentioned above leads to a "fatal errer: Kernel oops".

The output from DEBUG CONSOLE is the following:

JLinkGDBServerCL: SEGGER J-Link GDB Server V7.94e Command Line Version
JLinkGDBServerCL: 
JLinkGDBServerCL: JLinkARM.dll V7.94e (DLL compiled Jan 15 2024 15:18:46)
JLinkGDBServerCL: 
JLinkGDBServerCL: -----GDB Server start settings-----
JLinkGDBServerCL: GDBInit file:                  none
JLinkGDBServerCL: GDB Server Listening port:     58968
JLinkGDBServerCL: SWO raw output listening port: 2332
JLinkGDBServerCL: Terminal I/O port:             2333
JLinkGDBServerCL: Accept remote connection:      localhost only
JLinkGDBServerCL: Generate logfile:              off
JLinkGDBServerCL: Verify download:               off
JLinkGDBServerCL: Init regs on start:            off
JLinkGDBServerCL: Silent mode:                   on
JLinkGDBServerCL: Single run mode:               on
JLinkGDBServerCL: Target connection timeout:     0 ms
JLinkGDBServerCL: ------J-Link related settings------
JLinkGDBServerCL: J-Link Host interface:         USB
JLinkGDBServerCL: J-Link script:                 none
JLinkGDBServerCL: J-Link settings file:          none
JLinkGDBServerCL: ------Target related settings------
JLinkGDBServerCL: Target device:                 nRF52840_xxAA
JLinkGDBServerCL: Target device parameters:      none
JLinkGDBServerCL: Target interface:              SWD
JLinkGDBServerCL: Target interface speed:        12000kHz
JLinkGDBServerCL: Target endian:                 little
JLinkGDBServerCL: 
=thread-group-added,id="i1"
=cmd-param-changed,param="pagination",value="off"
z_arm_reset () at C:/ncs/v2.4.3/zephyr/arch/arm/core/aarch32/cortex_m\reset.S:73
73	    movs.n r0, #0
[New Remote target]
[New Thread 536891328]
[New Thread 536891144]
[New Thread 536880744]
[New Thread 536882016]
[New Thread 536882232]
[New Thread 536890928]
[New Thread 536891512]
[New Thread 536885248]
[New Thread 536880560]
[Switching to Thread 536891328]

Thread 3 hit Breakpoint 1, main () at ../src/main.c:46
46	int main(void) {
Execute debugger commands using "-exec <command>" or "`<command>", for example "-exec info registers" or "`info registers" will list registers in use (when GDB is the debugger)
[New Thread 536880560]

Thread 3 hit Breakpoint 4, main () at ../src/main.c:76
76		init_serial();	// enable USB, initialize UART, printing LOG messages as well as 'printk'-outputs
[New Thread 536882448]
[New Thread 536882632]
[New Thread 536890696]
[New Thread 536884792]
[Switching to Thread 536891512]

Thread 9 hit Breakpoint 2, bt_ready (err=0) at ../src/main.c:42
42		bt_mesh_prov_enable(BT_MESH_PROV_ADV | BT_MESH_PROV_GATT); // with the bit wise 'OR' ()"1"|"2" =) "3" => (01 | 10 =) 11 (bit-style) is send

Thread 9 hit Breakpoint 6, bt_mesh_prov_bearer_cb_get () at C:/ncs/v2.4.3/zephyr/subsys/bluetooth/mesh/prov.c:417
417		return &prov_bearer_cb;

Thread 9 hit Breakpoint 5, bt_mesh_prov_enable (bearers=bearers@entry=(BT_MESH_PROV_ADV | BT_MESH_PROV_GATT)) at C:/ncs/v2.4.3/zephyr/subsys/bluetooth/mesh/prov_device.c:685
685		if (IS_ENABLED(CONFIG_BT_MESH_PB_GATT) &&

Thread 9 hit Breakpoint 6, bt_mesh_prov_bearer_cb_get () at C:/ncs/v2.4.3/zephyr/subsys/bluetooth/mesh/prov.c:417
417		return &prov_bearer_cb;
[New Remote target]
[Switching to Remote target]

Thread 17 hit Breakpoint 7, k_sys_fatal_error_handler (reason=3, esf=0x2000b85c <z_interrupt_stacks+1948>) at C:/ncs/v2.4.3/nrf/lib/fatal_error/fatal_error.c:18
18	{

Regarding your question about flashing:
(Firstly, I have several dongles ;-), one that is connected to the nRF52 DK and several with pre-programmed bootloader on it). I do the (standalone) app flashing via the nRF Connect Tool using the generated hex file and the pre-programmed bootloader. However, with the compiled NRF5_BOOTLOADER=y and the included fstab-stock.dts settings. This is changed for debugging. With the changed conf and dts settings, I flash the dongle connected to the nRF52 DK from VS Code. Everything according to your https://devzone.nordicsemi.com/guides/short-range-guides/b/getting-started/posts/nrf52840-dongle-programming-tutorial.

Here is the complete project: devzone.nordicsemi.com/.../mesh_5F00_node_5F00_uart.zip

To compile your own build version, you would have to select the nrf52840dongle.overlay and the prj_dongle.conf. And for debugging, you should also go to the board settings of the 2.4.3 SDK (here is the path: \ncs\v2.4.3\zephyr\boards\arm\nrf52840dongle_nrf52840 ) in the Kconfig the entry BOARD_HAS_NRF5_BOOTLOADER=n and in the nrf52840dongle_nrf52840.dts instead of the line #include "fstab-stock.dts" use the line #include "fstab-debugger.dts". I probably didn't need to write that to you, because of course you know that.

Many thanks in advance for your help.

Best regards Uli

RE: Use of the USB CDC ACM interface together with the BT Mesh Stack on the nRF52840 dongle

Edvin — Tue, 27 Aug 2024 14:24:18 GMT

Hello Uli,

Sorry for the late reply.

When you debug, and find the place where it crashes. What does that mean? Does it stop/hang? Does the (RTT) log say anything at this point in time? If you have a debugger connected you can monitor the RTT log.

And if it is inconclusive, feel free to upload the DK and dongle application files so that I can have a look. It is easier to test and try to replicate than reading through thousands of lines of config not knowing what to look for.

And how did you flash the application to the dongle? Via the pre-programmed bootloader, or using a debugger? If you used a debugger, does that mean that you have erased the pre-programmed bootloader?

Best regards,

Edvin

RE: Use of the USB CDC ACM interface together with the BT Mesh Stack on the nRF52840 dongle

uli_hn — Mon, 26 Aug 2024 17:38:13 GMT

I have some more info after debugging the dongle via the nRF52 DK until the system crashed:

Inside <int bt_enable(bt_ready_cb_t cb)> [from the hci_core.c file] the implemented and sent callback function is initialised.
At the end of this function, <bt_mesh_prov(BT_MESH_PROV_ADV | BT_MESH_PROV_GATT);> is called.
At the end of this function, there are two queries (one ADV and one GATT) in which the callback is to be linked to the provsioning bearer:
- bt_mesh_pb_adv.link_accept(bt_mesh_prov_bearer_cb_get(), NULL);. ( prov_device.c ).
- When returning to "bt_mesh_pb_adv", the pointer to the prov_bearer is still returned.
- On the second return to "bt_mesh_pb_gatt" there is a system crash in the "prov.c" file.

int main(void) {

	[...]
	init_serial();	// enable USB, initialize UART, printing LOG messages as well as 'printk'-outputs
    [...]
	err = bt_enable(bt_ready); // calls the BT enable function in hci_core.c and passes our callback function to our BT Mesh clients 
    
    ------------------
    int bt_enable(bt_ready_cb_t cb) { [...] k_work_submit(&bt_dev.init); return 0; }
    ------------------
    static void bt_ready(int err) { [...] bt_mesh_prov_enable(BT_MESH_PROV_ADV | BT_MESH_PROV_GATT); }
    ------------------
    int bt_mesh_prov_enable(bt_mesh_prov_bearer_t bearers) { 
        [...]
    	if (IS_ENABLED(CONFIG_BT_MESH_PB_ADV) &&
    	    (bearers & BT_MESH_PROV_ADV)) {
    		bt_mesh_pb_adv.link_accept(bt_mesh_prov_bearer_cb_get(), NULL);
    	    ------------------
        	    const struct prov_bearer_cb *bt_mesh_prov_bearer_cb_get(void) { 
        	        return &prov_bearer_cb;  // HERE IT STILL WORKS
        	    }
    	    ------------------
        }
    	if (IS_ENABLED(CONFIG_BT_MESH_PB_GATT) &&
    	    (bearers & BT_MESH_PROV_GATT)) {
    		bt_mesh_pb_gatt.link_accept(bt_mesh_prov_bearer_cb_get(), NULL);
    		------------------
        	    const struct prov_bearer_cb *bt_mesh_prov_bearer_cb_get(void) { 
        	        return &prov_bearer_cb;  // HERE CRASHES
        	    }
    	    ------------------
    	}
    [...]

Thanks for looking at it,
sunny regards
uli