DTM test procedure over Bootloader + SoftDevice

Question

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 · Accepted Answer

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

Einar Thorsrud · Answer

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

Einar Thorsrud · Answer

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

Einar Thorsrud · Answer

Hi Vishnu, 
 2a. Yes. 
 2b. This is because the first flash page (starting at address 0) is stripped away from the binary, since nrfutil assumes it is the MBR. So the DTM binary will not work if it is built to start ad address 0, even though DFU looks OK.

DTM test procedure over Bootloader + SoftDevice

Top Replies