ChibiOS Free Embedded RTOS

Is there any way to somehow make the behavior predictable? Perhaps is there a simple way to check where everything gets assigned to be in RAM such as a table showing that information? I want to avoid a situation where there's unpredictable behavior which might only show up in corner cases for ...

I went back to my code that matches up to the code snippets above. I changed the stack size on the Thread1 from 10000 to 1000. That allowed both threads to work correctly. Why might dropping the stack size on that thread be helpful? I would expect larger stack sizes (up to a rather large value) to ...

The FPU is enabled in the Makefile. I have tried removing all of the floats and disabling the float support as well to no avail.

I've got two threads. If I start the first thread (temp_thread_1), but I don't start the second thread (Thread1), then temp_thread_1 functions correctly (it does some SPI communications and displays temperatures of components on the board). However, if I start the temp_thread_1, wait 10 seconds, and ...

I don't think that a stack overflow is occurring, but I'm not sure that I know exactly what I should be looking for. Please give me some hints. I don't know what to look for regarding an overflow in adjacent variables.

The working area I started with for thread1 was 1024. I've gone as high as 10000 ...

Here's a simplified version of the code in main that relates to the problem:


static float setVal;

// Definition of Thread1 thread
static THD_FUNCTION(Thread1, arg) {
while (true) {
chMtxLock(& mt);
//setVal = 250.0f;
vertiqVelocity(setVal, setVal, setVal, setVal);
chMtxUnlock(& mt ...

After a recommendation from my manager, I am giving a couple paragraphs of a description to see if that helps describe the situation better:

We have four motors that we’re trying to control via UARTs. The main command we are sending to the motors is a rotational speed command which uses a single ...

It is a STM32H753. It does have cache, but I guess it only works with external RAM which I don't think we have.

Now I'm even further confused. If I take the case where things seemed to be working (assigning setVal in the same thread as used) and I add the volatile keyword to the declaration of setVal - now the end result is no longer correct. I'm definitely frustrated by the behavior I'm seeing.

Thanks,
John

I agree that it is strange behavior. I've never seen anything like it before.

The variable is always assigned directly as a float. There is no casting going on.

That's a good point about volatiile. I'll give that a try.