MPC5775B Bootloader and RAppID BL Tool

[fev_buergel]

Dear all!

I try to write as "condensed" as possible. Please correct me, where ever my statements might be wrong.

We have a new hardware development.

It uses MPC5775B microcontroller.

I would like to use a bootloader to flash application software via CAN (MSCAN_0).

I understand that this controller does not have a bootloader "pre-flashed" and that I do have to flash a bootloader myself.

I somewhere read that "MPC5777C_S32DS_UART0_CAN0.rbf" is compatible to MPC5775B. I successfully flashed this file using a third party flash tool (PE Micro Cyclone Universal).

Now I tried to "download" ("flash") the actual application file to the MPC5775B.

I tried to use RAppID BL Tool 1.6.7.35. I belive there is no newer version available.

RAppID BL Tool does not have MPC5775B available (since the controller is newer than the software).

I was using this tool before successfully with MPC5643L, therefore I know that the tool "in general" works and drivers are set up correctly.

I selected MPC5777C. BAM status I selected "enabled", use default passwort is enabled.

I trace the CAN communication with a 3rd party CAN tool.

I see exactly one CAN frame in the trace:

ID: 0x011, DLC: 8, 01 00 00 00 AA AA AA AA (hex)

Then RAppID BL Tool indicates "target not responding".

I then power-cycled my board and sent with a 3rd party CAN tool manually the following messages (500 kbit/s):

1) ID: 0x000, DLC: 0

2) ID: 0x011, DLC: 8, FE ED FA CE CA FE BE EF

And now I receive the echo from the MPC5775B: ID: 0x001, DLC: 8, FE ED FA CE CA FE BE EF

Therefore I conclude that the bootloader in general is running and the hardware including CAN transceiver etc. is working properly.

Question now would be:

What did I do wrong and how can I use the RAppID BL Tool to properly "talk" to the bootloader?

I would be very glad for hints.

Please let me know if you need further information.

Best regards,

Alex

P.S.: the MPC5775B is connected to a 40 MHz crystal, MCU_EVTO pin is pulled low via resistor, BOOTCFG[1] is HIGH. The target board and microcontroller are able to run an application software properly if it is directly flashed via JTAG.

Edit No. 1:

I think I am a step further! The RAppID BL Tool GUI comes with a file named "RAppidBL_MCU.rbm". In this file, I copied the line for MPC5777C and re-named it to MPC5775B. Then, I changed the parameter "BAM Type (Type of BAM implementation designated by a number)" from "0" to "1".

[MPC5777B]
RBF_Files\MPC5777C.rbf, 0x40000100, 0x4000, 115200, 115200, 1, 1, 0, 0

Now, I am able to select MPC5775B in the list of targets in the GUI:

And now, when I click "Start Boot Loader" it actually does do something:

So it does correctly begin with the AutoBaud-Rate negotiation and then following the "default password" and everything gets acknowledged by the MCU.
Just: after some time, it prompts an error that the communication was lost...

Edit Nr. 2

I repeated the experiment as follows:

1) instead of MPC5777C_S32DS_UART0_CAN0.rbf I now flashed the "original" MPC5777C.rbf which came directly with the RAppID BL Tool GUI.

2) the BOOTCFG of the microcontroller is now "jumpered" to [00].

Now, at least an erase operation seems to be working:

[egeonurg]

I see that you are trying to flash the bootloader area which is given below. 

I'm sure that, the application should be placed in any other place than the bootloader area. 

Also you can check the original topic below : 

https://community.nxp.com/t5/S32-Design-Studio/Rappid-Bootloader-on-MPC5777C/td-p/1414182

Edit: I'm currently aware that you are trying to use 5777C .rbf, this should be a problem too in RapidBL pow.

Best Wishes 

Ege

[fev_buergel]

Hi Ege,

I retried now and manually changed the memory address for my application to another area. The result is the same.

You are correct: I selected 5777C.rbf in the RAppID BL Tool GUI. MPC5775B MCU is not present in the GUI, since the GUI is from 2015 and the MCU itself exists only since ~2020. And there is no newer version of the GUI, as far as I can see...

Thanks for your support and contribution!

Best wishes,

Alex

[egeonurg]

Currently, I am not sure whether the MCU has bootloader code which you can flash the memory or not, RAppID BL Tool has a specific memory section in flash which you can find in the linker script.

First of all, you can check the memory region which is allocated for RAppID BL, whether it is including some hex code or not.

