PSOC5LP / Custom bootloader with external I2C EEPROM slave device

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

cross mob
RuLe_1240116
Level 1
Level 1
5 replies posted First reply posted First question asked

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
1 Solution
KyTr_1955226
Level 6
Level 6
250 sign-ins 10 likes given 50 solutions authored

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