cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC 5, 3 & 1 MCU

New Contributor

Hi,

These are some the forum threads I have read before submitting this question:

bootloader from memory

Bootloading from SPI / I2C memory (?)

bootloader/bootloadadle from external memory

PSoC 4 EEPROM Bootloader Example - Hackster.io

This is the documentation I have studied:

  • 001-60317_AN60317_PSoC_3_and_PSoC_5LP_I2C_Bootloader
  • 001-73854_AN73854_PSoC_Introduction_to_Bootloaders
  • CY_BOOT_COMPONENT_V5-50_5lp
  • PSoC_Creator_Component_Author_Guide (chapter 10) - this is the only documentation I could find on "custom bootloader" 

Here is the general idea:

  1. I am developing a product using PSOC5LP which has an external I2C EEPROM. 
  2. This EEPROM is 2Mbit, but a large portion of the memory is used up for other things.
  3. I have converted the contents of the .cyacd file generated at compilation to a .bin file which will be used to perform an over-the-air update.  This .bin file is 256 bytes per line, and will be written to EEPROM a page at a time (256 bytes/page).  I will do my own checksumming and data integrity during the write process to EEPROM. I do not wish to use Cypress's checksum features, etc. The .bin file contains only firmware data, and nothing else.
  4. The importance of not writing additional .cyacd information to EEPROM is both due to minimization of overall data transferred over the air, as well as memory used in EEPROM.
  5. The data needs to be stored in EEPROM first, not in flash.
  6. The data needs to be stored as binary data only, without checksum information, etc. so it is aligned to each page in EEPROM.

Question:

In bootloaders I have used previously, you write data to flash memory, do any checksums, etc. as needed, verify the write completed, continue until all data is written to flash, and then reset the chip (and sometimes you may swap a flag to revert to previous code if there's a flash write error somewhere in the middle of the process). 

I'm having difficulty understanding the process for implementing a custom bootloader to read data out of an I2C slave device, write it to flash, and reset the chip.  All of the examples I have seen seem to indicate there's a host present somewhere sending commands and receiving responses.  In my case, the PSOC5LP micro is the host, with an I2C master in the bootloader code taking data out of external memory and writing it to flash. 

My understanding is that there are 5 functions that need to be implemented:

void CyBtldrCommStart(void)   - this function starts the I2C master

void CyBtldrCommStop(void)     - this function stops the I2C master

void CyBtldrCommReset(void)   - this function resets data pointers (clear cached data, etc.)

cystatus CyBtldrCommWrite(uint8 *data, uint16 size, uint16 *count, uint8 timeOut) - this function would technically write data to a host, but what if the "host" is an EEPROM slave device ?

cystatus CyBtldrCommRead(uint8 *data, uint16 size, uint16 *count, uint8 timeOut) - this function reads data from EEPROM device -- I assume that Cypress state machine is going to write contents of data to flash here?

In my case, there is no concept of CyBtldrCommWrite, because the host would only be communicating with itself.  Or maybe, I'm very confused.

I need some help in understanding the concept of reading from EEPROM, writing it to flash, and resetting the micro from a custom bootloader.  Is this functionality supported within the bounds of these 5 functions?

Thanks

0 Likes
Reply
1 Solution
Contributor II

I wonder if maybe this is a situation where "Launcher Only" bootloader would be appropriate?

When you set a comm component, even a custom one, it is expecting a host on the other end that adheres to the communication specs of the bootloader as written in the datasheet:

bootl_packets.JPG

Since you don't really have a Host in your situation, and emulating one to adhere to the communication protocol would probably be a pain, this might be a better option.

I think with a Launcher Only Bootloader you could just jump to it via Bootloadable_Load() and once inside the bootloader, your custom code would just have to read the bytes from your EEPROM and write them to flash with the API functions in cyFlash.c.

I think that's basically what the OP in this thread was doing, just with FRAM instead of an EEPROM:

Re: In Application Programming with FRAM

View solution in original post

6 Replies
Contributor II

Hello.

I can't answer your questions.  But, I found a couple of articles discussing similar boot method from external memory (EEPROM, FRAM).  Maybe will help you.

In Application Programming with GSM and External EEPROM

Re: In Application Programming with FRAM 

Good luck with your project.

0 Likes
Reply
New Contributor

Thanks for your reply, BiBi.  I've read that thread too.  It's just not "clicking" with me.  It would be nice if Cypress had a very clear explanation of how to implement these methods. 99.9% of their documentation is spot-on and clear, but this is not making sense.

I'm going to "guess" my way to something that will at least allow me to ask more specific questions.  I'm going to start by guessing how to implement CyBtldrCommRead by hacking together various bits and pieces, and go from there.

0 Likes
Reply
Contributor II

Hello rule

Here's a far fetched idea.

Cypress app note for HSSP has a 5LP programming a target 5LP.

https://www.cypress.com/documentation/application-notes/an73054-psoc-3-and-psoc-5lp-programming-usin...

In this app note/code, a copy of the target image is stored in the programming 5LP.  It would take some work to massage the code such that the programming 5LP programs itself (being its own target) where the image is stored in external EEPROM.

Maybe you'll get some idea's from AN73054.

Hmmmm,

AN73054 is using SWD between Host and Target.  Might not be that simple to make it applicable for your project.

Your reference to AN60317 would be more applicable.

Or even AN68272 over a UART interface.

All just idea's (likely you've already scanned these).

Choices-choices.

Good luck.

0 Likes
Reply
Contributor II

I wonder if maybe this is a situation where "Launcher Only" bootloader would be appropriate?

When you set a comm component, even a custom one, it is expecting a host on the other end that adheres to the communication specs of the bootloader as written in the datasheet:

bootl_packets.JPG

Since you don't really have a Host in your situation, and emulating one to adhere to the communication protocol would probably be a pain, this might be a better option.

I think with a Launcher Only Bootloader you could just jump to it via Bootloadable_Load() and once inside the bootloader, your custom code would just have to read the bytes from your EEPROM and write them to flash with the API functions in cyFlash.c.

I think that's basically what the OP in this thread was doing, just with FRAM instead of an EEPROM:

Re: In Application Programming with FRAM

View solution in original post

New Contributor

Wow, this seems so clearly obvious and straightforward! Thanks, KyTr.  I will start down that path. That process makes a whole lot of sense.

0 Likes
Reply
New Contributor

I think this is the solution, KyTr.  Makes perfect sense. Thanks for your help, everyone.

0 Likes
Reply