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).
Related
I'm a little bit new to ESP32 and Arduino ID. I've been working on a project in which I want to switch the wifi network from one to another at any given time. But whenever I'm trying to close the existing connection (network) and reconnect to the new one, ESP32 crashes and gets rebooted. A bit peculiar behaviour I would say. Additionally, I even tried to use the EEPROM for the storage purpose, so, even when my ESP32 gets rebooted, it will take the updated values from the storage. Unfortunately, sometimes ESP32 crashes even when I update the variable which was being passed earlier to WiFi.begin(). Lastly, In my application, I'll be providing the new SSID and Password through the serial (COM) port. Can anyone help in achieving this task?
I tried a similar task with persisting values in memory. The ESP32 lacks an eeprom so you need to use some nvs (non volatile storage) functions as they are called for ESP32. See https://github.com/rpolitex/ArduinoNvs for example.
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
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/
Please pardon me if this question comes as a little too basic but I have tried searching almost everywhere but haven't found a clue.
I am using the esp8266 module and have uploaded the firmware in it. I have also set it as "Access point" so that other modules are able to connect with it. My problem is that I want to control it pro-grammatically through an 8051 micro-controller. I have searched online and there is a lot of documentation on how it program it through arduino, but that doesn't solve it for me. I want to use assembly language to build a serial protocol that communicates the data from 8051 to esp8266 and then to the connected modules (such as Android device).
My question really is, "would it be possible to just connect TX/RX of 8051 to RX/TX of esp8266 and write a code in assembly that transfers data as I desire to esp8266? Or, do I have to do something else?".
At the moment the only documented way for a host controller (the 8051 in your case) to talk to the ESP8266 is to use the serial port (there is a slave SPI port but the mechanism for driving it isn't known yet). So you will have to make up a little protocol to send and receive commands and data (assuming that the standard support for an enhanced AT command set isn't sufficient for you).
The baud rate can go a lot higher than the default 115200bps, if you need it to (although I'm not sure if the 8051 could keep up).
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