System-part upgrade troubles


#1

So, I’ve been trying to use my CHIP as a gateway primarily, but I’m running into an issue with upgrading to the newer system firmware (aka, flash with build against 1.1.47, go into safe mode, download the upgrade). It seems like the first part is going fine, however with the second part (after the Bluz reboots), the cloud sends down the 530 byte packet, then there are two upstream 18 byte packets, and that goes back and forth several times (not the same number every time), and then the cloud sends the 530, but then the Bluz takes quite a long time to respond (~30 seconds or so?), before sending one 18 response, waiting a little while longer, and then sending the other 18 response. The cloud doesn’t respond, and eventually the Bluz seems to timeout, and disconnect (and then reconnect, starting the process all over).

I’ve been able to successfully upgrade the system with the Android app (though it doesn’t work every time), though unfortunately I don’t have the logs for that. I’m wondering if it’s potentially choking on the data coming too fast, as I know the Node gateway code in general goes a lot faster than the Android code. Any ideas?


#2

There shouldn’t be any speed issues, the updating system is 1-for-1 DATA-ACK, so bluz gets a chunk of data and only ACKs back when the data is saved and it is ready for the next one.

I have been hearing random reports of trouble upgrading, and it usually seems linked to the Android app. I am wondering if perhaps it has to do with packets per connection interval. I know Android can handle 7 packets per connection interval (which is the max) and supposedly the nrf51 should be able to handle this just fine. But I am starting to suspect that perhaps it gets a little ahead of itself.

With iOS, it only support up to 6 packets per connection interval. I have no idea what the CHIP does, but maybe it is the same.

Did you happen to try it on the Pi 3? Any difference?


#3

I didn’t get a chance to try it on the Pi before I had upgraded all the DKs. Is there a way to force it to trigger the system upgrade again?

Edit: I found this potentially relevant item on the nordic forums: which says the nrf51 can handle 6 packets/interval

Edit 2: After thinking for a bit, I realized I could just flash the system-part via the particle cli. That had the same issue on the Pi


#4

Well, I modified the gateway code to do a 5ms block (which is quite the no-no in NodeJS…) after each write to the DK, and have been quite successful with that so far, so it looks like it might be a too fast issue somehow. It is still a fair bit faster than the Android gateway at least.


#5

One item to note, the stack can cause differences in how to handle the sending of data.

So in Android, the send command (actually writeCharacteristic) just sort of queues the data to be sent and doesn’t actually wait for it to be sent. So we have to listen for an event to make sure it is done before we send the next packet. You can see that here: https://github.com/bluzDK/android-app/blob/master/app/src/main/java/com/banc/BLEManagement/BLEManager.java#L527

On the other hand, iOS the send command does this all for us and doesn’t return until the packet is written.

So for the Linux drivers for BLE, which is blueZ I believe, I am not sure how it works and what it does. My guess, though, is that this isn’t the issue. In Android, for example, if we remove the wait then we can’t even get the handshake to work as it hangs pretty quickly. May be worth checking out though.


#6

@mumblepins, can you elaborate on “I could just flash the system-part via the particle cli?” I’ve got a Bluz DK that won’t update (always magenta) and need to do something similar, but had trouble getting cross compiling going. Did you find some binaries somewhere? Does the flash with CLI use the serial interface on the Bluz DK?


#7

In general you flash it in a similar way as the Particle Photon, though the gateway does sometimes add a bit of complication to the mix. For building on Windows, check out this thread on the Particle community, and git clone the Bluz firmware fork as opposed to the Particle firmware. Linux is much more straightforward, as you can easily get the ARM GCC compiler package. Building, you’ll pretty much always get an error regarding the “develop” branch, so use this. Flashing was done via the Particle CLI, with “particle flash BluzName system-part1.bin”


#8

You may be right about the problem. Working on a fix, but this:

is not making things easier right now :frowning2: