MPC5747G reset issue

[park_kwangsoo]

Hello,

Micom has been reset for some reason, and as a result, issues such as flickering etc. are reported.

mostly log tell F_SWT0_RES bit set. or cannot detect reason.

currently, log can detect below reason. 

F_SWT0_RES ( mostly, issue detected this )

F_FUNC_ESC

F_SSCM_SEC

F_SOFT_DEST

F_HSM_DEST

F_EXR

we don't remains all DES or FES currently.

so, I will expand this. but trying to reproduce issue is very difficult.

I want to know how to fix it or find root cause of sudden reset (we don't want reset)

I am not sure what I can do for solving this problem. Need help

thanks

+) there is one ISR make swt0 reset. wdg. what can I do in this situation.

ISR(Wdg_Swt0_Isr)

0xFC050000UL&0x00000040UL

0xFC050000UL&0x00000001UL

[petervlna]

Hi,

this will require some debugging.

First disable SWT. So you can see where the program is stuck and you can exclude SWT.

If possible test the SW on sample where the HSM is not enabled.

DES register faults:

F_SOFT_DEST - flag for Software Generated Destructive Reset - your code must call it somewhere in task or in some function. Check where you call destructive reset. I guess it is in exception handler.

F_SSCM_SEC

F_HSM_DEST

Those 2 a linked to secure boot. Check if your secure boot can pass successfully and set endless loop at the end of secure boot sequence.

F_SWT0_RES ( mostly, issue detected this ) - this is causing reset escalation to be set.

Flag for Functional Reset Escalation you can exclude.

F_EXR - is your debugger I guess - you can exclude this one

This is my first guess, it will require further investigation, but try to do it step by step.

regards,

Peter

[park_kwangsoo]

F_SWT0_RES(watchdog) issue happen again.

I add log all DES / FES

I also read 

MCSRR0 = 0xffffff

MCAR = 0xffffff

this result I cannot understand

this looks pure watchdog issue. How can this happen?

please guide me.

[petervlna]

ok,

disable the reaction o watchdog, or watchdog itself and see where you code hangs up.

regards,

Peter

[park_kwangsoo]

I need to check meanings of instruction storage interrupt for processing-method.

it can make argu between companys. this is very sensitive issue.

[petervlna]

Hi,

Instruction storage (ISI) or data storage (DSI) interrupts generated by aborted core accesses.

please check address where the ISI is triggered and make sure the accessing core has access.

regards,

Peter

[park_kwangsoo]

address where the ISI means task address?

it is triggered on UART_MODULE of task2.

As test result & debugging result, DMA_RX() or DMA_TX() executed before issue happen.

DmaTcdAddress = 4228518400 // TX

DmaTcdAddress = 4228518432 // RX

EEI16=1

EEI17=1

[petervlna]

Hi,

Simply debug the assembly code and see which instruction cause the exception.

This will give you a good overview on what went wrong.

Once you know the failing address you can check if the accessing core has the rights, etc..

regards,

Peter

[park_kwangsoo]

solved.

thanks you peter

[park_kwangsoo]

hello peter

I find other wdg problem that instruction storage interrupt -> jump to idle -> wdg -> os shutdown.

how can I handle this?

Our company A product / Other company B product

A and B communicate by uart.

it seems like B update their uart driver to more faster reply for our request.

after then mcu reset issue happen.

I debugging and reproduce test.

SRR0/SRR1 tell me instruction storage interrupt error cause by Uart Module.

how can this happen?

our uart driver use DMA.

thanks

kwangsoo.park

[park_kwangsoo]

thanks.

I solve the problem by deleting COMM. blocker