Unable to Flash MBDT BootLoader to RDVCU5775EVM in S32DS per Quick Start Guide

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Unable to Flash MBDT BootLoader to RDVCU5775EVM in S32DS per Quick Start Guide

Jump to solution
12,737 Views
rsating
Contributor III

I'm getting started with Matlab/Simulnk MBDT examples with the following configuration:

RDVCU5775EVM - MPC5775B BMS Plus VCU Reference Design

Model-Based Design Toolbox for MPC57xx Series Version 3.2.0

Matlab/SImulink R2019b

S32 Design Studio 2.1

PE Microlink Universal

I'm following the workflow in the Model Based Design Toolbox Quick Start Guide:
https://www.nxp.com/docs/en/quick-reference-guide/MBDT-MPC57xx_QSG.pdf

I'm unable to complete Section 2.3 BootLoader setup, blocked by errors flashing the MCU seen in the 32DS console:

Programming.
Processing Object File Data ...
No data to program.
Error during programming.
Error Programming flash of device
Error occured during Flash programming.

Attached are screenshots of the S32DS configuration related to flashing the Bootloader to the MCU.

After pressing the "Flash" button I get several variable Input "Please input a value" which I leave blank and click the "OK" button. Are they benign? Or a sign of trouble?

I can run the S32DS getting started example in Chapter 3 of the RDVCU5775EVM User Guide:
https://www.nxp.com/docs/en/user-guide/RDVCU5775EVM_UG.pdf

So I now PE Microlink Unversal is connected properly and able to flash an application to the MCU.

The Matlab/Simulink MBDT examples all fail with message "Loss Communication with CCP MCU. Please cycle power and try again. The operation has timed out."  I get this same message trying to flash the MOT file "emios_pwm_opwmb_mpc5775e.mot" directly to the MCU using the BAppID Boot Loader Tool. I presume this is because is because BAppID Bootloader failed to flash to the MCU in S32DS as mentioned above.  

The MCU has both the PE Microlink (uses COM1) and a USB cable (uses COM3) connected to it, see photo of the setup.  I presume Matlab/Simulink or the BAppID Boot Loader Tool would communicate with the MCU through the USB cable (not through the Microlink) but I did try both.

The following community forum thread helped understand the process but not the solution:
https://community.nxp.com/t5/S32-Design-Studio-Knowledge-Base/RAppID-Bootloader-rbf-file-for-MPC5777...

I also tried flashing the BootLoader file "MPC5777C_S32DS_UART0_CAN0.srec" to the MCU using the PEMicro ICDPPC Nexus In-Circuit Debugger:
http://www.pemicro.com/products/product_viewDetails.cfm?product_id=15320089&productTab=1

It appears to flash the SREC S-Record file to the MCU without error, but Matlab/Simulink and the BAppID Boot Loader Tool are still unable to communicate with the MCU (same timeout errors), see attached screenshot for ICDPPC running with status window showing no error messages.

Could we get help overcoming the errors flashing the MBDT BootLoader to the MCU in S32DS?

Thanks

Labels (1)
0 Kudos
1 Solution
12,661 Views
mariuslucianand
NXP Employee
NXP Employee

Hello @rsating,

My colleagues from RAppID team provided the bootloader that uses the UART2 for the board you are using. I've attached the bootloader to this thread. Can you please flash it and perform a test?

Regards,

Marius

 

View solution in original post

0 Kudos
15 Replies
12,551 Views
rsating
Contributor III

Thanks for the fix!   Flashing the new bootloader to the MCU and again trying Matlab/Simulink MBDT quick start example, the RAppID Bootloader Progress dialog gets farther (Erase --> APP 0% --> APP 1% --> Init --> Error) but it still ends with the "CCP Communication Error" timeout dialog box. See attached screenshots. Any suggestions for further troubleshooting?

0 Kudos
12,551 Views
mariuslucianand
NXP Employee
NXP Employee

Hello @rsating ,

From the previous reply of @ranulf , I understand that on his side the new bootloader works, so can you please check that when you have flashed the new bootloader on the board, you have selected the alternative algorithm like here?

mariuslucianand_0-1603275156366.png

Regards,

Marius

0 Kudos
12,560 Views
mariuslucianand
NXP Employee
NXP Employee

Hello everyone,

I am glad that you are now able to run the generated code on the MCU board.

