MBD tool with PIL mode

[karychang1234]

Hi All:

I try to use MBD tool for Simulink model with PIL mode. I have two question about this.

My environment:

Windows 7 64bit 

MATLAB 2016b

S32 power v1.1

DEVKIT-MPC5744P board

1.When I run the model, model will build and try to programming the code to the MCU with SDA serial port(COM3).

   But in my side, it is very hard to connect to the MCU. I got an error below:

Very very few times I can programming the code to the MCU.

2.I have a SDA serial port with COM3, but for the PIL , I need to use LIN or CAN for data transmission.

That means I need to connect USB2RS232(It will has a COM9 port) adaptor to my computer and connect the RS232 port to the LIN port of the DEVKIT board. Model setting should be as below, right?

[dumitru-daniel_]

Hi karychang‌,

Please have a look over this video  Video Link : 7845 at 4'30'' to see how to configure the model for running PIL on MPC5744P (or any other processor supported by MBDT)

If you are using the MPC5744P DevKit then the UART instance associated with the OpenSDA microusb port is UART1.

Since PIL is basically a simulation - you do not need to enable the FreeMASTER. Just keep it disabled - all the variables from the MCU can be displayed using the standard Matlab Scopes.

So please do the following:

- connect the USB cable between your PC and the OpenSDA microusb port on the board.

- check the COM port assigned for OpenSDA

- configure "PIL and Download Config" Panel as you did before but with correct COM and SERIAL1 interface for the PIL

- disable the FreeMASTER support from "FreeMASTER Config"

That should do the trick.

Hope this helps!

Daniel

[markusransberge]

Hi Daniel,

sorry for keeping you busy, but I got a question about the RAppID bootloader and this post is pretty similar to my experience with it.

If I do the following steps:

I) Flash the RAppID bootloader onto the board via JTAG.

II) Flash a .srec file via "RAppID Boot Loader Utility" onto flash memory. (Reset Button -> Press "Start Boot Loader" in App)

