Help activating bootloader logs on RTT

RE: Help activating bootloader logs on RTT

rmarques — Mon, 23 Sep 2019 09:18:56 GMT

Ah, ok, thanks Edvin, I'll be waiting then, good luck!

RE: Help activating bootloader logs on RTT

Edvin — Mon, 23 Sep 2019 08:59:58 GMT

Ok. I haven't tried to create the bootloader project yet (which was why I asked 🙂 ) I will try to see if I can get it up and running, but if it is something like the normal bootloader, it would require some changes to get it up and running, because the project will be too big when you include the NRF_LOG module.

RE: Help activating bootloader logs on RTT

rmarques — Mon, 23 Sep 2019 08:42:15 GMT

I didn't edit it yet, I could only manage to build it. In fact I couldn't even make a project out of it and my plan would be to edit the files in some text editor and build it using ninja since I could only get that to work.

I would prefer a Segger project for the mesh bootloader, but I'm happy as long as I can work with something.

RE: Help activating bootloader logs on RTT

Edvin — Mon, 23 Sep 2019 08:36:15 GMT

Can you send your bootloader project files so that I can unzip it in the SDK?

RE: Help activating bootloader logs on RTT

rmarques — Mon, 23 Sep 2019 08:29:01 GMT

Sure, but can you help me getting the RTT working with the mesh bootloader in the meantime, please? 🙂

I have things set up to build the bootloader already but I would like to have some RTT capabilities to try to debug the problem myself. I know for sure the Mesh team has enough on their plates already.

RE: Help activating bootloader logs on RTT

Edvin — Mon, 23 Sep 2019 07:51:11 GMT

Ok. I was not aware. I tested the DFU with this SDK, and it looks like it worked here, but maybe I was lucky, and didn't have any packet loss. I suggest that you follow up in the ticket that you linked to, where the issue was reported.

BR,

Edvin

RE: Help activating bootloader logs on RTT

rmarques — Fri, 20 Sep 2019 14:55:45 GMT

I'm using nRF52840 DKs.

The only change to the DFU example project were logging the received packets in the RTT.

It seems this is a curret problem on the mesh DFU, confirmed by the mesh team. Please advise if not true.

In the meantime, if I could get help activating the logs on the Bootloader, that would still be handy.

RE: Help activating bootloader logs on RTT

Edvin — Fri, 20 Sep 2019 14:27:42 GMT

Are you using nRF52840 Development Kits, or some other HW?

I tested it just now, and I don't see the same issue (using SDK_mesh3.2.0 and SDK15.3.0).

Have you done any changes to the DFU example project?

RE: Help activating bootloader logs on RTT

rmarques — Thu, 19 Sep 2019 12:54:30 GMT

I have two nodes side by side, both programmed with the DFU example built in debug mode, with a __LOG inside the nrf_mesh_dfu_rx function so I can inspect which DFU packets are being received using the RTT. The boards that I am using are two nRF52840 DKs with softdevice 6.1.1. DFU aborts on the node that is not connected to the computer.

RE: Help activating bootloader logs on RTT

Edvin — Thu, 19 Sep 2019 12:32:22 GMT

Sorry. I just saw 3.1.0 somewhere in your text. For 3.2.0 and SDK15.3.0, v3.40 of SES should be fine.

for 3.2.0, this guide is the updated one, but it should be the same, just with new recommended settings, such as --sd-req 0x00AF.

[quote user="rmarques"]When intended for the device connected to serial it works, when intended for others it fails on the others, the problem is on the recovery of lost packets.[/quote]

What are the other nodes programmed with? Do they have the DFU example running? The reason I ask whether it is the DFU example, or something built on the serial example, SDK\examples\serial, is that this example works a bit different.

How about the environment that you test in? Are the nodes close to one another? Did you change anything with regards to relay count? How many nodes do you use to test? Does the DFU fail on all devices, or only some?

RE: Help activating bootloader logs on RTT

rmarques — Wed, 18 Sep 2019 13:28:30 GMT

[quote userid="26071" url="~/f/nordic-q-a/52197/help-activating-bootloader-logs-on-rtt/210403"]Ok. I have seen some weird behaviour in DFU when using the non-specified version of SES. Can you please try to use the one listed in the release notes of SDK15.2.0, which is the SDK that is used with the Mesh SDK 3.1.0? That is, SES v3.40.[/quote]

