M122 software reset code field and its values

[droftarts]

I've moved the posts from this topic to here, to keep that one on track.

Ian

[AndMaz]

Sorry to intrude. I'm also having random reboots. Is there any docs about the Software reset code field and its values? I would like to understand what's going on with my Duet.

[dc42]

@AndMaz we haven't documented it because it's liable to change between firmware versions. If you post the specific software reset data that you are interested in, I will attempt to explain it.

[AndMaz]

Hi @dc42 Here's an example:

Last reset 00:00:29 ago, cause: software
Last software reset at 2023-12-07 11:58, reason: OutOfMemory, Gcodes spinning, available RAM 16, slot 0
Software reset code 0x41c3 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x200021e8 Task MAIN Freestk 943 ok
Stack: 2001993c 004103d3 200197bc 00400247 200197bc 00000000 000000cc 00400299 00000000 20002288 00000000 20002280 200022d4 0040018d 00000000 00411d7f 20004bb4 40090000 200040f4 ffffffed 00000002 00473fac 200023f8 20002400 00000000 20002288 00000000

Also, can you explain the available RAM 16? 16 was the available memory when the reset happened?

[jay_s_uk]

@AndMaz it helps if you post the full M122 output so the correct build of the firmware can be identified

[dc42]

@AndMaz for an out of memory error, the stack listing is the state of the stack at the point where the memory allocation routine found that there was not enough memory to satisfy the request. In your example, the stack values starting with 004 are probably return addresses. You can use the .map file for the firmware build you are running to identify which functions those return addresses are in.

And yes, 16 bytes is the amount of free memory at the time that memory allocation request was made. It's easy to run out of memory on Duet 2 if a lot of conditional GCode expressions and/or global variables are used.

[AndMaz]

@jay_s_uk You're right. I'm on 3.5.0-beta.4 but this also happens with other versions

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.0-beta.4 (2023-06-08 23:39:39) running on Duet Ethernet 1.02 or later
Board ID: <BOARD-ID>
Used output buffers: 2 of 26 (24 max)
Error in macro line 183 while starting up: I2C transmission error
=== RTOS ===
Static ram: 23236
Dynamic ram: 79896 of which 12 recycled
Never used RAM 1432, free system stack 184 words
Tasks: NETWORK(1,ready,27.9%,242) HEAT(3,nWait,0.1%,331) Move(4,nWait,0.0%,364) MAIN(1,running,72.0%,709) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 01:01:20 ago, cause: software
Last software reset at 2023-12-07 11:58, reason: OutOfMemory, Gcodes spinning, available RAM 16, slot 0
Software reset code 0x41c3 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x200021e8 Task MAIN Freestk 943 ok
Stack: 2001993c 004103d3 200197bc 00400247 200197bc 00000000 000000cc 00400299 00000000 20002288 00000000 20002280 200022d4 0040018d 00000000 00411d7f 20004bb4 40090000 200040f4 ffffffed 00000002 00473fac 200023f8 20002400 00000000 20002288 00000000
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 52.0, current 52.6, max 53.3
Supply voltage: min 23.6, current 23.7, max 23.8, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 297/187, heap memory allocated/used/recyclable 6144/5844/1812, gc cycles 119

@dc42 said in M122 software reset code field and its values:

It's easy to run out of memory on Duet 2 if a lot of conditional GCode expressions and/or global variables are used.

Yep, I have 174 global variables in total and my .g files have a loooot of conditional expressions. I guess that's the source of my problem

BTW what's the meaning of Never used RAM 1432, free system stack 184 words? Is it reserved for something? I mean, why the OutOfMemory error if there's 1432 of never used RAM?

[dc42]

@AndMaz the Never Used RAM is the important value. It's that value that is going down to 16. If you watch it while your printer is doing stuff then I expect you will see it gradually reduce, for example as you create more variables, or store larger amounts of data in them.

As well as watching the Never Used RAM I suggest you also watch the Heap stats that are at the end of the Platform section. Variables and the associated values are stored in that heap. The number of handles used should be not much greater than the number of variables that are active.

Is there something in your macros that causes the amount of data stored in variables to increase over time? You can use the Object Model Browser in DWC to see what global variables you have and what their values are.

If you don't think that amount of data in global variables increases over time then it's possible that there is a memory leak in the firmware.

[AndMaz]

@dc42 thank you for the detailed explanation. I'll keep an eye on the Never Used RAM

BTW would be possible to expose memory related vars via Object-Model?

Extracting data from M122 is prone to error. I need to update my regex for each firmware version.

Would be super useful to have a consistent API that exposes this kind of data via HTTP

[AndMaz]

@dc42 if exposing this data via HTTP API is not an option, is it possible to redirect the output of M122 to a file?

Something like echo >"my-file.txt" M122 or M122 F"my-file.txt" ?

[AndMaz]

@droftarts will any of the above be possible?

[AndMaz]

@dc42 @droftarts @jay_s_uk sorry for the spam, can we expect, in near future, RAM-related data exposed via Object-Model or, at least, a way to redirect M122 data to a specific file?

We're going to PROD in few months and I would like to sort this memory issue by then