PSoC4 Upgradable Stack OTA with one bluetooth profile

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
FrSt_4749731
Level 3
Level 3
10 replies posted 10 questions asked 10 sign-ins

Hello to all,

I am new to the BLE and bluetooth, OTA and few weeks ago started with the development kit (There I have 2 CPUs: BLE - CYBLE-222014 and MCU - CY8C4146AZI-S433). The firmware upgrade is done over the OTA and code is already available. The application to perform upgrade is on the mobile phone. But the procedure to update the FW seems very complicated for the normal user. As I see for the BLE part we have 3 projects: launcher, stack using the BLE with profile "BLE bootloader" and application with BLE and profile "BLE application".

When application is being used mobile phone and the kit are connected using the BLE profile "BLE application". And over this profile I can also update the MCU fw (both are connected using the I2C and on the MCU we have I2C bootloader) Which is ok and simple to the user. In the MCU we have 2 projects bootloader and application.

When we try to update the BLE fw over the OTA, the user has to disconnect from the kit. Then start the kit in such a way, that BLE is started in the bootloader mode. User then has to connect to the kit using BLE profile "BLE bootloader". After the update is done, user has to unpair with the kit "BLE bootloader" and again pair to the kit "BLE application".

I looked at the example and found similar case in this example: CE220960 - PSoC 6 MCU BLE Upgradable Stack Bootloader

The question is, why can't I use one BLE profile for all the actions? Must say that this approach is very complex for normal users. And also why are the bonding information deleted?

Also, could we not just use the mobile phone to put the kit into the bootloader mode? From the documentation 001-97060_AN97060_-_PSoC_4_BLE_and_PRoC_BLE_-_Over-The-Air_OTA_Device_Firmware_Upgrade_DFU_Guide.pdf

the bonding information should remain unchanged.

I am still searching the forum to find the answer to this question or maybe an example how someone has done this using one BLE profile only.

I again apologize for any beginner questions as lot of stuff here is new to me and I hope someone can clarify this questions.

Thank you very much for the answers, Frenk

0 Likes
1 Solution
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi Frenk,

Please find the project present in the link below that will solve your requirements.

https://community.cypress.com/t5/Code-Examples/PSoC4-BLE-Upgradable-Stack-OTA-with-bonding-data-shar...

Thanks and regards

Ganesh

View solution in original post

0 Likes
5 Replies
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi Frenk,

When we try to update the BLE fw over the OTA, the user has to disconnect from the kit. Then start the kit in such a way, that BLE is started in the bootloader mode. User then has to connect to the kit using BLE profile "BLE bootloader". After the update is done, user has to unpair with the kit "BLE bootloader" and again pair to the kit "BLE application".

User can use a custom characteristic in which when he sends certain command he can put the kit to bootloader mode. All you need to do is call this code in the custom characteristic write event.

                Bootloadable_SetActiveApplication(0);

                Bootloadable_Load();

                CySoftwareReset();

The entire event looks like as follows:

            case CYBLE_EVT_GATTS_WRITE_REQ:

            if(valid command)

           {

            (void)CyBle_GattsWriteRsp(((CYBLE_GATTS_WRITE_REQ_PARAM_T *)eventParam)->connHandle);

            Bootloadable_SetActiveApplication(0);

            Bootloadable_Load();

            CySoftwareReset();

            }

            break;

The question is, why can't I use one BLE profile for all the actions? Must say that this approach is very complex for normal users.

The memory present in the PSoC 4 BLe is not sufficient to hold two separate BLE applications at the same time. So, the upgradable stack OTA is implemented using two separate .cyacd files (for stack as well as application projects). I would like to share the architecture of BLE OTA process with Upgradable stack to you. It is as follows:

As per upgradable stack OTA architecture, stack upgrade is performed in three stages;

Stage 1: The firmware passes control to the Stack Application (using above mentioned method), which receives the new Stack Application image and writes it to a temporary location (User Application region) in the flash memory.  The User Application becomes corrupted in this process (the new Stack Application image overwrites the existing User Application image).

