DTM test procedure over Bootloader + SoftDevice

[beemavishnu]

Hello,

 

I am using nRF52840, SDK_16.0.0, S140 SoftDevice and Segger 4.16 for flashing the image.

 

1) At factory first we will load Secure Serial Bootloader and SoftDevice. Without erasing them, we want to do DTM. Whether can I load DTM package from below path using nrfutil.

                \examples\dtm\direct_test_mode\pca10056\blank\ses

 

2) As per below post can’t I use load SoftDevice along with DTM.

a) Since SoftDevice only loaded but nowhere enabled, still DTM can be loaded. Please correct my understanding.

                https://devzone.nordicsemi.com/f/nordic-q-a/42488/how-to-run-dtm-on-nrf52840-development-kit-using-mt8852b/167016#167016

                https://devzone.nordicsemi.com/f/nordic-q-a/33236/52840-dtm

 

Thanks & Regards

Vishnu Beema

[Einar Thorsrud]

Hi Vishnu,

Your understanding is not entirely correct. There is no problem having both the SoftDevice and a DTM application in flash at the same time. The point is that the DTM firmware uses the radio directly, which is not allowed when the SoftDevice is enabled. So you can use DTM as long as you make sure to not enable the SoftDevice.

In practice, I would say it makes more sense to use specific firmware for the DTM, and then program the actual firmware later. Bu tif you like, you could, for instance, read a GPIO input (or some other input) and use that to decide whether you should enter "normal" mode, enabling the SoftDevice etc., or "test mode", where you don't enable the SoftDevice but run DTM code.

Br,

Einar

[beemavishnu]

Thank you for your inputs.

I did few experiments. Please find my further related queries.

1) When I load DTM hex file to nRF52840 and read memory content via nRFConnect I am seeing only MBR. If I drag the same hex file into “File memory layout” I am seeing both MBR and DTM Application.

a) Also MBR size is different in Flash read and when hex file dragged to “File memory layout”. Why is this ?

b) Because of this, I am not sure whether DTM application is loaded when I load DTM example via Segger.

      

2) I merged “Secure Serial Bootloader” and SoftDevice. Now I am trying to merge DTM hex file, Bootloader settings hex file (generated from DTM application) and already “merged hex “ (Secure bootloader + SoftDevice). But I am getting error “ERROR: The hex files cannot be merged since there are conflicts”.

a) In DTM example I am seeing FLASH_START=0x0. Do I need to change macros as below. Apart from these any other macros to be changed.

               

        FLASH_START=0x27000

        FLASH_SIZE=0xD1000                     // 0xF8000 – 0x27000 = 856064 = 836 * 1024

        

 https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Flib_bootloader.html&anchor=lib_bootloader_memory

3) To cross check, I compared with ble_app_blinky. I am seeing below configurations.

a) Why FLASH_SIZE=0xd9000 rather than 0xd1000

b) Why to change RAM address.

 

FLASH_START=0x27000

FLASH_SIZE=0xd9000

RAM_START=0x20002300

RAM_SIZE=0x3dd00

 

4) I merged “Secure Serial Bootloader” and SoftDevice. Instead of above step in 2, I generated DTM package. During this, I did not change any FLASH_SIZE (As is to Original DTM project) and other macros. But still I am able to generate package and able to do DFU.

a) While merging why error got generated but while package generation, why there is no such error.

 

Thanks & Regards

Vishnu Beema

[Einar Thorsrud]

Hi Vishnu,

I am sorry for the late reply due to the holiday season.

1a) This is just a matter of how nRF Connect interprets and shows the data. It does not know if the first page is an MBR or some other data. It is odd that nRF Connect Programmer handles this differently when reading flash and when displaying a .hex file, but it is just a matter of presentation. The DTM example .hex files do not include an MBR (or SoftDevice), so it is just an "application", even though nRF Connect does not know this. 

1b) Yes, it is loaded. This is not a problem.

2) You cannot merge the examples like this. When I previously wrote that you can include DTM in your application, this was not the approach I had in mind. You cannot merge incompatible .hex files like this. As the error says, merging cannot be done since they files conflict (overlaps). However, there is another much more important issue here, which is that they are incompatible in this way. You can build the DTM example like this, and jump to it from your application (or a bootloader) in the same way that the bootloader starts the application, or you can implement DTM in your application using the DTM libraries.

2a) If you want to place the DTM application in the flash together with the application and SoftDevice, you need to put it in a region which is not used by either the SoftDevice or application, by adjusting FLASH_START and FLASH_SIZE. But this leaves you with the issue that you need a way to start it. So this is more work (see above).

3a) The FLASH_SIZE is only important in some cases. If it is set incorrectly, this will only cause problems in two situations. Either if you set it too low, and the application doe snot fit, even though there is an actual room. Or you set it too high and the application is too large, then linking will succeed but it will not fit in the physical flash on the chip. In other cases, having an incorrect value does not matter.

3b) The RAM start and size typically doe snot depend on the other .hex files you flash, since only one of them will be executed at a time. The only exception si if you are using a SoftDevice or MBR, since then the RAM start must leave 8 bytes for the MBR, even if the SoftDevice is not enabled. (And if the SoftDevice is enabled, it is a different story altogether.)

