Bootloading a PSOC 4 without access to original Bootloader hex file

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

cross mob
ImanHz
Level 1
Level 1
5 sign-ins First reply posted First question asked

Several years ago, we bought a product that uses PSOC 4 BLE chips (CY8C4247LQI-BL483 and  CY8C4127LQI-BL473). Now we've decided to upgrade its firmware using its bootloader. There is a host MCU on the board so we can use a UART bootloader.

The problem is that each Bootloadable project needs the hex file of a corresponding ‌Bootloader project. Currently, we don't have access to ‌the Bootloader project and it seems that the manufacturers have altered the Cypress default bootloader project in AN68272 application note. (Since it utilizes a baudrate rather than 57600).

Is it possible to acquire Bootloader hex file from PSOC flash? It is not locked. Or is there any way around this problem?

0 Likes
1 Solution

Hello.

Have  a look at the UART Bootloader app note AN68272 and search for metadata.  There is a table that shows the last flash row used by bootloader.  Be sure to look under the PSoC4 column.  And, read the note below the table in case it applies to your product.  This table also tells you where the application starts.

I would suggest you build a simple test application with a known UART bootloader.  Dump the FLASH as you did before and compare your unknown UART bootloader flash occupancy with the known UART bootloader flash to get a proper understanding of what's stored where.  From there, you might be able to salvage just  the unknown bootloader into a hex file.  I hope that made sense.

Good luck with your project.

edit:
BTW, "The metadata section is the highest 64-byte block of flash".  So, the address column in that table is actually an offset.

edit:
I would then attempt to create a hex file from the known bootloader, flash it, then see if UART bootloading with a different known bootloadable works.  If it works, you have a great starting point.  If it doesn't, you're missing something. TBD.  The reason for the 'different' bootloadable is, you don't want to accidently put some bytes into flash that shouldn't be there.

View solution in original post

4 Replies
SuSh_1535366
Level 5
Level 5
Distributor - Macnica (Japan)
10 solutions authored 10 likes given 10 likes received


Hi,

If the PSoC is not protected and you can access to the SWD port of the device, you can use a debugging tool such as MiniProg3 to dump all the contents of the FlashROM.

However, it is not possible to know to which extent of the dumped address is the bootloader area and from where is the program area.

(If SWD can be used, the program can be rewritten without using the bootloader.)

Does the product you purchased support firmware modification by the user?
Does the product really support the UART bootloader?

If so, you can certainly ask the product manufacturer to provide you the bootloader.

ImanHz
Level 1
Level 1
5 sign-ins First reply posted First question asked

Yes I've tried communicating with the device using UART. I send Enter Bootloader Command (along with setting a specific pin to LOW) and receive the Silicon ID and ... .

The flash memory is not protected and I have dumped all the flash memory data in a HEX file.

0 Likes

Hello.

Have  a look at the UART Bootloader app note AN68272 and search for metadata.  There is a table that shows the last flash row used by bootloader.  Be sure to look under the PSoC4 column.  And, read the note below the table in case it applies to your product.  This table also tells you where the application starts.

I would suggest you build a simple test application with a known UART bootloader.  Dump the FLASH as you did before and compare your unknown UART bootloader flash occupancy with the known UART bootloader flash to get a proper understanding of what's stored where.  From there, you might be able to salvage just  the unknown bootloader into a hex file.  I hope that made sense.

Good luck with your project.

edit:
BTW, "The metadata section is the highest 64-byte block of flash".  So, the address column in that table is actually an offset.

edit:
I would then attempt to create a hex file from the known bootloader, flash it, then see if UART bootloading with a different known bootloadable works.  If it works, you have a great starting point.  If it doesn't, you're missing something. TBD.  The reason for the 'different' bootloadable is, you don't want to accidently put some bytes into flash that shouldn't be there.

Great idea. I will test it soon.

0 Likes