Problem with DEVKIT-MPC5744P serial bootloader - after flash - app won't run after POR

[ones_and_zeroes]

Problem with DEVKIT-MPC5744P serial bootloader - using RAppID BL - after flash - app won't run after POR

Succesfully programmed in the RAppID BL bootloader for MPC5744P- no problems...

filename: MPC5744P.rbf -> as provided by the RAppID BL install package

using a PE Multilink Universal FX over JTAG

using S32DS - "Flash from file..." -dialog - so far so good

Set up RAppID BL Tool for:

Serial Port - Com Port designation for DEVKIT-MPC5744P OpenSDA serial port interface - 115200

MCU Part No: MPC574xP

BAM Setup -> Disabled - evidently not supported for MPC5744P for this tool, if at all.

Application file -> MyApplication.srec

Auto Read File -> unchecked

automatically filled -> Start Address 0xFA0000

automatically filled -> Code Size Range 0x63488

Operation Setup: RadioButton "Erase and Program" selected

Enable Trace -> checked

Upon Clicking the "Start Boot Loader" button of the RAppID BL Tool User Interface, status messages show proper erasure and programming

Application runs as expected - twiggles the DEVKIT's LED - sends a test packet out the CAN bus, etc.

So Far So Good (SFSG) - except, If the DEVKIT has it's reset button pressed - the program does not run

Not being sure if the previously programmed bootloader was wiped by the RAppID BL tool, reconnected with S32DS and the PE debugger to try and flash the bootloader again, and that failed, as the bootloader was already there - so that's good, the bootloader stayed resident in code after a RAppID BL flash, as expected.

Flashed in the application code's .srec file again, successful flash, program runs, but this time power was removed and re-applied - and program does not run

In preparation for bootloader, the application project's linker command file and main.c were modifed as follows - maybe incorrectly....in that the bootloader (MPC5744P.rbf) does not appear to jump to the application properly when the bootloader is not being called for.

In my S32DS IDE project for the application, file 57xx_flash.ld was modifed as follows:

within MEMORY {}

added

/* added for rbf bootloader support - 1 of 2 */

delay_us : org = 0x00FA0008, len = 0x4

/* added for rbf bootloader support - 2 of 2 */

appkey_addr : org = 0x00FA000C, len = 0x4

within SECTIONS {}

added

/* added for rbf bootloader support */

.appkey_addr :

{

KEEP(*(.appkey_addr))

} > appkey_addr

/* added for rbf bootloader support */

.usdelay :

{

KEEP(*(.usdelay))

} > delay_us

in main.c - added these bootloader reserved memory and assignments

// .rbf bootloader support constants

const volatile uint32_t __attribute__ ((section(".appkey"))) APPKEY = 0x55AA55AA;

const volatile uint32_t __attribute__ ((section(".usdelay"))) BLDELAY = 0x2DC6C0; //3 sec delay

const volatile uint32_t __attribute__ ((section(".appkey_addr"))) APPKEY_ADDR = &APPKEY;

Questions:

I recall a mention of a 2nd interrupt vector table or such - is that what is missing?

Should there be a memory field assigned to the start address of the application?

Or is that implicit by what flash block we start at?

Note that our test application was ported from the DEVKIT-MPC5744P demo project FlexCAN_MPC5744P - which works fine in debug mode on both a DEVKIT-MPC5744P and a RD33771 demo board.

[anthonym]

@lukaszadrapa I am having the exact same issue. Is there some solution for this or any alternatives that you know of? I've also tried modifying the MPC5748G Bootloader and had the same bug still come up.

[ones_and_zeroes]

OP Additional Info:

The project used above had in it's main.c this directive

__attribute__ ((section(".text")))

located after the designation of APPKEY, BLDELAY, and APPKEY_ADDR

and before int main(void){....}

I got the bootloader friendly linker command file and main() file directives from the demo program that comes with the RD33771 demo board .

project "Eval_MC3377X_New48V" which has not yet been tested here with the RAppID BL tool

Interestingly, the Eval_MC3377X_New48V does not appear to have the __attribute__ ((section(".text"))) directive in it's main() file (BMS_5744P_main.c)

[stanish]

Hello,

Since .text is a default code section it is not required to have it above main(). You can check in .map file that main() is placed into .text section even without the attribute.

I'd suggest you to use RAppID BL app to dump address range 0x00FA0000 .. 0x00FA000F after POR.

Please compare it with expected values:

0x00FA0000: RCHW,
0x00FA0004: Reset Vector,
0x00FA0008: Delay,
0x00FA000C: Appkey_addr

Now, when you get Appkey_addr, please dump this address as well into another dummy srec. the file should contain the pattern "0x55AA55AA"

I don't see appkey placement in your snippet, but you can place it at the end of .text section e.g.

.text :
{
 *(.text.startup)
 *(.text)
 KEEP(*(.appkey))
 KEEP(*(.init))
 KEEP(*(.fini))
} > m_text

if it all matches there is no issue with the application boot header.

If you are not able to dump via RappID BL within 3s there might be e.g. corrupted delay.

Last but not least you might try to use Pemicro probe to load both BL rbf + app, invoke debugger reset and debug it.

This could be done simply by adding MPC5744P.rbf into the debug configuration -> "Specify the number of additional object files..." set to 1 and enter path"to rbf file into field "Specify Additional Object file 1".

Now when you press debug button both files are being programmed into MCU. 

There is no source code available to .rbf file but at least you can identify if the problem is in BL or you reached (jumped) to app entry point or narrow down the place where the code crashes after reset.

Hope it helps.

Regards,

Stan

[anthonym]

Thank you for the response,

I have completed the steps you have provided exactly and am still having the same issue. Not sure what it is at this point. The solution you gave seems like a derivative of the guide  https://community.nxp.com/t5/S32-Design-Studio-Knowledge-Base/HOWTO-Use-RAppID-BL-tool-with-MPC5744P... which also did not solve the problem.

When I use the RBL App it times out every time regardless of debug configurations, and after flashing via SREC file and including the MPC5744P.rbf file, it still does not power up on reset.

Do you have any additional steps that may be of assistance or links to any other resources or tutorials for similar issues? Let me know any additional info you may need to assist me

Thanks for the help

[mikedoidge]

Hi Anthony,

You might try using a debugger in attach mode to determine where the core is getting stuck. This will help to understand what is going wrong.

Best Regards,

Mike