III) Then try to flash another .srec file onto the board (also (Reset Button -> Press "Start Boot Loader" in App in less than 1-2 seconds)...

and it does not work anymore (same error message as in the first screenshot). Is the RAppID Boot Loader Utility erasing the bootloader itself or does it change the entry point to the start of the program it flashes, so that it does not actually jump to the bootloader on startup?

So the question is: How can I use the bootloader multiple times in a row without reflashing it with JTAG every time?

Thank you.

Kind regards,

Markus R.

[dumitru-daniel_]

Hi markusransberger‌,

That should not happed. Once you have program the flash algorithm (RBF) file via JTAG is should allow you to reprogram the board/processor as many times you need without the need of JTAG.

Still, there might be 2 issues that might explain your scenario:

- you are not using the correct RFB file: e.g. for MPC5744P DevKit you should use:

- your srec/application is built with an incorrect linker command file that might allocate application code over the flash segment assigned for BAM and overwrites its section and flash algorithm is lost. 

Can you check in which of the above situations you are ?

Best regards,
Daniel

[kaushik_subrama]

Hi Daniel,

Could you please elaborate on how to solve the below mentioned issue:

your srec/application is built with an incorrect linker command file that might allocate application code over the flash segment assigned for BAM and overwrites its section and flash algorithm is lost

[dumitru-daniel_]

Hi Kaushik,

It depends on your settings. Currently the BAM supports works for RAM targets. Once you select RAM target to build the application for and UART as download peripherals then the ***_RAM_BAM linker should be chosen. 

Anyhow, if there is a mistake in the linker, then all you have to do is to rearrange the sections not to overlap with flash algorithm. An easy way to do that is to use the custom linker files. Just create a new linker file, save it in the src\mbdtbx_pnt\src\s32ds_specific_files directory, restart MATLAB and then the toolbox should be able to see it in the list and allows you to use it for build process. 

Hope this helps!

Daniel

[markusransberge]

Hi Daniel,

I think that I'm doing both of your mentioned things correctly. I used the MPC5744P_DEVKIT.rbf, renamed it to MPC5744P_DEVKIT.srec to be recognized as flash-able file by PE Micro's ICDPPCNEXUS Debugger/Flash program (newest version, most recent flash script) and wrote it into the EEPROM. Afterwards I flashed my "test_program.srec" with the RAppID Boot Loader Utility with following configuration:

Here you can see the address ranges of the renamed .rbf file and my test program I compiled with S32 IDE 1.2.

And here you can see the that the first address it jumps to after a reset is indeed the bootloader.

Also you can see the values of the addresses here:

So I'd guess that something is not right since 0xF98008 and 0xF9800C have only F in them. And this is the relavant excerpt of the RAppID manual:

So what can I try now?

Kind regards,

Markus R.

[dumitru-daniel_]

Hi markusransberger‌,

Is there any particular reason for not using the S32DS debugger to program the the RBF file directly into flash memory via the PE micro JTAG ?

Is your probe recognized by the S32DS debugger as a valid connection to the target ? If that is true, then just create a simple test project in S32DS and replace the elf file with the rbf file and that will program the flash algorithm into the FLASH memory.

Perhaps something in the PE micro flashing algorithm is not working as supposed compared to S32DS debugger.

Hope this helps!

Daniel

[markusransberge]

Hi dumitru-daniel.popa

there is not really a reason I used the flash tool by PE Micro. But I tested it again with the S32DS debugger and even with a brand-new board. And the same thing happens: you can use the RAppID bootloader utility exactly ONCE and then it won't work anymore for further flash operations.

Just to be sure that I'm doing this right: You press the reset button (SW3) and then press "Start Boot Loader" in the RAppID BL Tool in less than 1-2 seconds and it should do its job. I also tested both powering possibilities (USB / External 12V), but this does not make a difference.

Btw the flash scripts (.pcp files) provided with S32DS and by PE Micro only differ in the last line of code. (Hexadecimal: NXP: "E8 34" vs Freescale: "7A D7"), so I'd guess it's not the flash file's fault, right?

Here the programming log from S32DS:

Here is the memory content (of the new board) and it looks identical to the other one.

So am I doing something wrong?

Kind regards,

Markus R.

[dumitru-daniel_]

Hi markusransberger‌,

Honestly, i do not know what is going on but i hope we will find out together.

Here are by board, CPU and jumper settings:

Board: rev x1

CPU: 1N15P. If the CPU has another code - it might be possible to require a different RBF file for that particular revision. I'm not sure but base on your CPU code we can double check with our internal teams.

Jumpers:

The S32DS log after flashing shows this:

Connection from "127.0.0.1" via 127.0.0.1
Copyright 2012 P&E Microcomputer Systems,Inc.
Command Line :C:\NXP\S32DS_Power_v1.2\eclipse\plugins\com.pemicro.debug.gdbjtag.ppc_1.6.7.201706090048\win32\pegdbserver_power_console -device=MPC5744P -startserver -singlesession -serverport=7224 -gdbmiport=6224 -interface=OPENSDA -speed=5000 -port=USB1Ø

CMD>RE

Initializing.
MPC5744P Device detected.
Target has been RESET and is active.
CMD>CM C:\NXP\S32DS_Power_v1.2\eclipse\plugins\com.pemicro.debug.gdbjtag.ppc_1.6.7.201706090048\win32\gdi\P&E\nxp_mpc5744p_1x32x616k_cflash.pcp

Initializing.
MPC5744P Device detected.
Initialized.

;version 1.05, 12/13/2016, Copyright P&E Microcomputer Systems, www.pemicro.com [5744P_2464k]

;device NXP, MPC5744P, 1x32x616k, desc=CFlash

;begin_cs device=$00F98000, length=$00268000, ram=$40000000

Loading programming algorithm ...

WARNING - Selected .PCP file has been modified. CRC16 = $B89D
Done.
CMD>VC
Verifying object file CRC-16 to device ranges ...
block 00F98000-00F98007 ...
Calculated CRC-16 does not match block. (File = $9E7A, Device = $9A8A)

CMD>EM

Erasing.
Module has been erased.
CMD>PM

Programming.
Processing Object File Data ...


.
Programmed.
CMD>VC
Verifying object file CRC-16 to device ranges ...
block 00F98000-00F98007 ...
Ok.
block 00F98010-00F996D1 ...
Ok.
block 00F996D4-00F9A11B ...
Ok.
Checksum Verification Successful. (Cumulative CRC-16=$3BE9)

CMD>RE

Initializing.
MPC5744P Device detected.
Target has been RESET and is active.

Starting reset script (C:\NXP\S32DS_Power_v1.2\eclipse\plugins\com.pemicro.debug.gdbjtag.ppc_1.6.7.201706090048\win32\gdi\P&E\s32e200_mpc574xp.mac) ...
REM This script is compatible with MPC574xP devices.
REM Clean GPRs to remove residual data after using algorithm
REM Initialize all of the Main SRAM - 384KB
Initializing RAM from $40000000 to $4005FFFF.
REM Core 0 D-MEM 64K
Initializing RAM from $50800000 to $5080FFFF.

Reset script (C:\NXP\S32DS_Power_v1.2\eclipse\plugins\com.pemicro.debug.gdbjtag.ppc_1.6.7.201706090048\win32\gdi\P&E\s32e200_mpc574xp.mac) completed.

MPC5744P Device detected.
Interrupt command received. Halting execution.
No breakpoints currently set.
Disconnected from "127.0.0.1" via 127.0.0.1
Target Disconnected.
Target Disconnected.

Based on these settings i can re-program the application as many times as i need without the need to re-flash the RBF file.

One think to mentions here (might not be applicable but worth trying) - can you check the value of the R17 resistor. It should be 1K or closed that value.

Best regards,
Daniel

[markusransberge]

Hi again,

here are my findings:

The little sticker on the backside of the board is identical to yours, it reads: "700-29333 REV X1 SCH-29333 REV B". On the packaging however it says "(2P)REV: X2". So I'm not too sure about my revision number.

CPU Code number is almost the same as yours: "SPC5744PFMLQ9 1N15P QQAL1621T".

My jumper settings were pretty much the same. I only had J31 and J39 in their standard unjumpered configuration and the rest is identical. But these two are for external power input over the pin headers afaik.

S32 log is also identical. The BL is flashed onto the board which I can confirm with the debugger.

In RAppID BL Tool I'm using the same options. (I mean I'm using COM8, but that should not be a problem...) Still works only one time, then the connection times out/is lost.

