6 Replies Latest reply on Mar 6, 2020 6:06 PM by RuLe_1240116

    PSOC5LP / Custom bootloader with external I2C EEPROM slave device




      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.



      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?