Having trouble re-flashing a preloaded nRF52 module (MDBT42Q)

[mydadisaplumber]

I started developing on the Adafruit nRF52 module.  I wanted to make a custom PCB to demonstrate a prototype and fabricated a board with a MDBT42Q module from Raytac.  I sent them my .hex file output from the Arduino compiler and they preloaded it with it.  Everything works great, exactly how it did on the Adafruit module.  Here's what nRFgo says about it:

However, when I try to upload a new sketch using the J-Link Segger through either the Arduino IDE or nRFgo, the chip never responds again.  The upload and verification works absolutely fine, but the chip never even shows life for a simple blink function.  If I swap out my custom PCB with the Adafruit board and upload with the J-Link, it works fine though.  When I plug my custom PCB into Ozone, it looks like no instructions ever get executed, it's really weird.

I've also tried burning the Adafruit boatloader (which of course works with their module).  After that, both my custom PCB and the Adafruit module give this output in nRFgo:

So I would think they would both work, but again, the Adafruit module does, but the custom PCB with the MDBT42Q never seems to get started up.  What's going on here?  Could it be the module from Raytac?  Is there a better source for nRF52 modules that I want to put on my own custom PCBs and reprogram?

[Einar Thorsrud]

Hi, 

started developing on the Adafruit nRF52 module.  I wanted to make a custom PCB to demonstrate a prototype and fabricated a board with a MDBT42Q module from Raytac.  I sent them my .hex file output from the Arduino compiler and they preloaded it with it.  Everything works great, exactly how it did on the Adafruit module.  Here's what nRFgo says about it:

However, when I try to upload a new sketch using the J-Link Segger through either the Arduino IDE or nRFgo, the chip never responds again.  The upload and verification work absolutely fine, but the chip never even shows life for a simple blink function.  If I swap out my custom PCB with the Adafruit board and upload it with the J-Link, it works fine though.  When I plug my custom PCB into Ozone, it looks like no instructions ever get executed, it's really weird.

This seems odd. It would be good to start by deciding if this is a programming issue or an issue with your .hex file. You write that it works with the pre-programmed .hex, but not if you program a .hex file yourself. What happens if you re-program with exactly the same .hex file as was used before, does it work then, or does it not? And is there a difference if you re-program with sector erase or do a full chip erase before you program?

So I would think they would both work, but again, the Adafruit module does, but the custom PCB with the MDBT42Q never seems to get started up.  What's going on here?  Could it be the module from Raytac?  Is there a better source for nRF52 modules that I want to put on my own custom PCBs and reprogram?

Which chip variants are on the  Adafruit nRF52 module and on the MDBT42Q? Is it the same, or are they different with regards to flash or RAM size? Another important question is if one has the optional 32 kHz crystal and the other does not. If your firmware tries to start the crystal and it is not there, it will not work. For instance, sd_softdevice_enable() will never return if it is configured to start the 32 kHz crystal and it is not present on the HW. In that case, you need to change the SoftDevice configuration to use the internal RC (LFRC) instead.

[mydadisaplumber]

Hi Einar, thanks for the response.  That was a good idea, I went back and tried to use nRFgo to upload the HEX file I had sent Raytac to preload it with.  At first it said I needed to either erase all, or change the SoftDevice because that HEX file included the SoftDevice.  I erased all, and then uploaded the HEX file...and everything works!  It's back to the way it was before.

Raytac had given me an app from them called "mergehex" which combined my HEX output from the Arduino compile with their "s132_nrf52_2.0.0_softdevice.hex" file to make an output HEX, which is what I used for the original pre-loaded firmware.  I originally did that over a year ago.  But now, if I merge my HEX that I compiled today using Adafruit's updated nRF52 library with that same SoftDevice Raytac gave me, and upload that using nRFgo (after erasing all), I get nothing again, no response from the chip.  Programming the year old one brings it back again.

