Problem:
The OTA upgrade based on the official Bootlaoder needs to follow the official communication protocol. We need to implement customized OTA according to our own communication protocol. How do we need to implement it? What are some things to keep in mind?
Solution:
Whether it's an OTA based on the official Bootlaoder or an OTA based on the user's automatic communication protocol, the following basic steps need to be implemented:
1. Internal Flash Partition (Bootloader Area, App Area and Data Area)
2. Internal Flash erasing
3. Separation and extraction of app application files
4. Implementation of the BOOT area program redirected to the APP area API
1. Internal Flash Partition (Bootloader Area, App Area and Data Area)
1. The address map of PSoC™ 4 is as follows:
Among them, the starting address of the internal flash is at 0x00-0x1FFF FFFF, and the actual size can be obtained according to the data sheet of the corresponding chip model.
Therefore, we need to divide the internal Flash according to the OTA architecture. The following are commonly used partitioning methods:
The different OTA zones need to be divided according to the unit of conduct. The line size corresponding to different flash series is not the same. For details, please refer to the corresponding data manual.
Note: Because the app project needs to use the bootloadable primary key to integrate boot and the app's engineering firmware, the last line of the single-partition project Flash will be used to store Metadata, while the last two lines of the dual-partition project Flash will be used to store Metadata, users need to ensure that the application area does not occupy the Metadata area of Flash.
2. Internal Flash erasing
1. There is only one userFlash area inside the chip. There is no DataFlash area. Flash does not have the concept of sectors, but rather the concept of lines. The erasing and programming of Flash are operated according to lines. The size of the lines will be different for different series of chips. Among them, the CY8C4100S Plus series line size is 256 bytes.
2. Flash erasing and programming calls use the same function interface, and there are no separate erasing and programming interfaces. The interface functions are as follows:
uint32 cysysflashwriterow (uint32 rownum, const uint8 rowData [])
Parameter description:
rowNum: line number, total number of rows = flash size/row size
rowData []: content that requires programming, the array size must be equal to the size of the Flash row
Return value:
/** Completed stages. */
#define CY_SYS_FLASH_SUCCESS (0x00u)
/** Specified flash row address is invalid. The ROW ID or BYTE ADDRESS IS OUTSIDE OF THE AVAILABLE MEMORY. */
#define CY_SYS_FLASH_INVALID_ADDR (0x04u)
/** Specified flash row is protected. */
#define CY_SYS_FLASH_PROTECTED (0x05u)
/** Resume Completed. All non-blocking calls have been completed. The resume/abort function appears to be called until the next non-blocking. */
#define CY_SYS_FLASH_RESUME_COMPLETED (0x07u)
/**\ brief Pending Resume. A non-blocking was completed and must be completed by calling the resume API, before any other function may be called */
#define CY_SYS_FLASH_PENDING_RESUME (0x08u)
/** System Call Still In Progress. A resume or non-blocking is still in progress. The SPC ISR MUST FIRE BEFORE
Continue the next resume. */
#define CY_SYS_FLASH_CALL_IN_PROGRESS (0x09u)
/** Invalid Flash Clock. Products using CY_IP_SRSSLT MUST SET THE IMO TO 24MHz and THE HF CLOCK SOURCE TO THE IMO CLOCK BEFORE WRIT/ERASE OPERATIONS. */
#define CY_SYS_FLASH_INVALID_CLOCK (0x12u)
3. Flash erasing and programming takes about 9.4ms, and since it is blocking mode, all interrupted functions are blocked. It is necessary to evaluate whether it will affect application functions (mainly display). Additionally, it is necessary to add cleaning operations before and after line erasing and programming functions to ensure that the program does not think that the upgrade has failed due to the Watchdog reset.
3. Separation and extraction of app application files
BOOT and APP can be integrated into a burnable HEX file through the primary key of BootLoadable. The corresponding upgrade file can be extracted according to the following operation:
1. Copy the HEX file that needs to generate the BIN file to the corresponding BIN folder:
2. Modify the content of the RUN.bat file: Hex source file name, starting address, and length, and run the RUN plug-in to generate the corresponding BIN file
4. Jump to the API in the BOOT area to the APP area
void (*flash_jump) (void);
void flash_boot_jump (uint32_t addr)
{
uint32_t destAdrr;
uint32_t*pt;
SCB- > reserved0=addR;
//< set User code interrupt vector tab address SCB-> VTOR
pt = ((uint32_t *) (addr));
destAdrr =*pt;
__set_msp (destAdrr);
pt = ((uint32_t *) (addr+4));
destAdrr =*pt;
flash_jump = (void (*) (void)) (destAdrr);
flash_jump ();
}
void MG_JumpToApplication (void)
{
uint32_t u32JumpAddress;
u32JumpAddress = USER_APP_RUN_ADDR;
flash_boot_jump (U32JumpAddress);
}
Note: If the BOOT project uses interrupts, all interrupts need to be turned off before redirecting
smartconx_target@Q!w2e3r4t5y6u7i8o9p0||/t5/PSoC-4/PSoC-4-%E7%94%A8%E6%88%B7%E8%87%AA%E5%AE%9A%E4%B9%89OTA%E5%AE%9E%E7%8E%B0%E6%8C%87%E5%AF%BC%E8%AF%B4%E6%98%8E/td-p/484046
Show Less
Dec 19, 2023
Solved
