UDS Bootloader & Application Build Structure for S32K144 (S32 Design Studio 3.4)

[KAVIN7]

Hello,

I am working on firmware development for S32K144 using UDS Bootloader and UDS Application.

I am currently using S32 Design Studio 3.4 (RTD/RTM) and need guidance on the recommended tool version and project structure for UDS bootloader implementation.

My questions are:

1. Should the UDS Bootloader and Application be implemented as

   • two separate S32DS projects, or

   • one project with separate memory sections?

2. Can a UDS bootloader be developed using S32 Design Studio 3.4, or is S32 Design Studio – ARM recommended?

3. Some NXP Community examples use S32 Design Studio ARM with RTM 2.0.0 for the UDS bootloader.

   • Is this setup mandatory, or

   • can the same approach be used in S32 Design Studio 3.4 with RTD?

4. Is the Unified Bootloader Framework / demo bootloader still the recommended solution for new S32K144 designs, or is there a newer option?

Any guidance would be appreciated.

Thank you for your support.

[lukaszadrapa]

Hi @KAVIN7 

1. I recommend to use two separate projects to ensure that there are no cross-dependencies.  
2. You can use any development tools, that’s up to you. Common recommendation is to use latest IDE and latest SDK/RTD for any project.  
3. Unified bootloader shared on the community (https://community.nxp.com/t5/S32K-Knowledge-Base/Unified-bootloader-Demo/ta-p/1423099) is only unofficial demo shared AS IS with no guarantees and no support. Nothing is mandatory here. The demo can be used as a starting point to develop own solution. It’s not classified as production code. You can use any IDE or SDK/RTD you want.
4. There’s no newer option. If you are looking for production code, you can check third parties like https://www.vector.com/int/en/products/products-a-z/embedded-software/flash-bootloader/#

Regards,

Lukas

[lukaszadrapa]

And I will add - if you want to use or just slightly modify original Unified Bootloader, use the same IDE and SDK, of course. This will require lowest effort. It probably does not make sense to port it to different IDE/SDK/RTD.