4) I am not sure. It could be interesting to see the .hex files and command you used to knot the full answer. But DFU package generation generally doe snot check everything, unlike merging .hex files which is a very simple operation where almost the only thing that can go wrong is overlapping data.

Please note that we generally don't recomend using DTM in the production firmware. So before going further with this, I suggest you ask yourself why you do this? DTM is typically used when certifying and testing devices, but not commonly used for production tests etc. This is why we just provide an example that is to be used as-is without anything else. It is not intended from our side to be used in production firmware. But that said, it is possible if you really want to, as I outlined in my initial answer, but you need to adapt it yourself.

Br,

Einar

[beemavishnu]

Hello,

 

Thank you for your detailed explanation.

 

1) Let me give more inputs on our setup. DTM is used only for Factory testing. Once done, we will load our Production application and release to market.

1. 1. Yes, Initially I thought to load merged “Secure Serial Bootloader” + “SoftDevice + MBR” and then update DTM using DFU. Since we are yet to port nrfutil on to Android OS, for time being we want to merge even DTM application and load final hex file using nrfjprog. So first we load merged hex file with “Secure Serial Bootloader” + “SoftDevice + MBR” + DTM Application + “Bootloader settings page”. Once DTM is tested we will load our BLE application via DFU (Once nrfutil is ported on Android OS) so that DTM application will be replaced by our BLE application.
   2. Also our intention is not to keep both DTM and BLE applications at a time.

 2) Can you please let me know more details on you comment “if the SoftDevice is enabled, it is a different story altogether.”. As mentioned about we are keep MBR and SoftDevice. Anyway, SoftDevice is not enabled when DTM is executed.

3) On original DTM code as is, using below command I generated DTM package. So even FLAH macros are as is.

 nrfutil pkg generate --hw-version 52 --application-version 2 --application direct_test_mode_pca10056.hex --sd-req 0xCA --key-file CT40_private.key DTM_CT40_V2_package.zip

 

4) I did small experiment. I modified DTM code so that I can toggle LED3 on nRF52840 DK by sending UART format commands.

I compiled DTM example with below FLASH & RAM macros changed and merged as 1.a. With this I am able to do ON / OFF on LED3.

FLASH_START=0x27000

FLASH_SIZE=0xd9000

RAM_START=0x20002300

RAM_SIZE=0x3dd00

 

With same DTM code (LED changes) as is I reverted back FLASH & RAM macros as below. With this I generated DTM application package (.zip).

 

FLASH_START=0x0

FLASH_SIZE=0x100000

RAM_START=0x20000000

RAM_SIZE=0x40000

 

Using DFU, I am able to upgrade the package. DFU is success, but I am not able to toggle LED3.

 

a) My basic query is, why DFU is success in this case. DTM as part of package starts at Flash address 0. When doing DFU, should not writing Flash fail as at address 0, Flash is not erased and MBR resides.

 

b) Similar to ‘--verify’ option as part of nrfjprog, is there any similar verify option as part of nrfutil.

c) As part of DFU, how CRC and other sanity check are success even though we are overwriting / overlapping on top of MBR.

 

Thanks & Regards

Vishnu Beema

[Einar Thorsrud]

Hi Vishnu,

I see. So just to double-check, this is like this. 1) initially you program the DTM app for production test (1). After that, you upgrade to the "normal" application firmware via DFU (2). Is that correct, and with the memory layout as suggested in this drawing?

If so, then you are right. Then you subsequently reset and the bootloader enters DFU mode based on GPIO pin or other, and you update to the application, right? This should be straightforward. You just need to do the following changes to the DTM example application:

• Change the flash start address to locate it directly above the SoftDevice, at the exact same location your other application (they will not be on the device at the same time).
• Change the RAM start address to 0x20000008 (and reduce size correspondingly).

With these changes, the DTM app will run from the correct location.

Now for the questions:

2) The comment about adjusting RAM when the SoftDevice is enabled was just a generic comment, really. It is not relevant since it cannot be enabled while using DTM since that requires direct radio access. Nor is it relevant in this configuration.

4a) Apparently there is no check preventing the application from starting at page 0. This is a bit odd since the MBR is always located there. However, it should alow SoftDevices hex files that start there (conceptually), since it includes the MBR. The second point here is that for hex files (SoftDevices) page 0 is silently stripped away since the MBR is not overwritten. So that is what you see here as well. The first page of the DTM app is stripped away.

4b) No. There is a hash of the image in the DFU package, and DFU will only a success if the hash is verified. However, this is generated by nrfutil and if there is an issue with the generated image (as here), this will not help you. That is not something we have seen as an issue though since you should anyway test the image properly before providing it to customers. If you want to verify this during development, you should use a debugger before and after DFU and read the flash that way.

4c) Because the CRC is only calculated based on the data that is actually part of the image, and that does not include page 0, as explained above. So this is not a problem with the DFU or CRC checking per se.

Br,

Einar