Announcements

Help us improve the Power & Sensing Selection Guide. Share feedback

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

cross mob
LYNllow
Level 1
Level 1
10 sign-ins 5 replies posted 5 sign-ins

Hi guys!

I'm trying to implement a bootloader where I can reprogram the internal psoc flash with a program stored in an external flash.

I'm following this document on the steps that I need to program, I don't need all of them since its not an external programmer, I am programming from "inside" the chip. I get the hex file from the HexFile Parser program so I guess the hex file is correct.

I can write on the flash rows but once I finish programming it, nothing happens. What can I be missing?

0 Likes
1 Solution

Hi.

As a double check on the checksum, download the app note pdf and its zip file AN73054:
Infineon Technologies

Go to Appendix A and read how to use this hex file parser.  It's pretty straight forward.  The parser is in the C# Application folder.
In the Heximage.c file, go to the bottom of the file, then scroll back up about 1 page worth.  Or, just search for the word checksumData.

I've used this download method and it verifies against PSoC Programmer.  I don't know if this is the same hexfileparser you are using or not.  But, I know that it works!

In your case, you have a downloader to deal with, so the app note isn't really applicable, but the checksum should work out to be the same.  As mentioned, this is just another way of double checking the checksum.

The bootloader is pretty picky about checksums.  If it's wrong, the bootloader won't jump to the bootloadable.  I would add a blinking LED or toggle a GPIO to indicate a failed checksum.

Something to try is, re-configure the bootloader to Exclude Checksum.

Another method is to program the bootloader flag in the metadata area that tells it to either check or ignore the checksum completely.

I wouldn't want to release a product without checksum verification upon bootup.  So, my suggestions are just temporary to help get the bootloadable running.

View solution in original post

0 Likes
11 Replies
LeoMathews
Moderator
Moderator
Moderator
First question asked 500 replies posted 100 solutions authored

Hi @LYNllow 

Can you please specify which PSoC device you are using? Which is the HexFile Parser program you used for the device? Does it belong to the same PSoCfamily?

Are you using PSoC Programmer or ppcli to program the device? If you are using PSoC Programmer, can you please send the console messages after programming?

Thanks and Regards,
Leo

0 Likes

Hey! Thank you for the quick answer.

I'm using PSoC 4.4 - CY8C4146LQI-S433. And about the HexFile Parser, I think it is the same family, it was on a folder called "CY8C41xxS family" (link for the program).

I have the MiniProg4, but what I'm doing right now is after I program the device with the MiniProg, on the bootloader there's a routine which will get data stored in an external flash and program using the CySysFlashWriteRow function to write on the internal flash.

0 Likes

Another point that I think that is important, on the manual for programming it has two different variables: MacroID - which can be 1 or 0 - and the RowID.

The code auto generated for writing in the internal flash does not have these two different variables, this is where it differentiates:

Auto Generated Code

LYNllow_0-1676043121081.png

 

Pseudo Code from the manual:

LYNllow_1-1676043144226.png

I've tried to change the auto generated code to follow this part of the manual, creating a variable macroID, but this change after 5 iterations don't let me access more the external flash and the code gets stuck because is waiting on the external flash, but without this change it reads the data until the end but then nothing happens.

I don't know what the problem is, I'm really stuck on this one.

0 Likes
BiBi_1928986
Level 7
Level 7
First comment on blog 500 replies posted 250 replies posted

Hello.

Did you Build the Project stored in external FLASH as Bootloadable?  If not, it will be programmed into FLASH starting at address 0, thus over-writing the bootloader.

Did you "absolute" locate the external FLASH Project above the memory occupied by your bootloader?

Is your bootloader designed from scratch?  If not, are you programming the Metadata area at the very top of FLASH space?  A normal bootloader checks this region before allowing the bootloadable to run.

Any reason you're not using Em_EEPROM to store the code read from external memory?  You don't need to worry about CySys calls, timing, clocks, etc. when using Em_EEPROM to write to FLASH.

I'd start with a simple s/w blink program to prove-in your bootloader/programmer.

BTW, is the bootloader image still intact after you attempt to program the FLASH from external memory?  You can check this with Creator in Debug mode or PSoC Programmer and verify the checksum.

0 Likes

