PSoC 4 Custom Bootlodaer is very slow

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

cross mob
lock attach
Attachments are accessible only for community members.
OmSa_4786791
Level 3
Level 3
25 sign-ins 10 replies posted 10 sign-ins

Hello,

I have a device that I want to update the firmware of.

I want to use a custom bootloader interface for the update of the device, however, when I try to use this interface, the update process is super slow (in comparison to using  CySysFlashWriteRow function and writing the new app by myself).

I currently have a simple POC bootloader program that writes an application from the disk.

I have two implementations for this bootloader. The first one is using the CySysFlashWriteRow function and writes the application manually, and the second one is constructing the bootloader commands and using the bootloader interface to write the program.

I saw that it is taking a lot more time to do the update with the bootloader interface.

The simple application that I am writing has 10 rows, while the real application I am using has 330 rows.

To emulate the run time of the real application update in this simple program, I write the same application 33 times.

By using the CySysFlashWriteRow function, the update takes a bit less than 10 seconds.

By using the bootloader interface, the update takes about 5.5 minutes (330 seconds)!

(There is a huge difference when writing only 10 rows as well, but it is a lot harder to measure)

I tried to look at the auto-generated code of the bootloader itself, but couldn't find any specific piece of code that took a long time there.

I understand that the bootloader adds overhead to the operations (it uses more functions, and does a lot of checks on the data), but an overhead of 33 times the original length seems way too long for me.

Is this the way it should be?

Is there any way to make the bootloader more efficient?

I am attaching my simple POC update application.

Changing the value of UPDATE_METHOD to either BOOTLOADER_INETRFACE or MANUAL_WRITING will make the bootloader run the update using the appropriate way.

Any help will be greatly appreciated,

Omri

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

Hi Omri,

First of all thank you for sharing your implementation with us. Ideally as you mentioned, there is not such thing that causes that much time difference between your own method and standard bootloader method.

Have you tried our standard bootloaders with I2C or UART and check what is the time taken with that method? We can say that it will not take around 30 seconds for medium application. So it depends on the custom communication algorithm ideally.

Thanks

Ganesh

View solution in original post

2 Replies
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi Omri,

First of all thank you for sharing your implementation with us. Ideally as you mentioned, there is not such thing that causes that much time difference between your own method and standard bootloader method.

Have you tried our standard bootloaders with I2C or UART and check what is the time taken with that method? We can say that it will not take around 30 seconds for medium application. So it depends on the custom communication algorithm ideally.

Thanks

Ganesh

lock attach
Attachments are accessible only for community members.

Hi Ganesh,

Thank you for your reply.

I now tried to use the UART implementation to update my software, and it took about 65 seconds, so I understood that it just an error I have created myself.

I looked into the code I wrote, and after (quite a lot of) debugging, I finally found that I have left a sleep inside my code.

The sleep was a delay of 1 second inside the write command.

Once I removed this sleep from my code, the implementation with the bootloader interface itself took about the same time as my manual implementation (now both of them takes about 10 seconds for a software update of 330 rows).

I am attaching my final implementation here, for future reference for anyone who might need it.

Thanks for the help, and sorry for bothering you about this bug of mine.

Omri