Programming MDBT40 through SWD, firmware and loading


Hi all!

I have built a custom Bluz gateway PCB using the all the tips in the docs, etc. I am able to get the particle device IC programmed, and am now working on getting the MDBT40 + nrf module loaded. I have one of those ( in order to program it.

I can’t seem to find the Bluz firmware for loading though. Is it on github? I also have nRFgo Studio in order to load it.

What is the best way for me to go about doing this? What all do need loaded?

Thanks a ton!

  • Keith


The device will need to get provisioned on the cloud and updated with keys in order to work properly. We have a private GitHub repo setup with instructions and the files you need, if you send me your GitHub username I can get you access to it.

It is pretty straight forward, we use a third party library and then you need only a few commands to get everything up and running.



I was able to get the nrf programmed through my stlinkv2 using the instructions, through the adalink programming. After getting the P1 connected and updated with the software through the Particle IIDE, the RGB led for it connects to the cloud for a moment and always goes back to breathing green (wifi connected but no cloud connection). There’s also no action from the NRF D7 led.

Any ideas?


If the LED on D7 of the nrf doesn’t blink once when it is powered on, then it probably isn’t properly loaded with firmware. Can you send me the adalink command you used to program the nrf?

If it does blink once when powered on, but then doesn’t blink after the P1 connects, it could be a problem with the connections or with the P1 having the wrong code. That may require some further investigation if you are trying to run this on a custom board.

Does the LED on D7 of the nrf blink once when it is powered on?


The D7 led doesn’t blink at all. The P1 connects and I can load an app from the Particle IDE and the RGB stays breathing cyan. If I load the gateway app though, it turns greens. Probably because the NRF is not configured properly yet?

I first built the firmware from the other git with make PLATFORM=bluz PARTICLE_DEVELOP=1
(I guess I don’t need this for the gateway?)

I used my ST link programmer and used adalink nrf51822 --programmer stlink --program-hex gateway/s120_nrf51_2.0.0_softdevice.hex --program-hex gateway/fw-0.1.5/gw-shield_fw.hex

from the bluz-beta-master folder I have on my desktop. All the environment variables seem to be setup correctly too. When I used the adalink comment to flash, it waits a few seconds and then gives me that error the git reminds you of (flash will be erased), and then doesn’t say anything else. Should it?

Thanks for help!


Ok, so it looks like the nrf isn’t getting the proper firmware files, that is why it isn’t working.

When building for the gateway, you should use this command:


Bluz and the gateway are two different products with two different firmware paths, so you need to specify the correct version when compiling.

There are 4 files that need to be flashed down in the adalink command. You can read up more here to see the 4 parts and what they do:

You can take all 4 of these parts from the gateway/gateway_programmer folder on the beta repository I had sent you. You should not take firmware from the fw-0.1.X folders, those are very old beta versions.

When you build locally, you are building the system part and the user part. The S120 SoftDevice is provided pre-compiled from Nordic, so that never changes. You can get the latest bootloader from the beta repo under the directory I mentioned above.

Let me know i you have any more questions or issues.


So I’m a little lost here.
What I’ve doing is this:

  1. make PLATFORM=bluz-gw PARTICLE_DEVELOP=1 using that command from the bluzdk-firmware-develop/modules/bluz-gw folder. It is giving me some errors though but runs through a bunch of compiling.
    Not sure what to do with this…
  2. I navigate to the bluz-beta-master/gateway/gateway_programmer folder and use this coommand adalink nrf51822 --programmer stlink --program-hex s120/s120_softdevice.hex --program-hex production_fw/bluz_gateway.hex and it seems too flash.

What do I need to do next? Does the bootloader need to be flash? Would I follow this?


You don’t have to compile the firmware locally, you can simply use the one in the beta repository.

So, you don’t need to do step 1, and you need to add more to step 2. The command should be:

adalink nrf51822 --programmer stlink --program-hex s120/s120_softdevice.hex --program-hex production_fw/bluz_gateway.hex --program-hex production_fw/bootloader.hex --program-hex production_fw/system-part1.hex

As I mentioned, there are 4 parts to the firmware, all of them need to be flashed down at the same time when using the STLink. That command above will do that for you.


I was pretty sure that was how to do it, thanks for writing out the command. That flashes but I still see no activity from the D7 led. Should something happen at this point?

But the led blinks quickly once if I click the bluetooth reset button now. This didn’t happened before. That’s the only time it blinks.


If you are seeing the D7 LED blink once when the board is powered on or reset, then it sounds like the nrf has the correct code.

If it doesn’t blink after that, it is likely that either the P1 has the wrong code or the connections between the nrf and P1 are wrong.

When you made the custom board, did you keep all pins between them the same? Or did you make any changes?

Is this a hand soldered board? Are you sure that all the pins on the P1 and nrf are properly soldered to the board? You may want to test them to make sure.

It sounds like the P1 probably has the correct code, but you may also want to verify that again. If you have another gateway or gateway shield, then it would be good to test out all your code/programming steps there and make sure it works, just to have a sanity check.


It’s not a hand soldered board, it was manufactured, and the connections seem to be correct.

The P1 connected pretty easily but I never uploaded any firmware locally. It doesn’t talk about loading firmware on the P1 (besides the gateway library/code from the IDE), so I wasn’t sure.

Could it be I just haven’t setup the P1 correctly?

Whenever I upload the bluz_gateway library stuff from the IDE, the P1 led ends up breathing green affter connected cyan for a few seconds.


It sounds like the P1 isn’t setup properly. Do you have a Photon you can also flash the code to in order to make sure it is working properly? Breathing green, I believe, means it is connected to WiFi but not the cloud.

What version of firmware is the P1 running?


I have a Bluz gateway wiith a normal Photon connected and it works fine. Same code uploading using the version 0.6.1.

No go on the board though. Could a problem with the NRF cause the P1 to go green? If not it has to be a software issue?


It could be a hardware issue, if the connections between the two aren’t correct there could potentially be situations where the P1 could hang.

I would double check the connections between the P1 and nrf, if there is something off there it would easily cause problems. Measuring them would be best, if possible.


So I got back around to work on this one too, and made sure that all the connections are correct for the P1. I’ve done it accoordiing to the P1 gateway schematic, not the Photon.

Are there any changes I need to make in the Bluz_Gateway library before uploading to the P1?

I was able to get the D7 led on the NRF to start blinking white actually as well. But the P1 still goes breathing green.


Well, I have good news and bad news on this one. The good news is, I know what the issue is. The bad news is that it has to do with the hardware design files online. The schematic diagram on GitHub was old and is missing a connection from the nrf51 to the P1. I am really sorry about that, it just never got updated during the final rev.

I have updated the schematic, you can see the new one here:

That shows the SA pin which was missing from the earlier design file. I am not sure how flexible your layout is and if you could connect that pin to your board somehow, but it is necessary for the firmware to work. Sorry again for the inconvenience from our side.


That OK, I understand. It’s not going to be too much trouble to get the traces remade.

What does pin SA do for the NRF? Before I got the board made I must have found something in the datasheet, can’t remember where exactly, but I found where SA is connected to pin 49 on the P1, rather than 50 like in the .pdf. So I have this connected to 49, but the problem is I don’t have access to 50 since the copper is underneath. Is this one correct though?

I also noticed the TXCONF and STATUS pins are switched around.

Is there anyway I can check the code to see what’s going on with the pins?


The pins on the nrf51 are defined here:

The pins on the P1 are defined here:

We currently don’t use the Bluetooth Compatibility pins (TXCONF, STATUS, etc). They are used, theoretically, to minimize the two radios transmitting at the same time. It was a nicety, so the hardware is there to support it and we hoped to turn it on in software some day. It would be good to match that, but it isn’t 100% necessary



So I think I can get around not having to change the board if I change the pins on the nrf firmware in the spi_slave_stream.h file. I’ll need to change the SS and SA pins.

Can I recompile the whole program easily if I do that? What would be the best way? I’m not sure which files I will need in total. Thanks again!


Yup, just compile like this:

make PARTICLE_DEVELOP=1 PLATFORM=bluz_gw APP=bluz_gateway

That will give you the system part and user part that you can flash down. You can read more about the different parts of out firmware here: