Difference between revisions of "How to retrieve Cortex-M4 logs after crash"

[quality revision] [quality revision]
m
 
m
 

Template:ArticleMainWriter Template:ArticleApprovedVersion

1 Introduction[edit]

When the Arm® Cortex®-M4 firmware crashes, Linux® running on Arm® Cortex®-A7, can generate an M4 coredump file. This M4 coredump records the states of the working memory of the Cortex-M4 firmware which permits to assist in diagnosing errors.

If some Cortex-M4 firmware logs have been output to the trace buffer declared in the resource table, they can be retrieved from the M4 coredump.

2 Prerequisite[edit]

An M4 coredump file is generated under the following conditions:

  • the The Cortex-M4 informs the Cortex-A7 when it crashes. This is the case for instance if the Cortex-M4 firmware implements the watchdog detection (see WWDG internal peripheral),.
  • the The remoteproc node of the Linux device tree defines the "recovery" property,.
  • a A Linux service is running, allowing to enable and capture coredump files is running. In the STM32MPU Embedded Software distribution this is implemented by the :
  • set the /sys/kernel/debug/remoteproc/remoteproc0/coredump to enable the feature,
  • implement the m4-dump.rules udev rule to get and store coredump.
In the STM32MPU Embedded Software distribution, the service is available in recipes-extended/m4coredump/files/ ,

3 Getting an M4 coredump file[edit]

When the Cortex-M4 crashes, Linux running on the Cortex-A7 is informed and stores a timestamped M4 coredump file in /var/crash.

Example: listing M4 coredumps

Board $> ls -l /var/crash 
total 1188
-rw-r--r-- 1 root root 608500 Nov 30 16:02 m4-fw-error_2018-11-30_16-02-21.dump
-rw-r--r-- 1 root root 606420 Nov 30 16:07 m4-fw-error_2018-11-30_16-07-26.dump

4 Reading the logs from the coredump file[edit]

Start with getting the offset address of the trace log:

PC $> readelf -l m4-fw-error_2018-11-30_16-02-21.dump

Elf file type is CORE (Core file)
Entry point 0x10003129
There are 6 program headers, starting at offset 52

Program Headers:
 Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
 LOAD           0x0000f4 0x00000000 0x00000000 0x10000 0x10000 RWE 0
 LOAD           0x0100f4 0x30000000 0x30000000 0x40000 0x40000 RWE 0
 LOAD           0x0500f4 0x10000000 0x10000000 0x40000 0x40000 RWE 0
 LOAD           0x0900f4 0x10040000 0x10040000 0x02000 0x02000 RWE 0
 LOAD           0x0920f4 0x10042000 0x10042000 0x02000 0x02000 RWE 0
 LOAD           0x0940f4 0x100200e4 0x100200e4 0x00800 0x00800 RWE 0

The trace log (assuming that the resource table defines a trace buffer) is stored in the last memory segment. In this example, its offset is 0x0940f4.

You can read the M4 binary coredump file from this offset to get the logs or you can use the following command to output them (use -c +N option where N is log offset + 1):

PC $> tail -c +$((0x940f4 + 1)) m4-fw-error_2018-11-30_16-02-21.dump
[00000.000][INFO ]Starting WWDG
[00001.422][INFO ]WWDG now!


<noinclude>

{{ArticleMainWriter | FabienD}}
{{ArticleApprovedVersion | FabienD | ArnaudP, Jean-ChristopheT (Passed, 15Jan'19) | No previous approved version | AlainF - 21Jan'19 - 10358 | 21Jan'19}}

[[Category:How to trace and debug]]  
[[Category:Coprocessor management STM32Cube]]</noinclude>

== Introduction ==
When the Arm<sup>&reg;</sup> Cortex<sup>&reg;</sup>-M4 firmware crashes, Linux<sup>&reg;</sup> running on Arm<sup>&reg;</sup> Cortex<sup>&reg;</sup>-A7, can generate an M4 coredump file. This M4 coredump records the states of the working memory of the Cortex-M4 firmware which permits to assist in diagnosing errors.

If some Cortex-M4 firmware logs have been output to the [[Coprocessor_resource_table#How_to_add_trace_for_the_log_buffer|trace buffer declared in the resource table]], they can be retrieved from the M4 coredump.

== Prerequisite ==
An M4 coredump file is generated under the following conditions:
* theThe Cortex-M4 informs the Cortex-A7 when it crashes. This is the case for instance if the Cortex-M4 firmware implements the watchdog detection (see [[WWDG_internal_peripheral|WWDG internal peripheral]]),
* the.
* The [[Linux_remoteproc_framework_overview#Device tree configuration|remoteproc node of the Linux device tree]] defines the '''"recovery''"''' property,
* a Linux service allowing to capture coredump files is running. In the STM32MPU Embedded Software distribution this is implemented by.
*A Linux service is running, allowing to enable and capture coredump files:
:* set the  /sys/kernel/debug/remoteproc/remoteproc0/coredump to enable the feature,
:* implement the ''m4-dump.rules'' udev rule.
  to get and store coredump.
:In the STM32MPU Embedded Software distribution, the service is available  in {{CodeSource | meta-st-stm32mp  | recipes-extended/m4coredump/files/}},
== Getting an M4 coredump file ==
When the Cortex-M4 crashes, Linux running on the Cortex-A7 is informed and stores a timestamped M4 coredump file in /var/crash.

Example: listing M4 coredumps
 {{Board$}} ls -l /var/crash 
 total 1188
 -rw-r--r-- 1 root root 608500 Nov 30 16:02 m4-fw-error_2018-11-30_16-02-21.dump
 -rw-r--r-- 1 root root 606420 Nov 30 16:07 m4-fw-error_2018-11-30_16-07-26.dump

== Reading the logs from the coredump file ==
Start with getting the offset address of the trace log:
 {{PC$}} readelf -l m4-fw-error_2018-11-30_16-02-21.dump

 Elf file type is CORE (Core file)
 Entry point 0x10003129
 There are 6 program headers, starting at offset 52

 Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x0000f4 0x00000000 0x00000000 0x10000 0x10000 RWE 0
  LOAD           0x0100f4 0x30000000 0x30000000 0x40000 0x40000 RWE 0
  LOAD           0x0500f4 0x10000000 0x10000000 0x40000 0x40000 RWE 0
  LOAD           0x0900f4 0x10040000 0x10040000 0x02000 0x02000 RWE 0
  LOAD           0x0920f4 0x10042000 0x10042000 0x02000 0x02000 RWE 0
  LOAD           {{red|0x0940f4}} 0x100200e4 0x100200e4 0x00800 0x00800 RWE 0

The trace log (assuming that the resource table defines a trace buffer) is stored in the last memory segment. In this example, its offset is 0x0940f4.

You can read the M4 binary coredump file from this offset to get the logs or you can use the following command to output them (use '''-c +N''' option where N is ''log offset + 1''):
 {{PC$}} tail -c +$(({{red|0x940f4}} + 1)) m4-fw-error_2018-11-30_16-02-21.dump
 [00000.000][INFO ]Starting WWDG
 [00001.422][INFO ]WWDG now!

<noinclude>

[[Category:How to trace and debug]]  
[[Category:Coprocessor management STM32Cube]]
{{PublicationRequestId | 10358 | 2019-01-21 | AlainF}}</noinclude>
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<noinclude>
 
{{ArticleMainWriter | FabienD}}
 
{{ArticleApprovedVersion | FabienD | ArnaudP, Jean-ChristopheT (Passed, 15Jan'19) | No previous approved version | AlainF - 21Jan'19 - 10358 | 21Jan'19}}
 
 
[[Category:How to trace and debug]] 
 
[[Category:Coprocessor management STM32Cube]]
 
</noinclude>
 
 
 
== Introduction ==
 
== Introduction ==
 
When the Arm<sup>&reg;</sup> Cortex<sup>&reg;</sup>-M4 firmware crashes, Linux<sup>&reg;</sup> running on Arm<sup>&reg;</sup> Cortex<sup>&reg;</sup>-A7, can generate an M4 coredump file. This M4 coredump records the states of the working memory of the Cortex-M4 firmware which permits to assist in diagnosing errors.
 
When the Arm<sup>&reg;</sup> Cortex<sup>&reg;</sup>-M4 firmware crashes, Linux<sup>&reg;</sup> running on Arm<sup>&reg;</sup> Cortex<sup>&reg;</sup>-A7, can generate an M4 coredump file. This M4 coredump records the states of the working memory of the Cortex-M4 firmware which permits to assist in diagnosing errors.
Line 14: Line 6:
 
== Prerequisite ==
 
== Prerequisite ==
 
An M4 coredump file is generated under the following conditions:
 
An M4 coredump file is generated under the following conditions:
* the Cortex-M4 informs the Cortex-A7 when it crashes. This is the case for instance if the Cortex-M4 firmware implements the watchdog detection (see [[WWDG_internal_peripheral|WWDG internal peripheral]]),
+
* The Cortex-M4 informs the Cortex-A7 when it crashes. This is the case for instance if the Cortex-M4 firmware implements the watchdog detection (see [[WWDG_internal_peripheral|WWDG internal peripheral]]).
* the [[Linux_remoteproc_framework_overview#Device tree configuration|remoteproc node of the Linux device tree]] defines the ''recovery'' property,
+
* The [[Linux_remoteproc_framework_overview#Device tree configuration|remoteproc node of the Linux device tree]] defines the '''"recovery"''' property.
* a Linux service allowing to capture coredump files is running. In the STM32MPU Embedded Software distribution this is implemented by the ''m4-dump.rules'' udev rule.
+
*A Linux service is running, allowing to enable and capture coredump files:
  +
:* set the  /sys/kernel/debug/remoteproc/remoteproc0/coredump to enable the feature,
  +
:* implement the ''m4-dump.rules'' udev rule to get and store coredump.
  +
:In the STM32MPU Embedded Software distribution, the service is available  in {{CodeSource | meta-st-stm32mp  | recipes-extended/m4coredump/files/}},
   
 
== Getting an M4 coredump file ==
 
== Getting an M4 coredump file ==
Line 50: Line 45:
 
  [00000.000][INFO ]Starting WWDG
 
  [00000.000][INFO ]Starting WWDG
 
  [00001.422][INFO ]WWDG now!
 
  [00001.422][INFO ]WWDG now!
  +
  +
<noinclude>
  +
[[Category:How to trace and debug]] 
  +
[[Category:Coprocessor management STM32Cube]]
  +
{{PublicationRequestId | 10358 | 2019-01-21 | AlainF}}
  +
</noinclude>