What is the best practice of a CAN-based Bootloader for S32K and MBDT toolbox?

[yerik]

Dear all,

I have gone through quite a few posts on this forum. However, I have not found any best practices for CAN-based Bootloader and MBDT.

There are two different bootloaders I found.

1. The unified bootloader framework.

# Provided by NXP, can be found here

** https://community.nxp.com/t5/S32K-Knowledge-Base/Unified-bootloader-Demo/ta-p/1423099

# Host PC uses an open-source GUI called ECU-BUS, which can be found here

** https://github.com/frankie-zeng/ECUBus

** This feature enables you to use your current CAN device and don't need to buy a new one, not to mention to buy a highly expensive Vector one. ^_^

# Used for IDE based Application

** Ok for IDE-based project.

** Maybe ok for the MBDT-generated bin file, but I have not tested it yet.

Here I have a question. Even if this tool could work for the first time, there should be a daemon thread in the user APP to monitor whether a new upcoming upgrade is required by the Host PC, cause the MCU should go back to Boot to flash the new bin file. If this logic is correct, the daemon feature should be fulfilled in Matlab with the MBDT toolbox, but I didn't see any related function or module in the MBDT toolbox.

2. The openbox bootloader in MBDT

# RAppID bootloader

** Support Vector CAN device only which has limited the usage a lot

** Support MBDT-generated bin file originally

** It is a little bit hard to fulfill chips such as S32K148 based on post

https://community.nxp.com/t5/Model-Based-Design-Toolbox-MBDT/Is-it-possible-to-use-MBDT-development-...

So, what is the best practice of a CAN-based Bootloader for S32K and MBDT toolbox?

The ideal one should at least have the following features:

1. The CAN address can be customized for the target MCU which is very important in multiple controller systems.
2. The Host PC client can use the main vendors' CAN devices such as PEAK and Kvaser.
3. The MBDT-generated bin file is supported and re-upgrade is supported.

Thanks very much to anyone who helps.

[mukhtar]

Option number 1, is it not possible to port this from RTD2.0.0 to RTD5.0.0 ?

[Irina_Costachescu]

Hello @yerik 

Indeed, there is a C code application example, which demonstrates this functionality, as you indicated in Option number 1. However, that represents just a reference example (and not a product) which is developed on top of the RTD 2.0.0, while currently MBDT for S32K3 will be delivered in the next release with RTD for S32K3 5.0.0. Hence, due to such compatibility issue, I don't think that migrating this example inside the toolbox represents a streamlined process.

As for the second option, as far as I know, RAppID Bootloader does not offer support for S32K3.

We will research this functionality and use case for our future releases, and investigate what would be the most suitable manner in which we could add support for the S32K3 bootloader. But currently, we can't commit to a time frame of when this feature will be available.

Thank you,
Irina