What are the Minimum Bootloader changes to prevent Bootloadable from being applied?

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

cross mob
MiSt_296941
Level 4
Level 4
25 replies posted 10 replies posted 10 questions asked

Hello there,

We have a product in production using the PSoC5LP using a Single Application Bootloader.  We are now creating a variant of the original Hardware - it will have a slightly modified version of the Bootloadable.  I want to change the Bootloader enough such that the end user can't put the original FW in the new Hardware (and vise versa).

I have been unable to make changes to the Bootloader to cause the original Bootloadable to be rejected when I try a FW update.  The Bootloader component has a Bootloader Version Number - you would think that would do it but no...

Anyone know what to do for this?

Mike.

0 Likes
1 Solution
MiSt_296941
Level 4
Level 4
25 replies posted 10 replies posted 10 questions asked

Ganesh & Len,

Thanks for the replies.  I discussed this with my local FAE and there is another solution which I am considering:

1. There is a Bootloader Application Version in the Bootloader component.

2. There are also 3 fields in the Bootloadable component (Application version, Application ID, Application custom ID).

3. None of these are very well documented as to what we should or should not use them for.

4. All of these values end up in the Metadata which is in the last 64 bytes of Flash - and they all default to hex 0.  They also are in the CYACD file.  So here is what I was thinking:

In my new version of the Bootloader I add the optional "Get metadata" command.  If I then required the Bootloader Application Version and the Bootloadable Application version to match, I can control whether to update the FW from my Host application.  If the Host talks to an old unit where the Get Metadata command is not available it will get an error and I can assume it is version 0x0000 (which was the default that I never changed for the Bootloader Application Version).

I just wish this topic would have been addressed in the documentation.  Even the Intro to Bootloaders App Note didn't cover this in it's "Future Proofing" section - seems like it should.  Can Cypress address this?

Mike.

View solution in original post

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

Hello Mike,

The Bootloader project will not know the information about the Bootloadable until the Bootloadable project is loaded completely.

So, it could not stop the process in the middle.

For your case, you need to design custom software that adds one more layer to the Bootloader host application and the Bootloader project to check the version of the Bootloadable project. This layer can be implemented using an I2C transfer of few bytes to the Bootloader project and there the project will call the actual Bootloader Start() function to initiate actual Bootloading process.

Thanks

Ganesh

0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Mike,

Ganesh has the best solution of modifying the Bootloader host SW only on the newer HW to accept a "minimum" version of the Bootloadable.

This requires that you either send a preface packet of data that contains the FW build # or in the Bootloadable image, the FW build # is included in a specific location in the image.

Note: This method does not prevent loading the newer Bootloadable into the OLD HW.  I hope this is OK.

Here's another modification of the suggestion from Ganesh.

The FW build # can be multi-layered.   One of the layers can be encoding the HW revision the FW applies to.  For example:

Build = HHH.vvv.RRR.sss

Where:

HHH = Hardware version #

vvv = SW version #

RRR = SW revision #

sss = SW release #

With the HHH you can have the Bootloader ONLY allow Bootloadable SW loading if it matches the Bootloader HHH.

Just a thought.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
MiSt_296941
Level 4
Level 4
25 replies posted 10 replies posted 10 questions asked

Ganesh & Len,

Thanks for the replies.  I discussed this with my local FAE and there is another solution which I am considering:

1. There is a Bootloader Application Version in the Bootloader component.

2. There are also 3 fields in the Bootloadable component (Application version, Application ID, Application custom ID).

3. None of these are very well documented as to what we should or should not use them for.

4. All of these values end up in the Metadata which is in the last 64 bytes of Flash - and they all default to hex 0.  They also are in the CYACD file.  So here is what I was thinking:

In my new version of the Bootloader I add the optional "Get metadata" command.  If I then required the Bootloader Application Version and the Bootloadable Application version to match, I can control whether to update the FW from my Host application.  If the Host talks to an old unit where the Get Metadata command is not available it will get an error and I can assume it is version 0x0000 (which was the default that I never changed for the Bootloader Application Version).

I just wish this topic would have been addressed in the documentation.  Even the Intro to Bootloaders App Note didn't cover this in it's "Future Proofing" section - seems like it should.  Can Cypress address this?

Mike.

0 Likes

Mike,

Looks like you might have a solution.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes