nRF52840 connection to load MCUBoot+Zephyr

[Claudio Rosa]

I am having problems in the JLink connection for nRF52840(RAK4631) to load MCUBoot+Zephyr application.  In the RAK4631 RAKWireless bootloader, it is loaded using nrfutil by usb serial connection, for example "nrfutil.exe dfu serial -pkg rak4631_factory_bootloader.zip -p COM5", then I don´t have to have a JLink for every flash operation.

I have a nRF52840DK what there we have a JLink-OB, but for production environment it will be expensive for thousands devices, each one with his own JLink-OB.  Is it possible to load a merged.hex without by USB instead of JLink?

Regards,

Claudio

[Einar Thorsrud]

Hi,

I have a nRF52840DK what there we have a JLink-OB, but for production environment it will be expensive for thousands devices, each one with his own JLink-OB.

You do not need a JLink-OB in the end product, but you need J-Link or other SWD programmers on the production line. Then you flash the device with what you need directly. The only thing you need to do on your hardware for supporting this is routing out the SWD lines so that you can hook up to it on the production line.

[Claudio Rosa]

Could I do it using the "nrfutil.exe dfu serial -pkg rak4631_factory_bootloader.zip -p COM5" ?  I mean work with serial port to flash a merge file (MCUBoot+Zephyr).

[Einar Thorsrud]

I do not know what rak4631_factory_bootloader contains or the details of what the RAK4631 contains. But as you use nrfutil like this it includes the nRF5 SDK serial bootlaoder that may have modifications of some sort? It will not be possible in any way to remove the MBR with a DFU operation. It may be possible to remove the bootloader in an unsafe operation. You can read more about it here.

But I am curious about the context. Is this a product in your production line? Why do you not program it via a SWD programmer then? If not, you will have to maintain a combinatino of legacy nRF5 SDK comonents and nRF Connet SDK components, and I wonder what the benefits of this approach is?

[Claudio Rosa]

Let me explain better.  I will replace rak4631_factory_bootloade by merge file merged.hex(MCUBoot+Zephyr).  

[Claudio Rosa]

Let me clarify, I already tried to flash RAK4631(nRF52840) by VSCode/nRF Connect/Jlink, and nRF Connect for Desktop  v5.0.2 Programmer,  as you can see in the images below. 

In the screenshot below you can see as "connected devices":

1. The nRF52840-DK, it is working fine
2. The RAK4631 isn´t being reconized as a nRF52840.  

Well, below I attached the connection schema that I am using to connect the RAK4631 with the JLink, but I think that I have a problem between JLink and RAK4631, but I don´t know what.

Maybe I will need to rewrite the MBR, but I don´t know how.

In the Zephyr documentation  for my supported board RAK4631, I found:

1. Connect the RAK4631 board to your host computer using the USB debug port. Then build and flash the Hello World application.

   # From the root of the zephyr repository
   west build -b rak4631/nrf52840 samples/hello_world
   west flash
   

   You should see “Hello World! rak4631_nrf52840” in your terminal.

Could you help me?

Claudio

[Claudio Rosa]

The entire environment is:

1. RAK4631: a Zephyr supported solution with a Nordic nRF52840 + Semtech LoRa Radio SX1262.
2. RAK19007 : a mother board for:
   1. RAK4631
   2. RAK1904: LIS3DH accelerometer
   3. RAK1906: a Bosh BME680 environmento sensors
   4. RAK5801: a 4-20mA sensor + a pressure transducer
   5. RAK12500: GNSS ublox ZOE-M8
   6. RAK15007: Infiniion SPI FRAM 1MByte
   7. RAK15002: SD card reader

The solution will be applied in a wagon in a train in the Railroad Company in Brazil, with 19000 wagons.

Claudio 

[Einar Thorsrud]

Hi,

As you have a debugger you can erase everyting on the module so you do not need to think about what wast there before. But is the problem here that you are unanablet to debug? If you can back-track a bit and explain from a high level what you want to achieve that would be good.

That said, assumign the problem is that you are not ble to program via the J-Link, I suggest you start with a recover operation. Make sure you have the latest nRF Command Line tools, and use "nrfjprog --recover". This will open the debug port in case it was locked down by AP protect before. It will also erase the flash content during that operation. Does that work? And are you able pto program the device with what you want after that?

[Claudio Rosa]

thank you by ypur sppoert.

Cludio