Serious bug in bootloader component.

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

cross mob
kemic_264446
Level 4
Level 4
First like received

I'm telling you. If I didn't have to support existing products out there in the field (thousands of them), I would have moved far away from PSoC 5/5LP many years ago. Working around bugs in Cypress components that should have been caught by the most basic of in-house testing at Cypress has cost me many thousands in lost productivity and visits to customer sites.

   

**EDITED to add critical information**

   

Here's another serious bug, it's in the latest bootloader component. V1.30

   

If your main (bootloadable) app uses the flash for persistent storage, using the Emulated EEPROM component. This is perfectly legitimate, but you MUST switch off the "Bootloader application validation" flag in the bootloader component in the bootloader app. So far, so good. This is all perfectly normal. You need to turn off that flag becuase otherwise your app fails validation because the contents of FLASH have changed and checksum is no longer valid.

   

Except there is a serious bug in the bootloader component, when running on PSoC 5LP. It pans out like this:

   

The generated code for the bootloader component contains lots of blocks that are not compiled if the "Bootloader Application validation" flag is not set.

   

So the first bit of code to get executed is:

   
    

cystatus validApp = CYRET_BAD_DATA;

   
   

Then lots of code gets skipped because you are not using Dual Apps, and not using App Validation.

   

But when it skips code because you are not using Daul Apps - it then does this:

   

Bootloader_1_ValidateBootloadable(...);

   

Which it should NOT do because the validate bootloadable flag is not set!! This leaves validApp set to CYRET_BAD_DATA

   

The next piece of code is:

   
    

if ((Bootloader_1_GET_RUN_TYPE == Bootloader_1_START_BTLDR) || (CYRET_SUCCESS != validApp))

    

{

    

Bootloader_1_SET_RUN_TYPE(0u);

    

Bootloader_1_HostLink(Bootloader_1_WAIT_FOR_COMMAND_FOREVER);

    

}

   
   

 

   

So, even if you have a valid app loaded in flash, and you are not using app validation,  the bootloader will now wait forever because CYRET_SUCCESS != validApp.

   

 

   

The upshot of all this, is that when you use bootloader component 1.3 and switch off Bootloader Application Verification, then use Emulated EEPROM to store data in flash, your system will enter the bootloader and wait forever for bootloader commands, instead of waiting for the specified time and then loading your app.

0 Likes
1 Solution
Anonymous
Not applicable

Hello All,

   

The issue with Flast App validation was  due to missing flash temperature value initialization before writing to Flash. The issue can be overcome by calling the function: CySetTemp() in main() before CyBtldr_Start() or Bootloader_Start() API call.  This issue will be fixed in the next version of Creator.

View solution in original post

0 Likes
11 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Kenny, actual bootloader version is 1.40 and there have been a lot of corrections done.

   

Did Cypress (I assume you contacted them) already verified the error you describe? Did they provide you with a workaraound??

   

 

   

Bob

0 Likes
lock attach
Attachments are accessible only for community members.
kemic_264446
Level 4
Level 4
First like received

Hi Bob

   

I have checked and the same bug persists in v1.4

   

I have opened a case.

   

For the interested here (attached) is an image showing the code flow and how it goes wrong.

0 Likes
kemic_264446
Level 4
Level 4
First like received

With regards to the actual version of the bootloader component.

   

Bootloader is one component you cannot upgrade when a new version comes out, because it will be a different size in flash from the one before, and any attempt to load a CYACD file using a different version of the bootloader results in failure. It fails when it checks the first flash row number. So you shouldn't update the bootloader component, unless you can visit all your customer sites and flash the new bootloader from the HEX file with a MiniProg3.

   

Although bootloadble projects include the code for the bootloader in their hex, they do not include it in their CYACD, and anyway the bootloader cannot update itself, thererfore any change in the bootloader results in a visit with a MiniProg3. So therefore it's best to keep the bootloader part of the project static and not update the components in it.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Yes, I was always thinking about the requirement of a  (bootloadable) project that accepts a new Bootloader and programs it over an old one.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

By using a fixed load address you can allocate some addition (wasted) space for bootloader growth. Then an app image can work with different versions. You have to keep system settings in cydwr the same. An app space program can then upgrade the low memory bootloader. risky, but doable.

   

Ed

0 Likes

@psoc_ed Yes - and that's a technique I use with ease on other platforms, such as AVR and PIC.

   

I raised this issue with a support case and got a reply back that it was working as expected. ie. Any app which uses the EM_EEPROM component to store data in flash (perfectly legitimate!) cannot be bootloadable.

   

I believe the support engineer has this wrong, seing as there is a flag in the bootloader component for this very thing, and that I have been using this method for a few years with no trouble, but since a recent update to PSoC Creator it causes all boards with the newest bootloader to fail.

0 Likes
kemic_264446
Level 4
Level 4
First like received

You may remember that I found bugs in the EM_EEPROM component a couple of years back, which basically meant it just didn't work. (It would write data in the wrong place). 

   

Now the same component causes bootloader/bootloadable to fail.

   

It's a poor show form Cypress.

0 Likes

Hey SpiderKenny,

   

This is really terrible.  I'm very sorry for all the problems.  Can you email your preferred contact information to me at mdl@cypress.com.  I work with all the PSoC Creator developers. We'll figure this out.

   

--Matt

0 Likes
Anonymous
Not applicable

I've just encountered the same bug...

   

I set up the Bootloader Component for the default 2000 (ms) wait for command, and it ends up executing this line:

   

        Bootloader_HostLink(Bootloader_WAIT_FOR_COMMAND_FOREVER);

   

Like SpiderKenny, I also have some config data stored in FLASH, so disabled the Application Validation...

   

-mark

0 Likes
Anonymous
Not applicable

Hello All,

   

The issue with Flast App validation was  due to missing flash temperature value initialization before writing to Flash. The issue can be overcome by calling the function: CySetTemp() in main() before CyBtldr_Start() or Bootloader_Start() API call.  This issue will be fixed in the next version of Creator.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Thank you to keep us informed!

   

 

   

Bob

0 Likes