Hi @Ankit_Rana,
Please take a look into AN12218 S32K1xx Bootloader with its associated file (AN12218SW), it describes the architecture and usage of the S32K1xx bootloader in S32K1 MCUs. This bootloader supports UART as the communication interface.
Best regards,
Julián
Thanks for the quick response @Julián_AragónM .
I have taken AN12218SW file.
But it seems it is developed for S32k148 is there any easy way to migrate from s32k148 to s32k144.?
Also, I'm not able to see any configuration done in tool for S32k148 project in (UART, CLOCK, PIN etc.)
it seems it is written without generating drivers from configuration tool.
So, it's not easy to take configurations for s332k144 from provided code of s32k148.
Please suggest me a way to make this code functional for S32k144 As soon as possible.
Also, I need some guidance, I'm using Appnote An12323 section 6.1.1 S32K144 Memory Map for A/B Swap, with single pflash block. I have one question as below:
Where should I gather new firmware packets and write into flash? in application code itself OR we should gather in boot loader (UART based boot loader)?
Scenario_1: New firmware packets gathering in APP code itself.
total program flash: 512 --> 247kB running firmware (firmware_1) + 247kB(firmware_2)
flex memory: 64kB --> 16kB bootloader (only A/B swap logic) + 48kB (EEPROM)
If I'm planning to get new firmware packets in application code (firmware_1, Running firmware) itself. Is it possible to flash/store new packets at firmware_2 location without any write/read problems?
(Note: As of now planning to write UART based bootloader as current code size: 278kB will not fit in
247 kB partition decided in appnote section An12323 section 6.1.1)
below image attached from AN12323 page 12.
Thanks,
Ankit Rana
Hi @Ankit_Rana,
Unfortunately, there is no easy way to migrate from S32K148 to S32K144, the procedure is to create a new project, copy the code and drivers from one project into the new one. Also, since this is software based on an old version of S32DS, there are no Config Tools support.
You can instead take a look into this community post for guidance: S32K144 Bootloader Example - NXP Community
As for the second question, new firmware packets gathering in APP code itself should be fine. As long as there was not a reset, you can update the active region.
Just take into consideration S32K144 has one read partition on program flash, so it is not possible to update the application while the old application is still running.
For example, S32K146 has more read partitions on program flash, so old application can run during the update.
Best regards,
Julián
Hi @Julián_AragónM,
Just for confirmation can you please elaborate on below statement.
Just take into consideration S32K144 has one read partition on program flash, so it is not possible to update the application while the old application is still running.
Understanding: if new firmware(firmware_2) packets(1kb chunks) are receiving in running application code over UART(firmware_1), then while receiving new firmware packets it is not possible to perform WRITE/flashing operation to store new firmware packets at (firmware_2) location.
please let me know if my understanding is correct or not.
Thanks.
Hi @Ankit_Rana,
There is no specific example for a bootloader inside the FlexMemory, but you can look into AN12003: Using S32K148 FlexNVM Memory for the use cases. Also, AN11983: Using the S32K1xx EEPROM Functionality may prove useful as well.
There is an example "flash_partitioning_s32k1xx" in S32DS. The purpose of this demo application is to show you the usage of the Flash Driver with the S32 SDK API.
Best regards,
Julián
