nRF Connect SDK 2.4.2 - SLM application - AT#XDFUGET broken

RE: nRF Connect SDK 2.4.2 - SLM application - AT#XDFUGET broken

Simonr — Mon, 06 Nov 2023 07:06:48 GMT

So, I heard back from the developers again, and they think they've solved this issue now. The following changes will have to be done on your end to have the SLM DFU to the nRF52840 work in NCS 2.4.0.

nRF91 SLM:

The download client change of new DOWNLOAD_CLIEND_EVT_CLOSED, which is critical to sync the download of init data and file image. For UART TX DMA, always do memory copy in case the legacy DDU Slip overwrites the buffer during DMA.

The changes necessary can be found in “slm_at_dfu.c” (uploaded previously and “slm_at_host.c” respectively.

devzone.nordicsemi.com/.../slm_5F00_at_5F00_host.c

nRF52 app:

There is a major function change for the DFU function in https://github.com/nrfconnect/sdk-nrf/pull/9960, so the cluent must handle this behavior change (from NCS 2.0.0):

AT#XDFUGET will get “OK” right after init data is downloaded, this used to be after init data and file image is downloaded.
AT#XDFUGET will send “#XDFUGET: 1,<downloaded percentage>” unsolicited while downloading file image, and “#XDFUGET: 1, 100” means the full image was downloaded.
The new AT#XDFUSIZE command could be used to get the size of the file image if needed.
The nRF52 app should swap to bootloader mode only after the full file image has been downloaded on SLM side.

After implementing these changes we were able to complete SLM to nRF52 DFU as expected (with UART HWFC disabled).

Best regards,

Simon

RE: nRF Connect SDK 2.4.2 - SLM application - AT#XDFUGET broken

Simonr — Wed, 01 Nov 2023 07:08:07 GMT

One thing that could affect DFU is the fact that SLM has refactored UART DMA transmissions. Memory copy is removed and use direct memory access for DMA. This needs some access control which is implemented for the data mode, but not for DFU I'm afraid.

For more details we'll have to wait for next week when the expert on this is back in office I'm afraid.

Best regards,

Simon

RE: nRF Connect SDK 2.4.2 - SLM application - AT#XDFUGET broken

Simonr — Tue, 31 Oct 2023 15:48:32 GMT

I'm sorry, but DFU and AT commands isn't my area of expertise, and we're short on them in tech support at the moment, so I have forwarded this to the development team. It seems my explanation wasn't good enough as the fix I got was one you have tried and implemented already. Very sorry about that, but I have reiterated the problem to the devs now and someone will hopefully look at it soon. One of the experts in the field is out of office until Nov. 6th though, so it might be as late as that before you get a reply.

Sorry about the inconvenience.

Best regards,

Simon

RE: nRF Connect SDK 2.4.2 - SLM application - AT#XDFUGET broken

Gaétan — Mon, 30 Oct 2023 15:14:23 GMT

Hello Simon,
Thank you for your reply. I was on vacation last week and I'm just getting back to work...

I have the impression that you didn't read my first post all the way through, because the fix you're proposing is precisely the one I proposed in the first post...

After handling the DOWNLOAD_CLIENT_EVT_CLOSED event, I then encountered another problem: the current_id variable in dfu_target_stream.c wasn't initialized correctly. I corrected this by forcing a call to the dfu_target_nrf52_done() function.

With these 2 fixes, web downloading works perfectly.

Now the problem I'm talking about and which is totally blocking me is during the nRF52 update.
In the log I provided in my first post, you'll find an erroneous SLIP frame on line 716; this case always occurs with the same error. I think the problem is due to the many changes that took place in slm_at_host.c between version 2.0.0 and 2.4.2.

Could you please help me identify why an RS232 frame is incorrectly constructed by slm_at_host.c during nRF52 update ?

Best regards,
Gaétan

RE: nRF Connect SDK 2.4.2 - SLM application - AT#XDFUGET broken

Simonr — Tue, 24 Oct 2023 08:04:13 GMT

Sorry that it took a few days to get back to you, but I had to contact the developers to make sure I got the correct answer for you. The download_client has added one more event "DOWNLOAD_CLIENT_EVT_CLOSED, which says "Connection have been closed. Client is now idle, ready for next download". SLM will need to wait for this event after downloading the init data before starting to download the DFU image. Some simple changes in slm_at_dfu.c makes it work again.

Can you try the following file in NCS v2.4.2, as that should make the ATDFUGET command (and similar) stable. It is based on NCS 2.4.0 which was the last stable version.

devzone.nordicsemi.com/.../slm_5F00_at_5F00_dfu.c

Best regards,

Simon

RE: nRF Connect SDK 2.4.2 - SLM application - AT#XDFUGET broken

Gaétan — Fri, 20 Oct 2023 13:55:41 GMT

Ok I understand that the team is dropping support for these AT commands, but in theory in SDK version 2.4.2, these commands are supposed to work...

I would have appreciated it if this last version supporting them had been functional. Between you and me, I already think it's a shame that this functionality has been removed without an effective replacement option. And it would have been nice if the latest version supporting it had been functional.

To save me some time, what is the most recent SDK version that fully supports AT#DFUGET with nRF52?

RE: nRF Connect SDK 2.4.2 - SLM application - AT#XDFUGET broken

Simonr — Fri, 20 Oct 2023 13:31:00 GMT

Hi Gaétan

We decided to remove the DFUAT commands I'm afraid, as they aren't very well compatible with the nRF52840, so you're left with two options for what to do here.

The simplest one would be to stick to the older version of the nRF Connect SDK, but that would also be kind of a dead end in terms of future development, as you won't get access to new features in new versions of the SDK. If you're fine with that this is fine.
You can alternatively restore the DFU implementation to SLM on their custom solution. The removal commits are available in the git and in this pull request. They are pretty well isolated, but it will require more effort than just reverting the commits as the UART implementation was refactored.

Best regards,

Simon