Debug access without reset?

[Korken]

I have been trying to get my own Assert going, but something is wrong.

I have defined mine as:

Code: Select all

typedef struct {
  const char *reason;
  const char *function;
} assert_errors;

#define chDbgAssert(c, r) do {                                              \
  if (CH_DBG_ENABLE_ASSERTS && !(c)) {                                      \
    extern volatile assert_errors kfly_assert_errors;                       \
    kfly_assert_errors.reason = r;                                          \
    kfly_assert_errors.function = __func__;                                 \
    chSysHalt(__func__);                                                    \
  }                                                                         \
} while (0)

at the end of chconf.h. But when I compile I get the error:

Code: Select all

Compiling chcoreasm_v7m.s
Compiling chcore.c
./chconf.h: Assembler messages:
./chconf.h:498: Error: bad instruction `typedef struct {'
./chconf.h:499: Error: bad instruction `const char*reason'
./chconf.h:500: Error: bad instruction `const char*function'
./chconf.h:501: Error: junk at end of line, first unrecognized character is `}'
make: *** [build/obj/chcoreasm_v7m.o] Error 1
make: *** Waiting for unfinished jobs....

"volatile assert_errors kfly_assert_errors;" is declared in main.c (hence the extern).

Could you point out my error?

Brest Regards
Emil

[Giovanni]

chcore.h is also included from asm modules, if you put C declarations there then check the macro _FROM_ASM_.

Giovanni

[Korken]

Ah, thank you!

While we still are on debug problems I have one related to ChibiOS.
When I request the threads from debug view I get this error:


What does it mean?
Because when I fixed my reschedule problem it just runs the Idle thread and never switches to my other threads.
So I was trying to get the status of treads for clues.

[Giovanni]

It means exactly that, the linked list of threads is corrupted. Look for stack overflows or other possible memory corruptions.

Giovanni

[Korken]

Thanks you for the tip, I have never looked at stack corruption that much before so this will be very interesting!

Could you just provide one clarification about a stack frame?
I have an example stack frame here of a thread in my application:



The stack starts on 0x20002450 andhas a size of 512 bytes which implies it ends at 0x2000264C (the green box).
The entire stack frame is represented by the red box.

As I understand a stack grows to lower addresses, so it will start on 0x2000264C and fill the memory -> 0x20002450, is this correct?
If this is the case, about half of the frame is filled until the brown box which has the 0x55 patter which indicates unused stack.
But what is then the data in the blue box? I seems to have started at 0x20002450 and grown towards higher addresses?

The OS is not raising any flags about stack overflows, so it seems to not be an overflow?

Thanks in advance!

[Giovanni]

It can be one of the many stacks, there is one for each thread plus the exceptions stack, the OS is not able to catch any stack overflow condition because the CPU does not support such a feature in HW.

Giovanni

[Korken]

Hmm, okey. However, my question was if a valid stack frame should look like this? I'm not quite sure how a correct one should look.

What is best practice when hunting this type of problem? Step through the code and see when the erroneous data appears?

[Giovanni]

The best way is to simplify the code and then reintroduce things one by one until it breaks.

Stacks must have filler left.

Giovanni

[Korken]

Hmm, are you sure the data in the blue box shouldn't be there?
After I removed everything and just started a new thread blinking a LED the data in the blue box is still there.
So I checked all my threads, and all of them have data at the beginning of the stack address.

[Giovanni]

The data at the beginning of the stack is the Thread structure, see "kernel concepts" in the documentation. It is the part overwritten when a stack overflows.

Giovanni