At present, the customer has successfully upgraded the routine frdmkw38_connectivity_test_freertos through the uart using the KinetisFlashTool tool. The customer feedback now sees a paragraph like this in the attached Kinetis Bootloader Host_ Introduction, See the apps/bus_pal project for an example using pass-through hardware to connect to a target bootloader over I2C, SPI, and CAN. See the validation/embedded_host project for an example of a full embedded host application.
According to the understanding of these paragraphs, first of all I confirm that Kinetis Bootloader Host_ Introduction provides embedded routines to imitate the blhost upgrade function, of which there are two versions.
One is in NXP_Kinetis_Bootloader_2.0.0 package app /bus_pal (provides hardware pass-through function See the apps/bus_pal project for an example using pass-through hardware to connect to a target bootloader over I2C, SPI, and CAN)
The other is in the NXP_Kinetis_Bootloader_2.0.0 package validation/embedded_host (provides full embedded upgrade functionality See the validation/embedded_host project for an example of a full embedded host application. )
First question: 1. Can you help to confirm whether my understanding is correct or not, there is no deviation.
Second question: If my understanding is correct, do the apps/bus_pal program have instructions for use (is there a corresponding development board)? Only the code is seen on the file. If there is a document description, can you provide it to facilitate customer development. Customers can find the following brief chapters in the blhost instruction manual
9.5 Build the BusPal project The BusPal source code is available in the apps\bus_pal directory in NXP_Kinetis_Bootloader_2.0.0 package on www.nxp.com/ MCUBOOT.
9.6 Platform setup
As illustrated in Figure 4, "Role of BusPal in interfacing blhost and target device", the supported platform (FRDM-KL25Z/TWR KV46F150M/TWR-K65F180M) should be connected to host PC via UART (USB-HID is also supported on K65). The BusPal image should be running on the platform, and blhost should be running on the host PC. The target platform runs the bootloader image.
The connection between the target platform and BusPal platform hardware depends on what peripheral is being used to interface with the bootloader. For example, if the I2C peripheral is used for interfacing with the bootloader, the I2C probe pins for SCL and SDA available on the boards for BusPal and target platforms should be physically connected using fly-wires. The connection should be well secured for reliable data transfers.
According to the understanding of this paragraph, the buspal board provides a transfer function to connect the PC and the KW38 chip, (supports I2C, SPI, CAN) function to help upgrade. Find the supported platform (FRDM-KL25Z/TWRKV46F150M/TWR-K65F180M, burn the buspal program, then you can connect to the PC to upgrade.
Third question: 1. Please help to confirm whether my understanding is correct or not, is there any deviation?
Fourth question: If my understanding is correct, are there any instructions on how to connect and how to burn? (This is close to the function I want to achieve)
The real requirement of the customer is to use can to upgrade frdmkw38_connectivity_test_freertos with SK344, so the function of KinetisFlashTool should be implemented on SK344. It would be better to have S32K related routines.
Also clients feel that both folder routines are close, but not sure which one is better. If RD has a routine to implement the above functions on Sk344, it would be the best. If not, it is OK to find a similar one, and customers can modify it by themselves. Can you provide detailed development information, thank you....
