MPC5777M standalone startup problem

[chrisgerlinsky]

Using the MPC5777M EVB motherboard and MPC5777M_416DS daughtercard, I am able to run a test program from flash when debugging using PEmicro Cyclone, but without the debugger running the software does not run.

The first thing I do in main() is to set PA0 low, and even this does not occur unless the debugger is connected and running.  After resetting the MPC5777M, main() doesn't appear to run.  When I read flash, the boot header looks correct and points to the program in flash (looks OK as far as I can tell).

The software is a simple UART test program (based on Example-MPC5777M-LINFlex2-UART-echo-SWpoll-v1_0-GHS614.zip).  To create the software I made a new project using S32 Design Studio and copied the example code into main.c (code attached).  This is a simple program that runs on the IOP CPU only.

Any help to identify what I'm missing that prevents the software starting in standalone mode on the MPC5777M EVB would be appreciated!

Original Attachment has been moved to: testuart_MPC5777M.zip

[petervlna]

Hi,

I have tested your example and it is running stand-alone with any issues.

After reset I always get in main,.. while loop.

I am using cut 0N50N.

Which one are you using?

Peter

[chrisgerlinsky]

Hi Peter, thanks for your response.

I have the same problem when testing with PPC5777M2MVU8B ON50N and a SPC5777MMVU8 ON50N chips.

With the JTAG debugger connected and running, the software starts properly, PA0 goes low, and the "Hello World!" string is transmitted by UART.

With nothing connected to JTAG, PA0 isn't pulled low and nothing is transmitted by UART. (the same for reset or power-on)

[petervlna]

Ok, but when you run it in standalone mode and then do attach with debugger?

Are you in the loop as I am?

It is working also for you when you are connected with JTAG and you do a reset via debugger?

Or it is running only after code is loaded in flash and not after JTAG reset?

Peter

[chrisgerlinsky]

When I reset the EVB and then attach with debugger (with 'attach to running target' selected in the startup tab of the debug configuration), if I suspend the program it is in the loop as you are.

However, sending any data to the UART doesn't break the loop.  (and no data was sent out the UART before entering that loop)  If I look in EmbSys Registers:

LinFlexD_2.LINCR1 = 0x00000090 (expected 0x00000080, set in LINFlexD_2_Init())

LinFlexD_2.UARTCR = 0x00000033 (as expected)

LinFlexD_2.LINSR = 0x00002000

LINFBRR and LINIBRR are set as expected.  

SIUL2.MSCR_IO_62 = 0x00090000 (expected 0x32090002, set in SIUL2_Init())

SIUL2.MSCR_MUX_850 = 0x00000000 (expected 0x00000001, set in SIUL2_Init())

If I try to change the value of SIUL2.MSCR_IO_62 or SIUL2.MSCR_MUX_850 in the EmbSys Registers view, it has no effect (value doesn't change).

Also, PA0 has not been pulled low.  Even when watching PA0 with logic analyzer, it is not pulled low even momentarily after reset.

Viewing in EmbSys Registers when attached with debugger after standalone boot:

SIUL2.MSCR_IO_0 = 0x00090000  (should be set to 0x12380000 in main())

GPDO0 = 0x00

Thank you for your help troubleshooting this!

[petervlna · Accepted solution]

Hi,

your ME_PCTL for SIUL2 is not active.

In other words there is no clock for SIUL2 module.

Configure ME correctly as this cut of device is disabling SIUL in BAF.

In you application you have to enable MC_ME_PCTL15 for target mode and do mode translation. Then it will work.

Otherwise the pins wont be active.

Peter

[chrisgerlinsky]

Is a list of which cuts are affected by the disable of SIUL by BAF available?  Are there additional errata documents available for the MPC5777M?

Thank you

[petervlna]

No list is needed as this is only on cut 0N50N.

I don't think this is errata as this is no HW issue.

Anyway user has to configure SIUL and ME before he want to use it.

Your issue was that you run example code developed for older cut with different BAF.

Peter

[chrisgerlinsky]

Setting MC_ME_PCTL15 solved the problem.  Thank you, Peter!  

I added the line MC_ME.PCTL15.R = 0; before the last mode transition to enter RUN0 mode in SysClk_Init() and it is working correctly.  (MC_ME.RUN_PC[0] was already set correctly in the software)

Thanks again Peter!