We are developing a BootLoader for S32G and are currently finalizing the development plan for the BootLoader. If the official OTA solution is adopted, the UDS flashing protocol is implemented in the A-core APP. But if the APP encounters problems and cannot run normally at this time (even with the ABswap function, this situation may exist in both partitions), then it is necessary to open the controller shell and use serial or debug methods to flash. But once the controller is opened, it is scrapped. So how to avoid the need to open the casing for flashing? How to ensure that there is always a BootLoader available and that the APP can be flashed through the CAN bus or Ethernet bus?
The current solution we have in mind is to create a BootLoader on the M core that can achieve flashing based on CAN or Ethernet. But I'm not sure if this plan is reasonable? Is there any other more suitable solution? If it is reasonable for us to create another BootLoader solution on the M core, would it be based on the official BootLoader? Or should we implement an M-core APP software on top of it as a BootLoader? This forms a two-level BootLoader. Do you recommend making modifications directly based on the official BootLoader? Because the files of this BootLoader are very scattered, it is not convenient for software version management and maintenance. So I hope you can give some reasonable suggestions to avoid us doing something very unconventional.
The installation package name for the official BootLoader is Platform_Software_integrations_S32G2_2023_06
Looking forward to your response.
