Is it possible to implement ble over the air updating without the use of external memory?
Think of BLE as just one more communication method, albeit with
special properties, and that in and of itself would allow data, an update
as an example, to pass over the link. One could theroretically create an
update process over an A/D converter and an analog link. Maybe not
practible, but doable.
So a bootloader residing on client side could certainly manage an update
process via BLE. Other considerations would include speed of a large
update, memory available on client side.....
Although different links some useful references for other bootloader
/* Style Definitions */
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-fareast-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman";
http://www.cypress.com/?rID=50230 AN68272 UART BL PSOC 3, 4, 5LP
http://www.cypress.com/?rID=41002 AN60317 I2C BL PSOC 3, 5LP
http://www.cypress.com/?rID=57561 AN73503 USB HID BL with GUI Host PSOC 3, 5LP
http://www.cypress.com/?rID=56014 PSoC® 3, PSoC 4, and PSoC 5LP Introduction To Bootloaders
http://www.cypress.com/?rID=83293 AN86526 - PSoC® 4 I2C Bootloader
http://www.cypress.com/?rID=50230 AN68272 - PSoC® 3, PSoC 4 and PSoC 5LP UART Bootloader
Thanks, my question was maybe not phrased correctly. I was wondering if the new OTA firmware image could be stored in the internal flash memory. I have just seen that this is mentioned in the description for project 25 of the 100 projects in 100 days.
"There are a couple methods to perform OTA - by using PSoC's built-in Flash memory, or by using an external memory IC to store the new firmware image"
Looks like there is an example project here that you could adapt -
The problem with OTA bootloading is to ensure that on *ANY* circumstances have a running project on the PSoC BLE. A loss of contact during the update is quite more probable than on a cable-oriented update over I2C or UART.
An additional problem is, the BLE functionality is used for the update and would -if part of the bootloader- require a large amount of flash and sram. So a two-stage update would make the results predictable and always is keeping a functioning project running.
With an external memory you will be able to
-Save the current project to memory
-Load an updated version into a different area of the memory
-Bootload the new or the old project with a rather simple bootloader
The additional effort for an I2C FRam (preferred) or an EEPom will normally not bust your budget.
Cypress has an internal memory based BLE bootloader example in PSoC Creator. See "BLE_Shared_Memory_Bootloadable" & "BLE_Shared_Memory_Bootloader" projects for more details.
@undesh, maybe I am missing something but neither project appears to
be OTA, over the air ? So therefore do not have to run BLE stack overhead ?
This OTA question is important because most BT devices only have air link,
they are dirt cheap (if not now soon enough), and would only be allowed to
upgrade firmware OTA.
From Cypress website www.cypress.com/ -
As the name suggests, OTA allows you to perform firmware upgrades to your end-product over a BLE wireless connection. By doing the firmware upgrade OTA, the user does not need to connect the end-product to a computer over USB. There are a couple methods to perform OTA - by using PSoC's built-in Flash memory, or by using an external memory IC to store the new firmware image. In this example project, we demonstrate the external memory method by utilizing the on-board Cypress F-RAM IC on the BLE Pioneer Kit.
Cypress's Ferroelectric RAM (F-RAM) is a type of non-volatile memory that has three distinct advantages over traditional non-volatile memories: high speed, high endurance, and low energy consumption. These F-RAM devices communicate with the host controller over a serial interface (I2C in this case) that do not have any write delays such that the data is instantly nonvolatile. This is crucial for mission-criticial tasks such as BLE firmware upgrades via bootloading, where any interruption in power can typically be catastrophic to the system. The F-RAM devices also offer virtually unlimited endurance, as they are rated for 100 trillion read/writes when compared to traditional nonvolatlie memories, which is useful for storage of vital data in sensor-based applications. Most importantly, these F-RAM devices consume only 300-µA of active power and 6-µA of standby current, allowing for extermely low-power systems for your BLE products.
The second paragraph, underlined text, all bootloaders have to deal with COM issues. And
the FRAM does not solve a COM issue, its just as susceptable. If data can not be received
OTA by PSOC either internal FLASH approach or FRAM external fails to complete. One has
to design for this.
So the idea of doing firmware updates w/o external memory on the client side, just a design
issue in the BL code. Right ?
There are three methods of doing OTA that is/will be supported by Cypress (confirmed by Cypress tech support team):
1. External Memory OTA - This method receives the new firmware over BLE interface (OTA) and store it in an external memory (EEPROM, serial flash, FRAM etc.) and later reload the existing image with the new one stored at external memory location. This method of OTA is available in PSoC Creator today (BLE_External_Memory_Bootloader & BLE_External_Memory_Bootloadable example projects).
Pros - BLE stack and application can both be updated in one shot. Device temporary bricking during power failure etc. is not possible.
Cons - Requires additional external memory
2. Shared Memory OTA - In this method, the BLE stack and the profiles are fixed and only the end application is updatable using OTA. An example project for this method of OTA is also available in PSoC Creator today (BLE_Shared_Memory_Bootloader & BLE_Shared_Memory_Bootloadable example projects) and the documentation for these example project has all the details.
Pros - No external memory required.
Cons - BLE stack is not updatable
3. Stack updatable OTA - In this method, the BLE stack and the application are OTA updatable. Application update is similar to method 2 (see above) and the BLE stack update is a two step process where an application update is required after the stack update (stack update uses the application storage area). This method of OTA is under development by Cypress and they said this will be released with their next release of PSoc Creator and 256KB flash version of the BLE device. I didn't get a confirmation on the exact release date (they said it's somewhere towards end of June).
Pros - No external memory required, BLE stack is updatable
Cons - None that I could think of.
See attached image for a summary of these 3 OTA methods (courtesy - Cypress tech support team).
Cypress has a new BLE chip coming out soon. This chip will be identical (and pin-for-pin compatible) with the current PSoC 4 BLE devices in the QFN packages. However, these new devices will include 256-KB Flash, which will allow for OTA bootlading without the need for any external memory. The new 256-kb PSoC 4 BLE devices are expected to start sampling in July 2015.
Hope that helps!