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
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
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.
ok,
disable the reaction o watchdog, or watchdog itself and see where you code hangs up.
regards,
Peter
I need to check meanings of instruction storage interrupt for processing-method.
it can make argu between companys. this is very sensitive issue.
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
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
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
solved.
thanks you peter
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
thanks.
I solve the problem by deleting COMM. blocker