And I can confirm: R17 is a 1k resistor on my boards.

So I'm almost out of ideas now. (I'll try running the RAppID program with admin rights some time later, maybe that's a reason, but I don't think so.) Could you check the registers F98008 and F9800C for their values if you got time? I'd like to know if that's the reason why it doesn't work for me.

Kind regards,

Markus R.

[dumitru-daniel_]

Hi markusransberger‌,

I'm not sure i understood the address you wish to compare.

Could you check the registers F98008 and F9800C for their values if you got time?

The memory content @0xF98008 and 0xF9800C are 0xFFFF FFFF

While the register NCR @0xFFF98008 is 0x0

Is this the information you are looking for ?

Best regards,
Daniel

PS: petervlna‌, lukaszadrapa‌ have you ever encountered such behavior on other MPC families. Just to summarize: after writing the RBF in the flash, once you download the application via RAppID Bootloader, the RBF is somehow erase and you need to reflash it again.

[markusransberge]

Hello again,

thank you for providing the screenshots. So it does not actually break because of these values in those registers. The is pretty clear about the use of those registers, though. Isn't it?

Please hit me up if there is an update from your side.

EDIT:

I got an update,dumitru-daniel.popa‌.

I got it to work when I'm exclusively using it with generated Matlab/Simulink files. I can use the RAppID BL Tool several times in a row then (directly in Simulink and manually outside of it)! To test if there is a problem with .srec files, I converted the MATLAB/Simulink .elf file with objcopy manually into a .srec. And I was able to flash the .srec file several times in a row, so it's not a problem with the file type.

But: If I use the tool with .srec files compiled by S32DS it only works once as before. So I'd guess I have to add some code to my source files in S32DS or change some build options?

EDIT2:

I just realized that I was wrong on the addresses. The valid .rchw is at 0x00FA0000 and not at 0x00F98000, so the interesting bytes are at 0x00FA0008 and 0x00FA000C respectively. These two are not being written if the program is compiled with S32DS. And that's why this is happening. Do I have to manually add code to write the right values to the registers?

Kind regards,

Markus R.

[dumitru-daniel_]

Hi markusransberger‌,

Do you have this code in your main.c application when compiling with S32DS ?

const volatile uint32_t APPKEY __attribute__ ((section(".appkey"))) = 0x55AA55AA;
const volatile uint32_t RCHW __attribute__ ((section(".apploc"))) = 0x015A015A;
const volatile uint32_t APP __attribute__ ((section(".apploc"))) = (uint32_t)Reset_Handler;
const volatile uint32_t DELAY __attribute__ ((section(".apploc"))) = 0x00500000;
const volatile uint32_t APPLOC __attribute__ ((section(".apploc"))) = (uint32_t)&APPKEY;

Best regards,

Daniel

[markusransberge]

Hi again,

as expected, I did not. I just compared the linker files of MATLAB/Simulink and S32DS. And found out where these registers are being written. I also found the following values in the auto-generated main.

const uint32_t appKey __attribute__((__section__(".appKey"))) = 0x55AA55AA;
const uint32_t appDelay __attribute__((__section__(".appDelay"))) = 5000000;
const uint32_t appKeyAddr __attribute__((__section__(".appKeyAddr"))) =  ( uint32_t )&appKey;

Sorry for causing this much headache for you. I were on the wrong path too long and was expecting that the RAppID tool would work right out the box with a S32DS project. Well, my bad, I was mistaken and dug at the wrong place.

I got it working some minutes ago after I edited the Linker file and added these three lines to my main. Thank you very much dealing with my problem so promptly! All good now.

Kind regards,

Markus R.

[dumitru-daniel_]

Hi markusransberger‌,

Glad to hear you have figure it out. That's the spirit we need on this community: sharing knowledge until we fix the problem :-)

Best regards,
Daniel