@ranulf, by flashing the rbf attached you are now able to program it directly from Simulink, right?

Regards,

Marius

0 Kudos
11,794 Views
ranulf
Contributor IV

@mariuslucianand, yes I am now able to directly program from Simulink.

0 Kudos
12,580 Views
ranulf
Contributor IV

Hi Marius,

Like rsating, I was not able to flash Simulink code onto the X-RDVCU5775EVM. However, with the information in this thread I have been able to do it. The S32DS approach you provided worked. The UART approach with bootloader you provided above worked. 

Thanks!

12,696 Views
mariuslucianand
NXP Employee
NXP Employee

Hello @rsating,

Thank you for all the details provided in this thread, I have identified the issue, but I need to contact the RappId bootloader team. Let me explain.

Unfortunately, the QSG you are mentioning refers to a previous version of or toolbox, the 3.0.0. The QSG for the 3.2.0 can be found directly in our toolbox, but I will attach it to this response. It contains an additional step for the MC5775B/E and MPC5777C which requires the usage of an alternative algorithm for flashing the bootloader only. But I think you already know this because you've found it on another thread on the community.

mariuslucianand_0-1602752973580.png

Now, the bootloader part.

The process is like this: The user flashes the bootloader on the board, which after reset, waits for the new firmware over the serial to be sent from the Simulink model, or from the RappID bootloader tool.

But the bootloader delivered with the toolbox is configured to wait over the eSCI_A, pins 89, 90. These pins are used as the main serial connection routed to USB on the majority of the evaluation boards for the MC3377x parts. But the board you have, has the the eSCI_C, pins 244 and 245, while the e_SCI_A has been routed to a LIN transceiver.

mariuslucianand_1-1602754218716.png

mariuslucianand_2-1602754330744.png

https://www.nxp.com/webapp/Download?colCode=RDVCU5775EVM_SCH

So this is the reason why the bootloader is not working: it wait s the code on another serial instance.

Now, I will contact the RappId bootloader team and reply with a response here, related to the Bootloader version.

Until then, you can bypass the Bootloader flashing method by using the S32DS. Basically, you have to m manually flash the Simulink generated code using the S32DS.

The easiest way to do that is to import an example for the MPC5777C, let's say Hello World. (Go to File -> New -> S32DS Project from Example)

mariuslucianand_3-1602754855354.png

Then go to debug, select the new created project, go to Browse and select the generated .elf by the SImulink project. Disable the autobuild and press Debug. 

mariuslucianand_4-1602755004927.png

 

Now the code should be deployed on the board and the code should run.

Hope this helps,

Marius

 

0 Kudos
12,702 Views
rsating
Contributor III

It turns out there are additional instructions in the Quick Start Guide document that is part of the NXP MBDT installation:
C:/Users/T5810/Documents/BanP/EV-models/NXP-MBD/Model_Based_Design_Toolbox_MPC57xx_Series_Quick_Start_Guide.pdf

The additional instructions "only for MPC5775B/E and MPC5777C" indicate the flashing algorithm must be changed, by selecting the PCP file "nxp_mpc5777c_1x32x64k_eeprom.pcp" from the PEMicro Eclipse plugin files, see attached.

Specifying the alternative flashing algorithm does appear to resolve the errors flashing the bootloader to the MCU.

However, I am still unable to build and run the Matlab/Simlink MBDT on the MCU. I'm still blocked by the "Loss Communication with CCP MCU" CCP Communication Error dialog.

This is a step in the right direction, but due to this error we are still unable to run any of the MBDT examples.

See attached screenshots:
Simulink MCU Configuration (MCU, Build Toolchain, Target Connection)
MCU USB Port COM3 driver properties
BAppID Boot Loader Tool with Error Dialog (same as from MBDT)
S32DS Flash Debugger Advanced Options PCP File Selection

Any hints to help move forward are greatly appreciated.

0 Kudos
12,662 Views
mariuslucianand
NXP Employee
NXP Employee

Hello @rsating,

My colleagues from RAppID team provided the bootloader that uses the UART2 for the board you are using. I've attached the bootloader to this thread. Can you please flash it and perform a test?

Regards,

Marius

 

0 Kudos
10,905 Views
1620773328
Contributor II

Hi Marius,

Can you share with me the source code project (S32_PA) for mpc5777c can bootloader ? I wanna do some advanced development based on your project. Thanks very much.

Regards