I am using Mesh SDK 3.2.0, which uses SDK15.3.0, whose release notes report testing and verification with SES v4.12.

[quote userid="26071" url="~/f/nordic-q-a/52197/help-activating-bootloader-logs-on-rtt/210403"]I have never seen the error that you list before. Are you using the precompiled bootloader from the SDK?[/quote]

I am using the precompiled bootloader.

[quote userid="26071" url="~/f/nordic-q-a/52197/help-activating-bootloader-logs-on-rtt/210403"]Can you please try to follow this guide, and let me know at what point your behavior differs from the guides?[/quote]

I don't generate keys to keep it simple at first. I use blinky_nrf52840_xxAA_s140_6.1.1.hex and also update the --sd-req option when running nrfutil for SD 6.1.1, so instead of 0x00AF I use 0x00B6 and select the correct softdevice when flashing. The rest is the same.

[quote userid="26071" url="~/f/nordic-q-a/52197/help-activating-bootloader-logs-on-rtt/210403"]You can use another application than the blinky.hex. It shouldn't matter.[/quote]

That's my problem, it matters, the blinky.hex is 1.7KB and is very unlikely to fail a packet, the dfu example firmware image is larger than 100KB and much more likely to fail.

[quote userid="26071" url="~/f/nordic-q-a/52197/help-activating-bootloader-logs-on-rtt/210403"]I recommend writing a bat/sh script to generate the different files, and dfu image. Add some delay before starting the actual DFU to allow the applications to initialize before starting the DFU transfer. [/quote]

This was one of the first things we did when starting to try the DFU feature. We use a script to generate device page and flash softdevice, bootloader, app and device page, and another script for the DFU transfer.

[quote userid="26071" url="~/f/nordic-q-a/52197/help-activating-bootloader-logs-on-rtt/210403"]Is the file that you generate matching the device page on the serial device? Or is it intended for the other nodes? If so, what application are the other nodes running? Is it based on the normal examples in the SDK, or the serial example found in SDK_for_mesh\examples\serial ?[/quote]

When intended for the device connected to serial it works, when intended for others it fails on the others, the problem is on the recovery of lost packets.

RE: Help activating bootloader logs on RTT

Edvin — Wed, 18 Sep 2019 12:38:53 GMT

Ok. I have seen some weird behaviour in DFU when using the non-specified version of SES. Can you please try to use the one listed in the release notes of SDK15.2.0, which is the SDK that is used with the Mesh SDK 3.1.0? That is, SES v3.40.

I have never seen the error that you list before. Are you using the precompiled bootloader from the SDK?

Can you please try to follow this guide, and let me know at what point your behavior differs from the guides?

You can use another application than the blinky.hex. It shouldn't matter.

I recommend writing a bat/sh script to generate the different files, and dfu image. Add some delay before starting the actual DFU to allow the applications to initialize before starting the DFU transfer.

Is the file that you generate matching the device page on the serial device? Or is it intended for the other nodes? If so, what application are the other nodes running? Is it based on the normal examples in the SDK, or the serial example found in SDK_for_mesh\examples\serial ?

BR,

Edvin

RE: Help activating bootloader logs on RTT

rmarques — Wed, 18 Sep 2019 09:43:06 GMT

[quote userid="26071" url="~/f/nordic-q-a/52197/help-activating-bootloader-logs-on-rtt/210325"]Ok. What are the symptoms of your large firmware images not being able to run? [/quote]

After a while I get "Abort event. Reason: 0x3" on the targets, due to receiving too many packets after a lost segment was requested and not received/processed by the bootloader, I think.

[quote userid="26071" url="~/f/nordic-q-a/52197/help-activating-bootloader-logs-on-rtt/210325"]The mesh DFU is a background DFU, meaning that the bootloader only copies the firmware to the correct placement once the upload is finished, so it doesn't handle the upload. [/quote]

I know. Is there a proper way to upload a packet from the application side programmatically?

[quote userid="26071" url="~/f/nordic-q-a/52197/help-activating-bootloader-logs-on-rtt/210325"]I have tested the Mesh DFU with larger files, and it should work. Have you tried e.g. creating a DFU image of the dfu example? Does that work in your case?[/quote]

It did not, same thing as above. It did work with blinky though.

[quote userid="26071" url="~/f/nordic-q-a/52197/help-activating-bootloader-logs-on-rtt/210325"]Maybe you can tell me about the symptoms you see when it doesn't work? Do you get any messages returned from the nrfutil command when you try to update? Do you get any useful information from the application log on the nRF52840?[/quote]

I don't get anything useful on the nrfutil command, the sender board just keeps sending the packets until the end of the firmware image. I added some log messages inside the nrf_mesh_dfu_rx function in nrf_mesh_dfu.c so I could track the packets being received. I noticed that even though the lost packets were being asked for with the FFFB handle and received with the FFFA handle, after the second or third lost segment, FFFB handles were being sent from the target for packets already received with the FFFA handle.

[quote userid="26071" url="~/f/nordic-q-a/52197/help-activating-bootloader-logs-on-rtt/210325"]Also, can you tell me what version of SES you are using?[/quote]

SEGGER Embedded Studio for ARM
Release 4.12 Build 2018112601.37855
Linux x64

RE: Help activating bootloader logs on RTT

Edvin — Wed, 18 Sep 2019 09:09:57 GMT

Ok. What are the symptoms of your large firmware images not being able to run?

The mesh DFU is a background DFU, meaning that the bootloader only copies the firmware to the correct placement once the upload is finished, so it doesn't handle the upload.

I have tested the Mesh DFU with larger files, and it should work. Have you tried e.g. creating a DFU image of the dfu example? Does that work in your case?

Maybe you can tell me about the symptoms you see when it doesn't work? Do you get any messages returned from the nrfutil command when you try to update? Do you get any useful information from the application log on the nRF52840?

Also, can you tell me what version of SES you are using?

Best regards,

Edvin

RE: Help activating bootloader logs on RTT

rmarques — Wed, 18 Sep 2019 08:45:01 GMT

I am not able to run DFU over the mesh for large firmware packets (other than the blinky destributed with the mesh SDK) and I suspect the problem is on the mesh bootloader. I have already posted here about this.

I want to have the LOGs working on the bootloader side so I can investigate on my own at least until I have confirmation of the state of the DFU over mesh from nordic.

Since this is so hard to debug right now, we are thinking of implementing our own transport layer on the app side and just use the bootloader to transfer the firmware from the nodes' ram into flash, because that works.

RE: Help activating bootloader logs on RTT

Edvin — Wed, 18 Sep 2019 08:33:29 GMT

You are maybe aware of this, but most of the links you have provided are not for the mesh bootloader, but the "normal SDK" bootloader. Is there any specific reason why you need to enable logging in your mesh bootloader? Or why you need to change it at all?

RE: Help activating bootloader logs on RTT

rmarques — Tue, 17 Sep 2019 14:23:34 GMT

Yes, section placement macros are used inside the flash_placement.xml file.

I am talking about the mesh bootloader.

I am now looking at this post to see if I can get logs working.

RE: Help activating bootloader logs on RTT

Edvin — Tue, 17 Sep 2019 14:18:54 GMT

[quote user="rmarques"]I think the flash_placement.xml file is used by SEGGER to generate the linker script referred above at build time, so we should edit flash_placement.xml.[/quote]

That is correct. Segger embedded studio uses the falsh_placement.xml file for the flash placements, but I believe it also uses some of the project settings, so check project settings -> build -> Memory segments, and project settings -> linker -> section placement macros as well.

It depends a bit on what you want to change how many of these you have to modify.

You are talking about the mesh bootloader, or do you use the normal SDK's bootloader?

Best regards,

Edvin

RE: Help activating bootloader logs on RTT

rmarques — Tue, 17 Sep 2019 10:10:56 GMT

The linker folder inside the project folder doesn't seem to have any use. The linker script that matters is inside build/${name_of_project}_${build_type}/obj/${name_of_project}.ld.

I think the flash_placement.xml file is used by SEGGER to generate the linker script referred above at build time, so we should edit flash_placement.xml.