MPC5744P Dev fails to launch App after reset if >64K

[stuart_jobbins]

NXP MBDT runs perfectly on MPC5744P and runs motor using MotorGD board until....

... I expand the application code such that the Flash segment runs beyond 0xFFFFH (i.e. from 0x01000000 to above 0x01010000).... and at that point it fails to come out of reset to start application. Reduce it below the magic 0x1010000H(such that .appKey resides in the first 64K) and it all works... highly repeatable.. and doesn't care which code I include/exclude to get the effect.

The MOT file appears correct, and includes all the Bootloader requirements of RCHW, address of application start, timeout value, address of appkey.... all pointing to the correct addresses and the appkey is clearly present at the right address in the .Mot S-records.

I can't see any 'memory size' model style restrictions in the build (running the automatic S32DS and RAppID elements, or standalone build and programming tools).. also tried changing the Default Target Memory Definition in Matlab - same result (works OK when smaller than 64K flash, not when above). RAppID reports correct size (from S-records) in each case.

Have I missed something that needs to be set to allow me to 'grow' the code size? (I have lots more to implement - but don't expect final size to be >128K of Flash).

App RAM usage is trivial at >16K (at Location 0x40000000 up) . Stacks and Heap etc are at 0x50800000 and are unchanged .. approx allocated 0x1000 each)

Failure example

S0130000534A5F4D435F4D6F64656C332E6D6F745F
S30900FA0000005A0001A1
S30900FA000401000000F7
S30900FA0008004C4B401D
S30900FA000C0101009C52
S315010000007C00014670000000702000007040000076

...

S31101010090BE2AA7C000000000800000008D
S3090101009C55AA55AA5A
S315010100A0011B033B0000001800000002FFFF2E9018
S311010100B000000030FFFF3E98000000A494

...

S315010113B802625A000100E9900100E9A80100E9F079
S315010113C80100EA080100E9C00100E9D8340000007A
S70501000000F9

Success Example (same build some content commented out before recompiling)

S0130000534A5F4D435F4D6F64656C332E6D6F745F
S30900FA0000005A0001A1
S30900FA000401000000F7
S30900FA0008004C4B401D
S30900FA000C0100FEAC45
S315010000007C00014670000000702000007040000076

...

S3110100FEA0BE2AA7C0000000008000000080
S3090100FEAC55AA55AA4D
S3150100FEB0011B033B0000001800000002FFFF308019
S3110100FEC000000030FFFF4088000000A495

...

S315010111C802625A000100E7980100E7B00100E7F859
S315010111D80100E8100100E7C80100E7E0340000005A
S70501000000F9

[rehab_hassan]

Hello 

Any updates regarding this issue? 

I have a similar issue as after flashing code doesn't start but with s32 it works

[mariuslucianand]

Hello stuart.jobbins@tiscali.co.uk‌,

Does the RappId Bootloader flashes the code on the CPU? Are you sure it is related to the memory size?

What does 'fails to launch App' mean? Does the mcu boot, gets into main function and after that the code ends up inside a fault handler or the mcu keeps run the bootloader?

Can you send us the working and not working example?

Best Regards,

Marius

[stuart_jobbins]

Hi Marius,

RAppID BL finishes successfully (at least the GUI suggests it flashes OK), but the application doesn't start. (The app is a modified PMSM MBDT FOC motor... and the LEDs don't light after reset if code size >0xFFFFH, but start normally if its below that size.)

Can't communicate with target with FreeMaster either, if above 0xFFFFH, but OK if below. Been working a month, and only just realised my recent random failures were to do with build size, not my code!

No debug tools, just commenting out bits of Simulink blocks to get size down always gets the target going.

No idea how to tell if memory is flashed OK - as no way to communicate when too large/unsuccessful. Equally can't tell what is running.. reset light blinks on/off at reset.. then nothing... but no idea why.

Is there any easy way to diagnose if main has been launched.. just with a scope?.. i.e. can I tell from any early GPIO port initialization?

It's not possible to share the application, so I'll have to emulate its size...I'll try and create a 'dumb' set of text into a standard MBDT PMSM build to make it over 64K and still see if it happens.

Would the 'fault handler' give any visible indication (or scope-able)? (I haven't written any fault handler... so unless there is any in the standard PMSM, it won't be going there! As I say, it runs fine, no faults when I rip out everything to get it below 64K - so currently living without Profiling, Freemaster etc to keep size down!).

Cheers for the help,

Stuart

[mariuslucianand]

Hello stuart.jobbins@tiscali.co.uk‌,

It is very hard for me to help you solving the problem without the model.

No debug tools, just commenting out bits of Simulink blocks to get size down always gets the target going.

My assumption is that the code size has nothing to do with the fact that the model is not working as expected. What I believe is that in the code you comment in order to work, there is a handler which is initialized before the code initialize the peripheral. For example the Simulink priority for any config block must be greater than the Interrupt handler for that peripheral. This is the main cause for this to happen. You can always import your generated code inside the S32DS for Power Architecture here and try debugging it line by line. 

If this is not solving your problem, please consider sending me the model in private.

Hope this helps,

Marius

[stuart_jobbins]

Hi Marius,

I am not taking out ANY configuration content.. and its still working as long as I keep total size below 64K, which I achieve by typically by leaving out FreeMaster, Profiling etc as well as some of my App.. but that leaves me blind for debugging.

I can show that ALL parts of the model work (by testing them individually on target, keeping below the 64K), but ANY composite model (tried MANY combinations)  that extends beyond 64K fails to start from reset after target is reflashed.

It is definitely code size related.

The RAppID BL seems quite an ancient version... Am I using the latest?

How do I send you a private version of model?

Many thanks,

Stuart

[stuart_jobbins]

Having accepted (by private message) that here is a fault in the MPC5744P RAppID BL for code >64K, is there going to be an update? For those of us working in Matlab, the workaround is a real pain in the workflow!

Regards,

Stuart

[mariuslucianand]

Hello stuart.jobbins@tiscali.co.uk‌,

Can you confirm that the code with a size >64K works by flashing it directly using the S32DS? It will help us addressing this to the RappID BL.

Best Regards,

Marius

[stuart_jobbins]

Yes it appears to work through S32DS with images >64K.

[mariuslucianand]

Hello stuart.jobbins@tiscali.co.uk‌,

Than you for your response! This has been reported to the Bootloader team as RBL-137. I will reply here their response once I have it.

Best Regards,

Marius

[stuart_jobbins]

Apologies, Forgot to detail set-up:

Hardware: MPC5744P Dev Kit and DEVKIT-MOTORGD - running a Trinamics QBL4208-61-04-013 motor.

Software: NXP_MBDToolbox_MPC57xx Series 3.0.0 Release, AMMCLIB V1.1.15, S32DS PA2017.R1, Matlab 2018b, RAppID BL 1.6.7.35