Author Topic: Simblee - OTA programming?  (Read 5554 times)

spkilla

  • RFduino Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: Simblee - OTA programming?
« Reply #15 on: August 24, 2016, 05:56:13 PM »
One more thing to note. The nrf toolbox app doesnt require the simblee to be in dfu mode. It'll automatically put it into dfu then upload.

I haven't found that to work.
SELECT DEVICE
SCAN
nada!!!

What is the trick???

No idea actually.. could it be the simblee for mobile library that allows this to happen?

below is the testing environment i used
Code: [Select]
#include "ota_bootloader.h"
#include <SimbleeForMobile.h>

//screens
int toScreen2ButtonID;
int toScreen1ButtonID;
int currentScreen;
int screenxmax;
int screenymax;

void setup() {
  Serial.begin(9600);
  Serial.println("Setup beginning");
  SimbleeForMobile.deviceName = "ota test";
  SimbleeForMobile.advertisementData = "Sample";
  SimbleeForMobile.domain = "xtcmodz.com";
  SimbleeForMobile.begin();
  Serial.println("Setup completed");
}

void loop() {
  SimbleeForMobile.process(); 
}
void SimbleeForMobile_onConnect()
{
  currentScreen = -1;
}
void SimbleeForMobile_onDisconnect()
{
}
void ui()

 
  screenxmax = SimbleeForMobile.screenWidth;
  screenymax = SimbleeForMobile.screenHeight;
  Serial.printf("UI screen size: %dx%d", SimbleeForMobile.screenWidth, SimbleeForMobile.screenHeight);
  if(SimbleeForMobile.screen == currentScreen) return;
  currentScreen = SimbleeForMobile.screen;
  switch(SimbleeForMobile.screen)
  {
    case 1:
      createScreen1();
      break;
       
    case 2:
      createScreen2();
      break;
           
   default:
      Serial.print("ui: Uknown screen requested: ");
      Serial.println(SimbleeForMobile.screen);
  }
}
void ui_event(event_t &event)
{
  if(event.id == toScreen1ButtonID && event.type == EVENT_RELEASE && currentScreen == 2)
  {
    SimbleeForMobile.showScreen(1);
  } else if(event.id == toScreen2ButtonID && event.type == EVENT_RELEASE && currentScreen == 1)
  {
    SimbleeForMobile.showScreen(2);
  }
}
void createScreen1()
{
  SimbleeForMobile.beginScreen(YELLOW, PORTRAIT);
  int textID = SimbleeForMobile.drawText(80, 60, "Screen 1", BLACK, 40);
  toScreen2ButtonID = SimbleeForMobile.drawButton(100, 200, 100, "Screen 2");
  SimbleeForMobile.setEvents(toScreen2ButtonID, EVENT_RELEASE);
  SimbleeForMobile.endScreen();
}
void createScreen2()
{
  //
  // Default to Portrait orientation
  //
  SimbleeForMobile.beginScreen(WHITE);
  ota_bootloader_start();
  int textID = SimbleeForMobile.drawText((screenxmax/2), (0), "Screen 2", BLACK, 40);
  Serial.printf("xpos,ypos: %dx%d", screenxmax/4, screenymax/2);
  toScreen1ButtonID = SimbleeForMobile.drawButton(100, 200, 100, "Screen 1");

  SimbleeForMobile.setEvents(toScreen1ButtonID, EVENT_RELEASE);
  SimbleeForMobile.endScreen();
}
« Last Edit: August 24, 2016, 05:59:39 PM by tolson »

tolson

  • Global Moderator
  • *****
  • Posts: 812
  • Karma: +19/-0
    • View Profile
    • Thomas Olson Consulting
Re: Simblee - OTA programming?
« Reply #16 on: August 24, 2016, 06:10:43 PM »
Ah, it is because you start the OTA_bootloader service in your screen 2.


spkilla

  • RFduino Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: Simblee - OTA programming?
« Reply #17 on: August 24, 2016, 06:14:56 PM »
just commented it out it still allows ota without going into dfu. Im going to assume the simblee for mobile library allows that to happen.

