I want to do firmware update over the air with BLE113 module. I am using Nordic's nRF Toolbox to test this and I have configured their GATT services and characteristics in BGScript to do OTA update. But OTA updates are not always successful.
I deduce that, according to Nordic there are different file types of file that can be used to upload for OTA update process, which are,
Distribution Packet(ZIP)
Soft Device
Bootloader
Application.
At present I use 'Application' which means I select a bin file and upload with nRF Toolbox app from Android mobile. But this method is mostly unsuccessful (success rate is nearly 10% only). Can anyone suggest me a reliable way to do this? Has file type got to do anything with reliable OTA update process?
EDIT :
I am using a custom made board. I am not sure with antenna, Anyway I shall check this. And I always keep optimum power level. But nRF Toolbox (or I have come up with my own app using Nordic's OTA firmware update library) always shows 'successfully transferred' when I do OTA update and firmware is not updated most of the times.
It looks like you're trying to update a Bluegiga BLE 113 with Nordic's toolbox? That can't work.
Nordic and Bluegiga (now Silicon Labs) have different ways to perform firmware updates over the air, and they're not compatible.
I have a sample iOS app which will let you OTA from an iOS device to the BLE113 (assuming your firmware supports it): https://github.com/RobotPajamas/ble113-ota-ios
Here is a longer explanation of the BLE113 over the air update process: http://www.sureshjoshi.com/embedded/ble113-ota-over-the-air-programming/
Related
I've built the custom_gattsvc_app and updated it into my movesense sensor through DFU in AndroidSampleApp. Now I am not anymore able to connect to the sensor. The sensor can be found by AndroidSampleApp as well as NRF Connect, but connecting does not work.
The sensor itself blinks in short intervals, perhaps it is in reset loop? I don't have a programming jig, so I can't even update it anymore (Cannot connect -> cannot update). I am using version 1.9.1. I've tested other example apps, such as hello_world_app and ble_std_services, and they have worked just fine.
Is there a known problem here?
Building done with following commands:
cmake -G Ninja -DMOVESENSE_CORE_LIBRARY=../MovesenseCoreLib/ -DCMAKE_TOOLCHAIN_FILE=../MovesenseCoreLib/toolchain/gcc-nrf52.cmake ../samples/custom_gattsvc_app
ninja dfupkg
The device might be crashing and trying to restart continuously. If you are not blinking the led and have turned off the BLE advertising in your code.
You should be able to recover by taking out the battery, short the two contacts with your finger(dip your finger in water if you have dry skin) and insert the battery, release the contacts immediately when the led starts to flash.
Your sensor should no be in DFU mode(led constantly on) and ready to update firmware. You can use the "nRF Toolbox" app(from the producer of the Bluetooth chip used in the Movesense device) to upload a new build of your code/example.
Custom GATT Example seems to be working with version 1.8.1, so I will continue using that. Perhaps the problem is related to this: https://bitbucket.org/suunto/movesense-device-lib/issues/70/version-190-and-191-and-send_ble_nus_data
It is widely known that you can update firmware over-the-air using <Update.h> functionality: receive blob size over the network, call Update.begin(blob_size), consecutively call Update.write() until its done, then call Update.end(), and restart the board.
But is there a way to do a backup of current firmware binary using WiFi?
The short answer is "no", there's no support for dumping the firmware over WiFi.
I've not looked at how WiFi Update is implemented so I'm not saying it can't be done at all - just that you're going to have to implement it yourself. Just like Update, if the sketch doesn't already support it, it is likely not possible at all (so you can't backup from an ESP32 flashed with just any old sketch).
I am doing a project on OTA programming of Arduino at remote place so I need GSM along with Arduino, so how can we do OTA with gsm for Arduino?
I assume you're asking how you can remotely control an Arduino with your phone, right?
I suggest using Bluetooth for this, as it is build into every phone nowadays. You'll still have to buy a module to allow the Arduio to communicate via bluetooth. An example of such a module is the HTC-06, wich can be bought online for less then $10 and for wich there is an exellent tutorial over at instructables.
The phone side of the story depends on what kind of device you're using, this is the official Android documentation, this seems to be the Apple documentation.
Alternatively, if you don't want to write everyting yourself, you can use an app like Tinkernut does is one of his videos.
Can anyone help me with the AT command to write characteristic value, Or how to send data from arduino to another ble device using Hm10 module.
The HM10 after sending the AT+START, does advertise packets, and can detect the service and characteristic, But the characteristic value is the default 0x00, How can I change that?
Have checked the data sheet multiple times but can not find an AT command that is capable of doing the same.
UPDATE: Similar problem with setting the HM10 in Central Mode:
Central Mode Setup!
1) AT+ROLE1 - Set up to Central Mode
2) AT+IMME1 - Start from RESET
3) AT+SHOW1 - Show discovered devices
4) AT+DISC? - Discover Devices
Get Device MAC ID,
5) AT+CON[MAC ID]
RESULT: Always gives OK+CONNA and after 10seconds OK+CONNF
I am confused, Use of "AT+START" before "AT+DISC?" causes AT+START to not work and viceversa.
Using AT+START results into a loop of OK+CONN followed by OK+LOST continuously and no more AT commands are accepted. I believe it does result in a
Can you advice on the right order?
Using LightBlue iOS app as the peripheral. How am I to select a service and subscribe to a characteristic to receive data from the application?
Thank You.
There is no AT command to set a characteristic value.
The HM10 is a serial-port emulation device - whatever serial data you send to the HM10 module (aside from the AT commands) is made available on it's BLE characteristic. Unfortunately the data sheet doesn't document the service and characteristics, but this code suggests that the serial RX/TX characteristic is 0000ffe1-0000-1000-8000-00805f9b34fb
So, data written to the serial port should appear as the value of that characteristic. Data written to that characteristic should be delivered out of the TX serial port pin on the HM10 module.
This thread is a bit dated. But the HM-1X firmware now supports changing the characteristics of a module.
"AT+CHAR?" Will get the current characteristic setting for RX/TX
"AT+CHAR0xFFFF" will set the TX/RX characteristics to 0xFFFF
Send: AT+CHAR0xAAA0
Recv: OK+Set:0xAAA0
These features were added v518.
If you need to update your firmware,
Link to Huamao's download site.
I don't have enough reputation to comment on Ladvien's answer, but...
Just a word of warning regarding updating the firmware with a new version from Huamao's download site. http://www.jnhuamao.cn/download_rom_en.asp?id=83
In my experience there were issues with V539, which prevented the firmware operating as an iBeacon - and there may be other problems.
I was fortunately enough to find someone emailed me a copy of the V538 firmware and was able to downgrade again.
Huamao doesn't have old versions of the firmware available for download and AFIK there is no way to backup your current firmware version.
But it was possible to downgrade from V539 back to V538 if you have the bin file for V538 etc. i.e At least up as far as V539 the firmware does allow downgrades and was not checking version numbers to only allow upgrades.
No need to use any AT-commands to send data as it works like transparent serial. Currently it works good to upload sketches from iOS devices to Arduino. Check out http://www.apploader.info
I purchased a BLED 112 dongle from BlueGiga (http://www.bluegiga.com/BLED112_Bluetooth_smart_dongle). I purchased the dongle since I was trying to do a simple POC with an iPhone. I did not want to get into breakout boards or the dev kit just yet.
I am trying to get the heart rate monitor samples working and I am not sure how to load the firmware on the device. I am using the latest version of the SDK (v1.1.1) which states to use the BLE Update tool, not the TI Flash Tool.
However it looks like you need the CC Debugger with the BLE Update Tool to update the SOC. I looked at the CC Debugger and it does not appear to be designed to be used with BLED 112 USB dongle. It appears you need a breakout board to expose the pins to be able to hook the CC Debugger to a BLE 112 module, not a BLED 112.
Lastly, I am not sure if DFU will work without bricking the dongle.
Any advice on how to properly use and program the BLED 112?
Thanks,
G
From the SDK docs:
TI Flash tool should NOT be used with the Bluegiga Bluetooth Smart SDK
v.1.1 or newer, but BLE Update tool should be used instead. The BLE112
and BLE113 and BLED112 devices contain a security key, which is needed
for the firmware to operate and if the device is programmed with TI
flash tool, this security key will be erased.
It is possible to update the firmware on the BLED112 via the USB connection, and without requiring a breakout box or a CC Debugger. However, it is fairly easy to accidentally 'brick' your device in so doing. The problem is that the firmware itself needs to provide the interface to enable DFU mode; if you do an update with your own firmware, and your firmware doesn't provide this capability, you're stuck with the last thing loaded on it.
That being said, here's the process.
The BLED112 dongle is essentially just a BLE112 with an attached USB connection. The BlueGiga SDK ships with drivers that allow the device to be mapped with a simple serial interface, such that the device shows up as a simple COM port (e.g., "COM16") to applications running on the host PC. The SDK also ships with two utilities - BLEGUI, and DFUTOOL - that are able to use this COM port interface to communicate with the device.
(Getting the drivers installed seems like it should be easy, but the process was finicky for me, and I ended up having to mess around with Device Manager, etc., for a while before getting the COM port to show up reliably when I attached the dongle.)
The basic process for building and installing firmware on the BLED112 is:
Compile your BGScript program to an image file using BGBUILD.EXE
Reboot the dongle into firmware update (DFU) mode using BLEGUI2.EXE
After attaching to the appropriate COM port, select Commands | DFU from the menu.
Update the firmware using DFUTOOL.EXE
Before you do this, make sure you read the "Developing Bluetooth 4.0 single-mode applications" and other technotes from BlueGiga's forum (registration required). Specifically around your project configuration:
WARNING:
If the firmware is to be installed into the BLED112 USB dongle the USB
CDC configuration MUST BE included in the project file. If this is not
included in the project file and the compiled firmware is installed
into the BLED112 USB dongle, the USB interface will be disabled and
the dongle stops from working.
Phew. Not necessarily for the feint of heart. I personally found it more appealing to shell out the money for the DKBLE112, which has the BLE112 module mounted on a board with some other accessories, and a CC Debugger for programming. With this setup, you can flash new images to the chip without worrying so much about screwing things up (there's a "reset" button on the board itself).
Other people have reported using breakout boards that are cheaper than the DKBLE112, such as this one from Jeff Rowberg. They also let you program with the CC Debugger, but I have no experience with them.
Have fun!
Based on the information provided, I found the following technote on the BlueGiga support knowledge base.
https://bluegiga.zendesk.com/entries/22810076--HOW-TO-Run-a-BGScript-application-on-the-BLED112-USB-dongle
Thanks
Greg