If this section is not empty, then you can find other ways to work with this BL.

Best wishes 

Ege

[fev_buergel]

Hello Ege,

perhaps you were right and I mixed some things up on how the RAppID BL Tool GUI works...

I did a new experiment now. This time, I had the BOOTCFG of the MPC5775B at 00 (which is "boot from internal flash").

When I now power-cycle the device and click the button in the GUI in fact there are some CAN frames being exchanged, but then it stops...

Do you happen to have an idea what's going on here?

Thank you and best regards,

Alex

[fev_buergel]

Hello Ege,

I am not quite sure if I understand you properly. Let me answer like this: I am sure that the bootloader is flashed onto the MCU (in the flash ROM). It must be there because it does reply to CAN frames which I manually send. There are only two devices connected to the CAN bus: my PC and the target board with the MPC5775B.

When I send the password CAN frame, then the bootloader replies by sending the echo (same content of the CAN frame, but different CAN ID).

What is not working is: use of the GUI (NXP RAppID BL Tool). I have the impression that it does not work, since the RAppID BL Tool does not: 1) send the "autobaud" frame and 2) does not send the appropriate password.

Both things together lead to the error "Loss communication...".

I tried to attach some screenshots showing the progress. (my RAppID BL Tool GUI setting, the error which is shown, the CAN frame which I trace and which comes from the RAppID BL Tool GUI and which "probably contains the wrong password" and the CAN trace which I receive from the MCU when I manually (!) send the autobaud frame and the password frame with the password I belive is correct)

[stanish · Accepted solution]

Hello,

RappID Booloader for MPC57xx does not use BAM so please disable BAM Setup in Bootloader app. and set the boot pins to boot from internal flash (as you already indicated)

I assume you assigned Bootloader App to the physical Vector CAN channel in Vector Hardware Config (please see “2.9 Enabling Vector Hardware” in the user manual): 

I noticed from the screenshots you are able to erase the flash so it seems there is no issue in CAN communication between RappID and your target board.

Are you able to dump a memory content using "read MCU memory" option e.g. (0x0080_0000-0x0080_FFFF)?

If you can dump and erase and there is an issue with programming only I suspect your s-record might overlap with booloader area (0x0000_0000 .. 0x0000_FFFF)

Hope it helps.

Stan

[fev_buergel]

Hello Stan,

thank you for your reply and support.

I can confirm that in the meantime also "flashing" (erase and program) does work with the RAppID BL Tool GUI.

The flashed software also is able to operate after having been flashed by the bootloader.

Therefore, this issue is solved. It was a misunderstanding on my side of the BAM pins in conjunction with the MPC57xx RappID Bootloader.

Edit:

I found a workaround in the meantime which for the moment is OK:

If my target pcb is not powered and no other nodes are connected to the CAN, I can click the "start boot loader" button in the GUI. Then an error prompt shows up "CAN error frame received" (which is correct, since the CAN frame is not acknowledged). When I then power up my target pcb, then the boot loader receives the CAN frame and waits for further data transfer. I can now close the previous error prompt which came from the GUI and click again the "start boot loader" button (while the boot loader is already waiting). 

With this workaround, I can re-enter the bootloader...

Nevertheless, perhaps I can take the chance and ask another related question: once the software is flashed, how can we "re-enter" the bootloader? In our old design which used the MPC5643L this was easy: we applied power to the MCU while the BAM pins were set to "wait for CAN serial bootloader". Now with the MPC57xx bootloader we cannot use the BAM pins of the MCU, therefore, when releasing it from reset, it "immediately" boots our application software and we see no way currently how we can enter the bootloader and make it work with the RAppID BL Tool GUI... would you happen to know a workaround for that?

Have a great day and thank you,

Alex

[stanish]

Hi,

There is a delay counter defined by  Bootloader Configuration Half Word within the target application binary (typically ~5s).

If the communication with the bootloader occurs within this delay you can program another image.

if you miss the delay the original application starts (if there is any image programmed).

For more information see e.g. RAppID Bootloader release notes (ReleaseNotes.pdf)

Size    Offset Value Description
(bytes) (bytes)
-----   ------ -------    -----------
4       0      0x0000005A RCHW
4       4      Address    Address of start of application
4       8      Delay      Delay in micro seconds before bootloader launches application on powerup
4       12     App key address   The location of application key. The application key value should be 0x55AA55AA 

Hope it helps.

Stan