Page 1 of 3

Debugging improvements.

Posted: Mon Jul 15, 2013 9:13 pm
by barthess
Hi Giovanni.
I am currently thinking about some debugging improvements and want to know your opinion.

1) add file name and line number in panic message. Looks trivial. Probably message could contain function name too.
2) change all chDbgAssert() to chDbgCheck(). After change #1 chDbgAssert() macro looks unneeded (probably I am incorrect). Replace can be performed in semi automatic way using some scripting.
3) add uart driver able to work after port_disable(). Driver for F4x written and tested but it needs to add a call of HAL function from portable kernel code. This looks dirty. Probably we can introduce (move current) panic handler to HAL.
4) insert somewhere in panic handlers code infinitely sending panic message every second via that driver.
5) add breakpoint call in panic handler when MCU runs under JTAG (cortex-m3 able to do such trick).

Re: Debugging improvements.

Posted: Mon Jul 15, 2013 9:39 pm
by Giovanni
Hi,

Checks and asserts have a different role, unifying them is not a good idea IMHO. The second parameter of both will be likely removed but this will not happen before version 3.0.

Giovanni

Re: Debugging improvements.

Posted: Tue Jul 16, 2013 7:47 am
by barthess
Giovanni wrote:Checks and asserts have a different role

Could you explain differences? It is not clean for me.

Re: Debugging improvements.

Posted: Tue Jul 16, 2013 7:51 am
by Giovanni
Checks are for parameters only those guard the interface between OS and application, assertions guard logic errors inside the OS.

Giovanni

Re: Debugging improvements.

Posted: Tue Jul 16, 2013 9:02 pm
by jscott
I like the idea of part 3 & 4.

Having a option of sending debugging information would be useful when working with systems that
don't support easy in circuit debugging.

I would thing a basic serial driver that when called, disables all interrupts, configures a serial port for polled serial output, and sends a message once a second would be handy. This would be a configurable option that once called would never return. Just send a error string.

-John Scott
http://www.atl123.com

Re: Debugging improvements.

Posted: Tue Jul 30, 2013 6:32 pm
by russian
I was going to start my own thread on a similar matter, but since this one is already here I'd better comment here.

-1) in chdebug.c, would it reduce code duplication if instead of
if ((dbg_isr_cnt <= 0) || (dbg_lock_cnt != 0))
chDbgPanic("SV#6");

you would use chDbgAssert? This case one adding his own parameters to chDbgPanic would have less places to change :)

0) chDbgPanic("SV#6");
I am not sure what these codes are, but something human-readable would probably improve things:
chDbgPanic("SV#4 misplaced chSysLock()");

1) please please add file and line into the panic message!

3) this is really needed. configuring the debugger just for the panic messages is not usable. My own solution for this is:

Code: Select all

void chDbgPanic(const char *msg) {
#if CH_DBG_ENABLED
   if (dbg_panic_msg != NULL )
      return;
   dbg_panic_msg = msg;
#else
   chSysHalt();
#endif
}
#endif /* CH_DBG_ENABLED */


and in the main thread I have a loop which does

Code: Select all

static void checkIfShouldHalt() {
#if CH_DBG_ENABLED
   if (dbg_panic_msg != NULL) {
      setOutputPinValue(LED_FATAL, 1);
      print("my FATAL [%s]\r\n", dbg_panic_msg);
      chThdSleepSeconds(1);
      while (TRUE) {
      }
      chSysHalt();
   }
#endif
}

Re: Debugging improvements.

Posted: Tue Jul 30, 2013 7:11 pm
by Giovanni
You suggestion seem to not consider the real function of a "panic" which is to stop the system immediately after an unpredictable and unrecoverable error.

Anyway, changes to the system are planned for the kernel 3.0, probably your suggestions about function names and line numbers will be implemented.

Giovanni

Re: Debugging improvements.

Posted: Tue Jul 30, 2013 7:29 pm
by russian
Giovanni wrote:You suggestion seem to not consider the real function of a "panic" which is to stop the system immediately after an unpredictable and unrecoverable error.

Ohh, absolutely - my panic is not a true panic anymore, it's a dirty hack :( but this dirty hack addresses a very particular problem - right now the cost of accessing the error message is prohibitively high.

Re: Debugging improvements.

Posted: Tue Jul 30, 2013 7:33 pm
by Giovanni
The Eclipse debug plugin retrieves the message for you :)

And in 3.0 it will show a lot lot more, tomorrow I will post some screenshots, the new kernel is shaping up very well.

Giovanni

Re: Debugging improvements.

Posted: Tue Jul 30, 2013 9:18 pm
by barthess
Hi all.
Tomorrow I will push first draft in separate branch for review.