@BiBi_1928986 I think the problem is actually writing on top of the bootloader, how do I know the address where the bootloader ends?

0 Likes

Hello.

A couple of ways to check where bootloader ends:

1) In the log window at bottom of Creator window, it will print how many bytes are used in FLASH (and in SRAM) when you compile just the bootloader.  Or, look in the .log file.  For example:
Flash used: 2142 of 262144 bytes (0.8 %).
SRAM used: 15693 of 65536 bytes (23.9 %). Stack: 2048 bytes. Heap: 128 bytes.

2) You can look at the .map file, but it's pretty ugly trying to understand it.

3) You can enter the Debug mode with just the bootloader programmed into FLASH and look at FLASH memory contents.  You'll see lots of programmed bytes starting from memory address 0x00 up to roughly 2k bytes (size depends on bootloader options selected for compile).  When you see blocks of 0x00's, then there's nothing programmed above this.

4) You can look at bootloader .hex file and search for the beginning of the Metadata bytes at end of .hex file (0x9030 0000).  Any bytes prior to this line are bootloader FLASH bytes.  Refer to Figure 2-2 in the PSoC 4 Programming spec you referenced.  A description of how to decode Intel hex is in Appendix B of same document.  (Actually, it's probably easier to just look at .hex file and scroll down till you see lots of 00 bytes.)

0 Likes

Hey! Thank you for the fast reply.

I thought that would be somewhere to get in a register.

Also, can you tell me how I can program the metadata?

0 Likes

Hi.

For info on Metadata, download AN68272 and search for Metadata.  This shows the FLASH image layout of Metadata.
Infineon Technologies

The other document is AN84858.  This has info on how to use the hexfile parsers for Metadata.  Appendix A.
Infineon Technologies

Something to keep in mind..., "Metatdata" in .hex file is not the same as Metadata in FLASH image.  They are 2 different structures with different parameters.  It took me a while to figure this out and led to plenty of confusion.

Of interest might be the CyElfTool Command Line Tool, (included with Creator installation) which combines files and updates/corrects the Metadata fields.  You might be able to save yourself some effort by combining your custom bootloader with your bootloadable and let CyElfTool work out the FLASH image Metadata fields.  This creates a new hex file.  Then, edit the new file to separate the bootloadable into it's own separate file that you then put into external FLASH.  Details of CyElfTool are in Creator User Guide.  I've not used this tool.  It's just a suggestion.

0 Likes

Hey!

Thank you very much for all your help. I've managed to get the metadata correct, and that part is working fine, but still after reseting nothing happens.

I've noticed that the new checksum is different, but I think it should be the same since I've used the same program to make a transfer. I think that maybe something is wrong with the HexFile Parser.

Do you have a good idea on maybe how I could do this by myself and not use HexFile Parser?

0 Likes

Hi.

As a double check on the checksum, download the app note pdf and its zip file AN73054:
Infineon Technologies

Go to Appendix A and read how to use this hex file parser.  It's pretty straight forward.  The parser is in the C# Application folder.
In the Heximage.c file, go to the bottom of the file, then scroll back up about 1 page worth.  Or, just search for the word checksumData.

I've used this download method and it verifies against PSoC Programmer.  I don't know if this is the same hexfileparser you are using or not.  But, I know that it works!

In your case, you have a downloader to deal with, so the app note isn't really applicable, but the checksum should work out to be the same.  As mentioned, this is just another way of double checking the checksum.

The bootloader is pretty picky about checksums.  If it's wrong, the bootloader won't jump to the bootloadable.  I would add a blinking LED or toggle a GPIO to indicate a failed checksum.

Something to try is, re-configure the bootloader to Exclude Checksum.

Another method is to program the bootloader flag in the metadata area that tells it to either check or ignore the checksum completely.

I wouldn't want to release a product without checksum verification upon bootup.  So, my suggestions are just temporary to help get the bootloadable running.

0 Likes
LeoMathews
Moderator
Moderator
Moderator
First question asked 500 replies posted 100 solutions authored

Hi @LYNllow ,

Thread was locked due to inactivity for long time, you can continue the discussion on the topic by opening a new thread with reference to the locked one. The continuous discussion in an inactive thread may mostly be unattended by community users.

Thanks and Regards,
Leo

0 Likes