tolson

  • Global Moderator
  • *****
  • Posts: 812
  • Karma: +19/-0
    • View Profile
    • Thomas Olson Consulting
Re: Simblee - OTA programming?
« Reply #18 on: August 24, 2016, 06:19:39 PM »
I changed all the SimbleeBLE to SimbleeForMobile and added a blank ui and ui_events function and added SimbleeForMobile.process in the loop(). No dice. Is your smart device bonded with your Simblee device, so it remembers certain info,,, I wonder.
What are your settings in nRF Tool /DFU Settings.
Keep bond Information ?
External MCU DFU ?

spkilla

  • RFduino Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: Simblee - OTA programming?
« Reply #19 on: August 24, 2016, 06:25:32 PM »
packet receipt notifications: enabled
number of packets: 10
MBR size: 4096
keep bond info: disabled
external MCU DFU: enabled

I did disable mcu dfu and it still automatically entered DFU.

tolson

  • Global Moderator
  • *****
  • Posts: 812
  • Karma: +19/-0
    • View Profile
    • Thomas Olson Consulting
Re: Simblee - OTA programming?
« Reply #20 on: August 24, 2016, 06:46:55 PM »
Yep, I had flipped all those toggle combinations with no joy!

Ah, I just realized. In my Blink_OTA sketch, I had not started SimbleBLE.begin(). So it is not a BLE device. Just an dumb app that can be OTA updated by providing a way for the app to start the DFU service. In this case the button_OTA.

It turns out that having SimbleeBLE.begin() or any of it's inheritances like SimbleeForMobile.begin() activates the DFU Service once a smart device connects.

I think I knew this was in the newer SoftDevices, but didn't know RFdigital activated it. Cool! Kind of.

All the more important reason to implement some kind of security negotiation in your apps to keep someone else coming along, connecting and uploading a bogus sketch. Hmm! Now I wonder if there is a way to turn off the service without turning off BLE!!!


« Last Edit: August 24, 2016, 06:50:25 PM by tolson »

tolson

  • Global Moderator
  • *****
  • Posts: 812
  • Karma: +19/-0
    • View Profile
    • Thomas Olson Consulting
Re: Simblee - OTA programming?
« Reply #21 on: August 24, 2016, 08:34:01 PM »
OK, so now, who has a good idea how big of a file we can upload using DFU.
Obiously it is going to be only half of available space without DFU. In other words if we had 128KB free for user program space, And half of that is needed to store the newly uploaded program before the loader replaces the old program. Then that would imply the programs can't be bigger than 64KB. So what is the real space available for user program space?

So those of us who have created huge complicated programs that uses most of the native user space, we can not ever use DFU as designed to replace our firmware. Right? In which case looks like a need for a separate remote control uploader for such applications. Too bad we can't tie on an external memory device for purposes of DFU uploads. Anyone got any ideas on how to hack that together.






wookie1

  • RFduino Jr. Member
  • **
  • Posts: 23
  • Karma: +0/-0
    • View Profile
Re: Simblee - OTA programming?
« Reply #22 on: September 08, 2016, 06:44:42 PM »
How would you prevent other devices from connecting? Can't they just discover services and characteristics and be connected without further interaction? Since no real interaction is necessary to start DFU, how would you stop it? Is there any way to disable the auto-DFU enabling? I set up a command that when received by Simblee calls the OTA start, but I guess that's ignored then.

danlsk

  • RFduino Jr. Member
  • **
  • Posts: 30
  • Karma: +0/-0
    • View Profile
Re: Simblee - OTA programming?
« Reply #23 on: November 03, 2016, 02:59:39 AM »
I tried using the IOS NRF Toolbox and no Simblee App that connects to the device. I cannot upload the application .hex. It got stuck at Enabling DFU Bootloader....

wookie1

  • RFduino Jr. Member
  • **
  • Posts: 23
  • Karma: +0/-0
    • View Profile
Re: Simblee - OTA programming?
« Reply #24 on: November 22, 2016, 06:56:22 PM »
So if I read this right, there is no way to prevent someone from just writing another program on the Simblee device as long as Bluetooth is active? This is a pretty bad situation if that's true!

stephenf7072

  • RFduino Newbie
  • *
  • Posts: 5
  • Karma: +0/-0
    • View Profile
Re: Simblee - OTA programming?
« Reply #25 on: January 04, 2017, 01:11:48 AM »
Hi all, thanks a bunch for this post - it helped me a lot and I got my custom Arduino Simblee doing OTA programming from Android, and also using flash memory for user data retention.

I wrote the below idiots step-by-step guide, mostly paraphrasing tolson's wisdom.  I figured it's worth posting because the more information out there on this, the better.  Yep, I even registered an account just to post it.

I also did some trial and error on sketch sizes (44% is about the limit) and how they are dealt with in OTA programming, which is at the end.

Cheers,
Steve

Simblee OTA using Android  (step by step):

To set up for it:
0.     I'm running Windows 10 on PC
1.   Install Python 2.7 (NOT 3)
2.   Install packages to make it work, ie.:
a.   Py2
b.   Microsoft Visual C++ v9.0 (per link in error message)
c.   The latest version of nrfutil (0.5.2) that still works with Simblee, from https://github.com/NordicSemiconductor/pc-nrfutil/tree/0_5_2
d.   DON'T JUST AUTOMATICALLY INSTALL THE LATEST NRFUTIL VERSION - it won't work
e.   install with "python setup.py install" (may need to be in the same folder or put in paths)
f.   may need to move the "nordicsemi" folder to the right place
3.   Install on android phone "nRF toolbox" app
4.   Make sure the code in the Simblee has functionality for OTA (and if you upload via USB cable, you should see the main and the ota memory banks get written).