Jinus

0 Kudos
11,776 Views
rsating
Contributor III

Encouraged by the post from "ranulf" indicating the new bootloader worked, I tried again, in a fresh Matlab/Simulink session, starting over with a new model created by re-opening the "Hello World" block from the Library Browser under NXP examples. 

It took a couple tries (seems sensitive to timing of power-cycle before pressing OK in the "build" dialog box that asks us to reset the MCU) but today Simulink successfully downloaded the result of the model build to the MCU. 

I noticed pressing Reset on the MCU worked (did not have to power-cycle the board), which is good. It is more trouble to power-cycle the board.

I noticed we do not need to re-flash the bootloader in S32DS before each build in Matlab/Simulink, which is good.  This was not clear at first, I had to try it to find out. 

Trying to connect TeraTerm to COM3 (the USB serial port assigned to the board and used by Matlab/Simulink to download the model build to the board) that I did not see the "Hello World!!!" messages. Trying various changes to work around the problem, I discovered that if we change the UART instance from 1 to 2, the "Pins" tab of the "UART Config" block a new and different set of pin selections for RX and TX that were not available for (default) UART instance 1, see below.

MBDT_HelloWorld_UART-config.png

Making this change allowed the serial output stream to reach TeraTerm using the same port COM3 that was silent when (default) UART instance 1 was tried.

MBDT_HelloWorld_TeraTerm-output.png

How does the "UART Module" (UART index selection) affect our design?
Why does UART index 1 not work, even with Matlab/Simulink closed?
It would be great to better understand how this works.

I suggest changing the "Hello World" example "UART Module" (UART index) selection from 1 to 2 in a future release of the toolbox, or mention it in the Quick Start Guide, since it seems to be required for the example to work (seeing serial output).

0 Kudos
11,704 Views
rsating
Contributor III

The reference design schematic shows why UART Module 2 has to be selected:

RDVCU5775EVM reference design – Schematic

In the schematic (see below) it shows that only RXDC and TXDC on the Microcontroller connect to the UART, the last letter "C" in the name of those pins corresponds with UART Module 2.  When UART 2 is selected in the MBDT "UART Config" block, pins [eSCI_C_RXDC] and [eSCI_C_TXDC] become available in the "Pins" property page; those correspond to the pins connected to the UART on the schematic.

A future version of the Quick Start Guide for RDVCU5775EVM deserves to be updated to mention this setting.

RDVCU5775EVM_SCH_U2C.png

RDVCU5775EVM_SCH_UART.png

0 Kudos
11,699 Views
mariuslucianand
NXP Employee
NXP Employee

Hello @rsating ,

I am glad that finally the new bootloader works on your side! This was actually the problem: the board that you are using has the UARTC/UART3 pins as UART while the boards that we used for developing are using UARTA/UART1. This board was not yet available when the toolbox was released.

All your assumptions are right: you can press the reset button to flash the board and also you only have to flash the bootloader once.

Regarding the UART instances, in our toolbox we have countered the UART instances starting from 0, where 0 is eSCIA, 1 i s eSCIB and so on. We only display the pins assigned to a certain instance, so in order to use certain pins, you have to select before the instance that you want to use.

Regards,

Marius

0 Kudos
12,522 Views
rsating
Contributor III

Thanks for providing a possible fix so quickly.  I tried flashing the MCU with the new bootloader and in Matlab/Simulink building (and running) the Quick Start MBDT example.

The process gets further, interacting with the bootloader, with the BAppID Bootloader Progress dialog progressing through a few steps, but it ultimately still fail, with the CCP Communication Error (the operation has timed out) dialog displayed at the endpoint.

The progress dialog shows steps: Erasing, App 0%, App 1%, Init

Timeout happens at the "Init" step, after a few seconds spent at that step.

Any suggestions?  Anything logs or status we could provide to help troubleshoot?

Thanks!

 

0 Kudos
12,379 Views
mariuslucianand
NXP Employee
NXP Employee

Hello @rsating ,

My suggestion, as posted previously is to make sure that you have selected the alternative flashing algorithm as mentioned in this thread yesterday. You will find my answer above.

Can you show me the flashing debug settings from the S32DS in which you are flashing the rbf file?

 

Regards,

Marius

 

0 Kudos
12,373 Views
rsating
Contributor III

Attached are screenshots of the relevant settings. I hope this helps.

0 Kudos