Where is the MDBT40 *GATEWAY VERSION* firmware?


#1

Hello all.

By way of a, “why” I’m asking this … I have a problem on my gateway board where the PTS pin will just stop doing anything if I kill the power to or reset a BluzDK in the process of being connected to the cloud. I can replicate the problem very reliably. (Only a hardware reset fixes the problem, suggesting the MDBT40 [nrf51x, I presume] has crashed.)

So, I want to look into this myself. But try as I may, I cannot find the MDBT40 firmware employed on the gateway shieldas opposed to the BluzDK board’s firmware, of course. The latter is pretty hard to miss.

The firmware on the gateway board must be a different, because the slave SPI interface to the Photon master uses GPIOs 13 and 14 for MR and PTS signals (respectively), whereas the BluzDK uses GPIO 14 for the Flash SPI port and doesn’t appear to have any code to do with gateway functions, that I can find anyway.

There are gateway and gateway_develop branches. But those don’t appear to be what I’m looking for, rather just branches of the main BluzDK develop branch, far as I can see.

Help! :blush: and thanks in advance.

Regards,

Gruvin


#2

The gateway_develop branch is actually where the code is stored. Just as the same repository can target the Photon and the Core, we can target the gateway or the DK by using make command line arguments. Currently we build the two from two different branches, but these will soon merge and we will only have one branch for both.

The file you are probably interested in is here: https://github.com/bluzDK/bluzDK-firmware/blob/gateway_develop/platform/MCU/NRF51/SPARK_Firmware_Driver/src/spi_slave_stream.c as that is where the pins are controlled for sending data to the Photon.

So to create this issue, you have a DK that is connecting and while it is flashing green quickly, you kill the power to the DK? And that freezes the gateway? I will try and recreate this from my end, is there anything else I need to do? Or any specific timing you use (has to be done after X seconds; etc)?


#3

Thanks Eric! That helps immensely.

Correct. Here are some more comments on the timing of the power-off/reset of the connecting DK, to cause the problem …

Firstly, you’ll have to wait until about the 12th quick green flash – don’t count the slow flashes before that. The timing of that does not need to be precise. Just wait for 10 to 12 quick flashes, then kill the power on the DK.

On the serial debug window of the gateway’s Photon, that same timing seems to correlate with the second and longer burst of communications event. The ones that stream up the screen for a couple pages. It was from this and only this that I have thus far assumed that the fault happens during the cloud connect phase … though that’s likely completely coincidental and more likely because there’s a bunch more data packets happening back-to-back. Just guessing here, since I am not yet familiar with it all.

I wanted to see if I could find the cause before raising an issue as such, just in case it’s something peculiar to my set-up.

Note that the main loop of the gateway Photo keeps running. It’s just that the PTS pin never goes high again, to trigger an spi_retrieve().

Gruvin