Are there any updates to the atrocious DFU over USB DevAcademy guide?

[Bk37]

I don't know who's in charge of Dev Academy, but the nRF Connect SDK Intermediate Lesson 9 -- Bootloaderse and DFU/FOTA section looks like it was written as a back burner project that was abandoned.

Let me walk you through the process.

Exercise 4 -- DFU over USB, this shows you a guide, but when you select an older SDK version (such as 2.6.x), it tell you to go back to Exercise 2 (DFU with Custom Keys), so you go back to Exercise 2, despite the critical information in the v2.9.0 version of the guide, when you click the v2.6.x version, all that info is gone. So you scroll down, and it says it's going to build off an irrelevant DFU over UART guide... but then right after says it's going to depend on an entirely new sample project called "Lesson 9 -- Exercise 2", but that project doesn't exist as a sample in the SDK........

In another section, it points to a file in a folder in a different project called "app.overlay", but the project it links has no file called "app.overlay", later then says "as you can see here", and doesn't reference anything, no link, no picture, no file.

Nordic is top notch, the best imo, but this guide is one of the worst guides I've ever seen -- and this is the so called 'Academy'.... Is there any update to this? It's so contradictory that I'm afraid of committing to it in fear that it won't work or is outdated. It treats the different SDK versions completely differently, I don't even know if it wants me to follow both SDK version guides first, or just the version I use.

EDIT:

So I just wasted my time going through the entire guide, low and behold, just as expected, it does not work. The guide does not delineate what to leave in or take out, and only changing what it suggests not only doesn't work, but doesn't work BECAUSE it's based on the prior (DFU over UART) exercise.

[Sigurd Hellesvik]

Hi Bradley,

Thanks for your feedback!

While I had help, I did write the main bulk of Lesson 9 on bootloaders and DFU. We try to make them as best we can, but different factors make this hard to perfect. Among others:

1. When the nRF Connect SDK changes, we update the guide to follow changes. This can make the guide messy or even wrong, if we miss parts to update.
2. Following a guide and writing a guide is different, so it can be hard to get this right. We have people who test the course, but as they work in Nordic as well, they are already experienced.

Alright, enough with reasons and on to being constructive. I would be delighted if you through this ticket can help us improve the lesson. User feedback such as this is very valuable to use; It can help the next guy get a better experience than you had.

If you want to help, I got some questions to better understand the problems you faced following the guide:

when you click the v2.6.x version, all that info is gone.

What do you mean "gone"?

Here is what I see:

So you scroll down, and it says it's going to build off an irrelevant DFU over UART guide...

Could you screenshot exactly where we say this?

In another section, it points to a file in a folder in a different project called "app.overlay", but the project it links has no file called "app.overlay", later then says "as you can see here", and doesn't reference anything, no link, no picture, no file.

I see the misunderstanding here, and clarified this in the text as follows:

Do you agree that this is better?

It treats the different SDK versions completely differently, I don't even know if it wants me to follow both SDK version guides first, or just the version I use.

The nRF Connect SDK changes between versions. We have two choices:

1. Support DevAcademy for different version at once, so users for previous versions of the SDK can still follow along.
2. Only support DevAcademy for the latest verstion of the nRF Connect SDK and leave users for previous versions on their own.

We choose 1.

So I just wasted my time going through the entire guide, low and behold, just as expected, it does not work. The guide does not delineate what to leave in or take out, and only changing what it suggests not only doesn't work, but doesn't work BECAUSE it's based on the prior (DFU over UART) exercise.

I suspect that you have missed the part where we provide templates for the exercises, which all stepps apply to. In the same git, you can also see solution projects, which are often helpful.
Is this the case?

Saying this, we should probably mention the git project on every lesson page, so that users will more easily find these. I will talk with the DevAcademy owners about this.

Regards,
Sigurd Hellesvik

[Bk37]

Thanks for the reply Sigurd.

The guide also relies on bad assumptions, for example, I have zero interest in DFU over UART, and zero interest in Serial Recovery, and yet, all the information pertinent to my section of interest, it relies on information from previous lessons.

Ok, going through those extra lessons is not the biggest deal, except my device is not setup for DFU over UART, it's not possible, and neither is Serial Recovery (due to the physical button requirement). So I'm made to go through a full guide assuming it works, and unsurprisingly, by the time I get to a section that I can actually run, nothing works, and I have no way to test it independently because all the code is based on the previous project.

Even following from the start, the student is made to download 'Go', AuTerm, and mcumgr-cli, before I've even got to any functional code. If the student is made to read the newest version before the older version, why is the software requirements set on the new version? There should be clear separation here, not only is there no benefit from basing the project on the Serial Recovery UART, it's highly detrimental, the guide does a REALLY poor job delineating what's now useless from the DFU from UART project, so now I have a dysfunctional AND cluttered project.

I really think this section should be thrown out and rewritten from scratch, because it's so interdependent across different exercises, versions, and projects that none of it makes sense independently, and it's certainly not clear.

All of these images - and plenty more information - is exclusively listed in a version that is not relevant to me, and don't even have anything to do with versions at all.

[Sigurd Hellesvik]

Bk37 said:

The guide also relies on bad assumptions, for example, I have zero interest in DFU over UART, and zero interest in Serial Recovery, and yet, all the information pertinent to my section of interest, it relies on information from previous lessons.

Ok, going through those extra lessons is not the biggest deal, except my device is not setup for DFU over UART, it's not possible, and neither is Serial Recovery (due to the physical button requirement). So I'm made to go through a full guide assuming it works, and unsurprisingly, by the time I get to a section that I can actually run, nothing works, and I have no way to test it independently because all the code is based on the previous project.

Here I will have to disagree with you.

The guide explicitly says it uses Developement Kits (DKs) for the exercises. Because of this you cannot assume the exercises will work on a custom board out of the box. We recommend doing development on DKs in general, as those are tried and true Hardware to test on. Furthermore, I would recommend you to follow the guide on a DK. This way you can follow along with the exercise all the way. While you may not require DFU over UART for your final project, knowing how to do DFU with a easier method, such as UART, will make the DFU over BLE easier later.

That said, the BLE lesson is not based on the UART lesson. Its code is built on top of one of our Bluetooth samples.
The theory part should be relevant for all lessons. Alright, Single Slot DFU is not used for DFU over BLE, but it is a useful stepping stone to explaining Dual Slot DFU.

Bk37 said:

Even following from the start, the student is made to download 'Go', AuTerm, and mcumgr-cli, before I've even got to any functional code.

Huh. This should be split into "go mcumgr" for the old version and AuTerm for the new version. Could you let me know where in the new version we still instruct you to install "go mcumgr"?

Bk37 said:

If the student is made to read the newest version before the older version, why is the software requirements set on the new version?

Wait, no. You are only to read the version you are on. Is it implied somewhere in the course that you should read both?

Also, do you have any answers to my questions in my previous reply, to help me improve the course?

[Bk37]

So what is the point of the guide if it's not easily transferable to real hardware? People aren't following the guide to just play with DKs, they're following it to apply it to their own boards.

I will try to get back to your questions once I've figured this out, if I ever figure this out. Nearly every 'solution' I've found to people having issues revolving this section of the guide, they just give up. Not a good sign. There are way too many implicit variables presumed one-way in this guide. In dozens of spots, the guide makes the user jump back and forth from one section, back to another, requiring the user to re-read irrelevant sections that contain critical setup information.

I've even upgraded to the newest SDK and toolchain, and there's still so many issues with Lesson 9. Again, if it's to teach people something that they DON'T know, there is way too much implicit knowledge. 

For example, the guide says "To enable MCUboot in a nRF Connect SDK, simply add SB_CONFIG_BOOTLOADER_MCUBOOT=y to sysbuild.conf", but if only it was simple. With my default build configuration, THERE IS NO sysbuild.conf to add anything to. Manually adding all the sysbuild files does not change anything, AuTerm is still failing to find any MCUboot header files. Making a new build with "Use sysbuild" enabled makes no difference.

Given the posts I've seen from other people, and my very limited personal experience with the guide, my best advice is to completely split apart the versions. One entire guide for one version, one entire guide for another version. Erase all cross-references to different methodologies. If the user is has no intention of using Serial Recovery via UART, there should be no reason they have to go back-and-forth between the DFU from application via USB and exercises 1, 2 and 3, this just adds complexity for the user and for you to write it, and leaves plenty of legacy code that isn't going to be used. The guide should be built to be easily transferable to non-DK boards. And finally, the guide should have ALL critical build information clearly laid out, and clearly state when a pre-existing setting is to be erased or modified.

As far as I can tell, most people following the guide seem to be under the umbrella of using UART and Serial Recovery, and that part of the guide seems fine, but it gets really confusing really quick when using USB, and DFU from Application.

[James168]

Hi Bk37,

Do you know how to add sysbuild.conf from NCS v2.9.1 sample peripheral_lbs without using the github template sample? 

I am still stuck in this step. Does the sysbuild.conf need to new file manually?

[Bk37]

I did a few things, and I'm not sure which one was the dagger, but I'll list them all.

1. Make sure your build configuration has "use sysbuild" enabled.2

2. Create the sysbuild.conf file in your project's highest level directory (project_name/ <-- Here), and copy whatever sysbuild data you need from your example sysbuild file.

3. Make sure you're not using ANYTHING USB related other than the USB parts detailed by the DevAcademy guide.