ChibiOS Free Embedded RTOS

Thank you Giovanni,

I increased the process stack size to 0xD00 and the code managed to proceed much further.
After that I started seeing a stack overflow in dbg_panic_msg. At that point an LED blinker thread was reporting 0 StkUnused. After doubling it's working area to 256 things seemed to start working again.

I'm not sure that I have gone through the process of checking for stack overflows properly. Is there a guide to this somewhere in the documentation?
All I have done is run the .elf executable and paused it to check the chibios debug view and make sure StkUnused was greater than 0 for all threads.

I'm not sure though how much spare room I have on the stacks after increasing the stack sizes, Is StkUnused in the Chibios debug view the best way to monitor this?

From what I can see all the remaining ram after the stacks are allocated is allocated to the heap but is it possible to work out how much of the allocated heap space is actually used or available when chibios is running?

Finally in the STM32CubeIDE build analyzer the used memory for ram0 shows 128KB which corresponds with 100% for the STM32G474. The same used memory of 128KB appears for both ram1 and ram2 although only 96KB and 80KB are available for those spaces. All usages of 100%, 133.33% and 160% are highlighted red. I imagine this is because ram1 & ram2 are sub-parts of ram0 as all have a start address of 0x20000000. I just wanted to check that this is OK because it is somewhat confusing when you might expect all reported usage %'s to be less than or equal to 100%?

You have enabled stack checking in chconf.h?

gp7 wrote:Is StkUnused in the Chibios debug view the best way to monitor this?

It's the minimum effort way.
I wrote a simple routine to do the checking on demand; so I can cause it to do a periodic check, or trigger a check from an external command. My routine isn't 100% accurate, since it uses a binary search for speed (The Chibi debug view steps through sequential memory locations).
Sometimes it's better to start from the opposite end of the problem; allocate generously oversized stack areas to start with (assuming you have the RAM, of course) then trim back once you have stable code.

Thanks steved,

I have enabled CH_DBG_ENABLE_STACK_CHECK and CH_DBG_FILL_THREADS in chconf.h If there is a problem with the stack sizes how does that normally manifest?

On a hugely positive note since changing the size of my blinker thread working area I haven't seen an unhandled exception yet so I think I might have stable code.

gp7 wrote:I have enabled CH_DBG_ENABLE_STACK_CHECK and CH_DBG_FILL_THREADS in chconf.h If there is a problem with the stack sizes how does that normally manifest?

I think you answered your own question earlier!

After that I started seeing a stack overflow in dbg_panic_msg

However that assumes the code continues to run - achieve a spectacular overflow, and all bets are off.

Apologies for reviving this thread.
Just a note for anyone that might be seeing similar issues. I managed to trace my problems with I2C bus to the setup of the I2CConfig:

const I2CConfig m_i2cfg2 = {0x30A0A7FB, 0, 0};

this was declared in a function however so a location was allocated on the stack, then when the variable m_i2cfg2 went out of scope the settings for the I2C bus were being overwritten by other operations in the stack memory space.

I corrected this as follows:

static const I2CConfig m_i2cfg2 = {0x30A0A7FB, 0, 0};

Every day's a school day. These challenges are sent to try us!

A very common error

Giovanni