Stage 2: After the download is complete, a software reset is initiated by the Stack Application, and the control passes to the Launcher image. It detects the image located in the temporary location (User Application region) and copies it to the Stack Application region.

(Later step is Application Upgrade as we corrupted application image which is as follows:)

Stage 3: Application Upgrade: Tthe User Application image is upgraded. To enter the OTA upgrade mode, the firmware passes the control to the Stack Application, which receives the new User Application image. The Stack Application then directly writes the new User Application image to the corresponding region of the flash.

Thus, when we use single profile option, bootloader host will keep on giving program row commands continuously for both stack and user application flash rows. Thus, data flow diagram is disturbed. And also, main problem is limited memory.

Hence, the single profile option is limited for External Memory OTA Bootloader configuration where BLE stack and application are part of single image.  External Memory OTA Bootloader configuration is called as legacy version of OTA.) Please have a look at this method also. You can get a code example from PSoC Creator itself.

For your case, the customer can enter Bootloader mode from the BLE application itself using the GATT Write requent from the mobile. After that you can upgrade either application only or application + stack.

In the application only upgrade case, the bonding information of application project only will be deleted. The bonding keys with stack are not disturbed.

In application + stack upgrade case, both the bonding information will be deleted since everything related to BLE is erased as per the architecture.

Hope the above explanation helps. Kindly let us know if you have any queries.

Thanks

Ganesh

0 Likes

Hi Frenk,

When application is being used mobile phone and the kit are connected using the BLE profile "BLE application". And over this profile I can also update the MCU fw (both are connected using the I2C and on the MCU we have I2C bootloader) Which is ok and simple to the user. In the MCU we have 2 projects bootloader and application.

Are you implementing I2C bootloader in the stack project? That means do you have two options to bootload? One with I2C and other with BLE?

Thanks

Ganesh

0 Likes

Hello Ganesh,

Actually we plan to have to cpus on the board, one will be ble and the other ordinary mcu CY8C4146AZI. And to upload FW of the second cpu we will use also I2C between BLE and MCU. To upload the BLE we wanted to use only OTA over BLE. Of course we plan also to update the MCU over OTA, but here we will send special command first to the BLE, so that later we can upgrade the MCU.

Best regards, Frenk

0 Likes

Hello GaneshD,

First I would like to thank you for excellent support and all the helpful answers.

Thus, when we use single profile option, bootloader host will keep on giving program row commands continuously for both stack and user application flash rows. Thus, data flow diagram is disturbed. And also, main problem is limited memory.

Hm, but bootloader could easy forward the commands either to the stack or to the app. Bootloader has plenty of commands and we could probably also add few more for the application, so it could be easy to distinct between them. But yes it could be memory problem if simultaneously we would run stack and the application, but isn't the stack shared and bootloader is very small, so they should probably have enough memory?

So, the upgradable stack OTA is implemented using two separate .cyacd files (for stack as well as application projects)

So even if we have two separate projects and they share the BLE stack, why cant they also share the bonding information?

In the application only upgrade case, the bonding information of application project only will be deleted. The bonding keys with stack are not disturbed.

In application + stack upgrade case, both the bonding information will be deleted since everything related to BLE is erased as per the architecture.

So there is not an option that bonding information remains? I assumed, that if we update the app or stack and inside are only small improvements, then the bonding information should not be lost. Even I thought that we have an option to specify if bonding information is lost or not. Also is not bonding information stored in the metadata section? Probably this could be overwritten in the code? What about temporary storing bonding information to the SFlash and then recover it, could BLE then use it?

Thanks, Frenk

0 Likes
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi Frenk,

Please find the project present in the link below that will solve your requirements.

https://community.cypress.com/t5/Code-Examples/PSoC4-BLE-Upgradable-Stack-OTA-with-bonding-data-shar...

Thanks and regards

Ganesh

0 Likes