To be honest, I'm a little fuzzy on my definitions of SoftDevice vs. DFU, so I'd appreciate a little bit of a description of what could be going on behind the scenes.  Could Raytac's module only work with their custom SoftDevice?  Do I maybe need a new SoftDevice from Raytac that keeps up with the Adafruit developments?

My PCB has a 32.768 kHz oscillator with the same circuitry going to the same pins as the Adafruit board, so I don't think that would be the problem.

[Einar Thorsrud]

Hi,

mydadisaplumber said:

I erased all, and then uploaded the HEX file...and everything works!  It's back to the way it was before.

Good. Then we know this is not a problem with programming itself.

mydadisaplumber said:

Raytac had given me an app from them called "mergehex" which combined my HEX output from the Arduino compile with their "s132_nrf52_2.0.0_softdevice.hex" file to make an output HEX, which is what I used for the original pre-loaded firmware.

That makes sense. mergehex is a tool we supply (part of nRF Command Line Tools), and it is useful to use it to combine the SoftDevice .hex file and application .hex file into a single .hex file that can be used in production. If you don't merge the SoftDevice .hex and application .hex you have to program them separately. The end result will be the same, but it is probably not so good for production, and you must remember to program the SoftDevice.

mydadisaplumber said:

Adafruit's updated nRF52 library with that same SoftDevice Raytac gave me, and upload that using nRFgo (after erasing all), I get nothing again, no response from the chip.  Programming the year old one brings it back again.

I do not have experience with Arduino or Adafruits nRF52 library. It might be better to check with Adafruit (or their forum) for issues specifically with that. In fact, it seems like there is a problem with your application or the Arduino port, and that this is not a problem with flashing. Have you debugged the application instead of just programming and hoping it will work? What happens if you debug? I think this is the key. You need to debug the application to figure out why it is not working. Without doing that, we will just have to guess (and that may take a very long time).

mydadisaplumber said:

To be honest, I'm a little fuzzy on my definitions of SoftDevice vs. DFU, so I'd appreciate a little bit of a description of what could be going on behind the scenes

The SoftDevice is the BLE stack provided by Nordic. It has to reside in the beginning of the flash for applications that use it. The bootloader is used for DFU. Since you don't know what it is and it is not present in the first screenshot of nRFgo Studio in the original case, it seems you do not use a bootloader. So then the question is why you programmed a bootloader after? I don't know how the Adafruit bootloader woks, but bootloaders tend to be complex so you should definitely know about it before you use it. It may very well be that the bootloader never starts the application. So the first thing to do is probably to get rid of the bootloader (if you need it you can always put it back later, but then you need to understand it).

mydadisaplumber said:

My PCB has a 32.768 kHz oscillator with the same circuitry going to the same pins as the Adafruit board, so I don't think that would be the problem.

I see. Then this is not relevant.

[mydadisaplumber]

I ended up figuring it out.  When I clicked "Burn bootloader" from the Arduino IDE, it would write both the SoftDevice AND a bootloader, and my board wouldn't work.  If I erased everything through nRFgo, manually wrote the 6.0 or 6.1.1 SoftDevice, and then manually wrote the .hex file for the application, everything works fine.

Last question though, how do the OTA updates work?  Can you write new application data wirelessly through a custom smartphone app?  Or can you only write new SoftDevice data?

[Einar Thorsrud]

I am glad to hear you made it work.

mydadisaplumber said:

Last question though, how do the OTA updates work?  Can you write new application data wirelessly through a custom smartphone app?  Or can you only write new SoftDevice data?

It depends on the bootloader you are using. If you are using the bootloader from the nRF5 SDK, this can be used to replace everything: The application, the SoftDevice and even the bootloader itself. You use it together with a application on the BLE central (phone, PC or similar), and that will act as a DFU master and transfer the update image to the bootloader. Then the bootloader will validate the image, and program it if everything is OK. See SDK bootloader example and bootloader modules documentation for details.