To do it:
1.   Compile (Ctrl-R) the sketch in Arduino IDE or whatever you like
2.   Check size of sketch is ok - ie. 33% works, 44% seems not to
3.   Find the resulting hex file - should be at C:\Users\<your name>\AppData\Local\Temp, and called "ElkLight_V_rev0_4_trimmed.ino.hex" or similar
4.   Copy this to C:\Python27\Scripts
5.   Run command line and navigate to C:\Python27\Scripts
6.   Paste nrfutil dfu genpkg SFlightSmall.zip --application ELtesting.hex --application-version 0xffff --dev-revision 0xffff --dev-type 0xffff --sd-req 0xfffe
7.   (SFlightSmall.zip is the name of the output file that goes to the smartphone)
8.   Copy the created zip file (ie. SFlightSmall.zip) to your phone memory somehow (Dropbox is easy, and works very well)
9.   Ensure bluetooth is enabled on the Simblee (DOESN'T have to be in FWU or whatever, just normal mode)
10.   On Android smartphone, run the "nRF Toolbox" app and select DFU
11.   Select file, and browse to the zip file  ("select Distribution packet (ZIP)") - you should be returned to the DFU (Device Firmware Update) screen and your selected file name should be shown.
12.   Hit "Select Device" and scan if necessary, your Simblee should come up under "Available Devices" (NOT "bonded devices").  Even if it's already selected, this is just remembered from last time - it's worth selecting again so you know for sure bluetooth is activated
13.   Select the Simblee, and the you will be returned to the DFU screen - your Simblee name should show at the top and the "Upload" button is no longer greyed out.
14.   Hit the "Upload" Button
15.   You should see a bit of stuff happen in the status bar, and then an uploading % sequency go from 0 to 100%.  This took about 30sec for me, and then there's a success message.
16.   Try to avoid the phone screen going off - it goes a bit weird sometimes
17.   The Simblee should reset and be running the new firmware straight away.

Other notes:
1.   If you are writing user data to flash (ie. as you would for EEPROM in regular Arduino) then you are likely using page 251 per the examples.  This will screw up your OTA programming.

Thanks to Tim's post at http://forum.rfduino.com/index.php?topic=1347.0:
I've done some investigation and found that sketches and SimbleeBLE are written to flash starting at page 124, and the OTA boot loader occupies pages 240-251. That leaves pages in between for writing application data.

I used page 237 for successful implementation of both OTA and flash memory writing.  Tested for preservation of data between resets/power cycles, but doesn't preserve data between programming.

Other values I tried (and results):
230,235,237 - preserve data across resets, and allow OTA to work
250, 251 - preserve data across resets, but prevents OTA from working
238,239 - allows OTA to work, but doesn't preserve data across resets
240 - stops the whole thing running when it's written to!

2.   Size of sketch for OTA.  By trial and error, I determined the maximum allowable size for OTA to still work is about 59kB (that's the zip file size - about 44% of memory by the by Arduino IDE). 
"Sketch uses 59,272 bytes (45%) of program storage space. Maximum is 131,072 bytes.
Global variables use 4,492 bytes of dynamic memory."
You don't get any error messages if you go slightly higher, and you can still program by USB cable just fine - the OTA will just quietly not work, and drive you mad.  I didn't test this with using flash memory for user data, so it's probably a bit less in this case.

Tim

  • RFduino Sr. Member
  • ****
  • Posts: 106
  • Karma: +2/-0
    • View Profile
Re: Simblee - OTA programming?
« Reply #26 on: January 04, 2017, 05:43:13 PM »
This is very helpful Stephen. Thank you.

Just yesterday I got the following to work (I'm on Mac OS 10.11.6):

- Successful installation of nrfutil (0.5.2) and generation of .zip for my sketch .hex file.

- Successful integration of Nordic's iOSDFULibrary using the Cocoapods method (see documentation here: https://github.com/NordicSemiconductor/IOS-Pods-DFU-Library/blob/master/documentation.md).

- Connect to Simblee advertising in BLE mode, then perform OTA sketch update by calling DFUServiceInitiator.start().

Our app does store user-defined data in flash and currently uses page 203 (user-defined data is erased during OTA). I will try pages 230, 235, or 237. It will be very helpful if user-defined data is not erased during OTA.

Cheers,

Tim

massimoX

  • RFduino Newbie
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: Simblee - OTA programming?
« Reply #27 on: January 20, 2017, 11:14:31 PM »
Thanks Stephen, working for mw as well (Mac OS 10.12.2, nrfutil 0.5.2)
I'm working at integrating Simblee on my own PCB and I need to decide wether to incorporate UST to serial UART interface, or leaving only the PIN used for serial programming or having nothing thus relying completely on OTA programming.
Do you know if Simblee is shipped with BLE off and if there is a way to wake it up and trigger OTA programming, via BLE?
Thanks

stephenf7072

  • RFduino Newbie
  • *
  • Posts: 5
  • Karma: +0/-0
    • View Profile
Re: Simblee - OTA programming?
« Reply #28 on: January 21, 2017, 12:08:44 AM »
Hi Massimo,
I can confirm that the Simblee chips (at least the 20 or so I've got from Mouser) come with BLE off, and I don't know of any way to turn it on until you upload something via UART.  Might be something hidden in the documentation, but I doubt it.

At least for my continued prototyping I'm inclined towards buying chips on breakout boards, so they can be programmed, removed and soldered onto my boards.  Although that's because soldering them by hand (even with tiny amounts of solderpaste and a temperature-controlled heat gun) is such a ridiculous nightmare and it makes debugging a whole lot easier if there's already a program in there.  Maybe I'm not being careful enough, but they seem to get wrecked very easily and I have a dismaying pile of dead ones - probably because my SMD soldering gun was slightly too hot.

I think having no backup UART connection is a scary idea as the board is then stuffed if you accidentally mess up the firmware, or the BLE firmware update bricks it.

I'm curious how you or anyone else has found the process of installing a Simblee chip - not sure if I'm just being bad at it...

Cheers,
Stephen

nicolas.ehrenberg

  • RFduino Newbie
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: Simblee - OTA programming?
« Reply #29 on: January 24, 2017, 06:08:24 AM »
Thanks a lot for the guide Stephen, that really helped out.

I was able to upload a sketch my Simblee board using ota_bootloader.h and ota_bootloader_start(). However it doesn't seem to be compatible with SimbleeCom which is necessary in my application. As soon as I include ota_bootloader_start(), the  SimbleeCOM.send function doesn't work anymore.

Does anybody know a way around this problem?

I tried using the Simblee BLE library and the SimbleeBLE_onDualModeStart() function with no success.

Cheers,
Nick