stack check

[olliw42]

@rotorman attempt at checking stack usage by painting

[rotorman]

Here some results.

Breakpoint after assembler painting with 0x55:

We can see that 0x20003C00 to 0x20003FFF is nicely painted.

Breakpoint before C++ painting:

We can see that stack from top 0x20003FFF down to 0x20003E50 is in use (432 bytes, thus limiting with 128 would have been too little).

Hardfault when executing mlrs-tx.cpp:L655 stack_paint(): due to overwriting necessary information.

[rotorman]

I removed the C++ painting and changed the assembly painting to 0xAA. Here how TX side FRM303 stack looks like after some minutes, when connected to RX side FRM303 and Mission Planner, via serial and mlrs-wireless-bridge loaded on M5Stack ATOM Lite:

We can see only 192 unused bytes. Will keep observing to see if this decreases over time.

The code that I am using: https://github.com/rotorman/mLRS/tree/FRM303_tx_debug_stack

[rotorman]

I'm gonna put it this way - the correct way is the assembler way before any C/C++ preparation code runs...

[rotorman]

The state after 10 min - free space has not decreased:

I will let it run to see if I get telem lost at some point.

[olliw42]

We can see that stack from top 0x20003FFF down to 0x20003E50 is in use (432 bytes, thus limiting with 128 would have been too little). I'm gonna put it this way - the correct way is the assembler way before any C/C++ preparation code runs...

I disagree. I think you have not yet picked up yet in which way this argument is flawed. You should look at MSP at time of painting.

I put stack_check_init() AFTER init() (that is even much later than it is now) and added debug printout of some variables, especially of MSP. And MSP was only at 80 bytes below estack.

Anyway, I have changed it to not paint above MSP, which really should remove any concerns.

I too - on my tx and rx diy boards I currently use (not FRM303) - see stack occupancies of ca 800 bytes. If that upholds for long time stack might be ok. I wonder though if we could explain this 800-ish number. I mean, the static stack analyzer gives just quite low values.

:)

Anyway, this is something I wanted to do since long, also for other projects of mine, and I'm glad I did it now. Can't hurt.

[olliw42]

Here how TX side FRM303 stack looks like after some minutes, when connected to RX side FRM303 and Mission Planner, via serial and mlrs-wireless-bridge loaded on M5Stack ATOM Lite: grafik We can see only 192 unused bytes. Will keep observing to see if this decreases over time.

that's super weired ... is it normal that there are gaps in the stack ??? I would not think so ... how does that come ?!?

[rotorman]

After ca. 40 minutes, I now have a telemetry lost and, steady green LED on TX-side FRM303, blinking red LED on RX side FRM303. Stack looks like this - only 16 bytes left !!!:

By stepping through code I see that I am stuck in: https://github.com/rotorman/mLRS/blob/e3335e53d2c5d22524a1e9af6163f7a4511c1bca/mLRS/Common/sx-drivers/sx128x_driver.h#L369

[olliw42]

largely settled, check check optionadded to main