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).
Debugging improvements.
- Giovanni
- Site Admin
- Posts: 14452
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1075 times
- Been thanked: 922 times
- Contact:
Re: Debugging improvements.
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
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.
Giovanni wrote:Checks and asserts have a different role
Could you explain differences? It is not clean for me.
- Giovanni
- Site Admin
- Posts: 14452
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1075 times
- Been thanked: 922 times
- Contact:
Re: Debugging improvements.
Checks are for parameters only those guard the interface between OS and application, assertions guard logic errors inside the OS.
Giovanni
Giovanni
Re: Debugging improvements.
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
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
- russian
- Posts: 364
- Joined: Mon Oct 29, 2012 3:17 am
- Location: Jersey City, USA
- Has thanked: 16 times
- Been thanked: 14 times
Re: Debugging improvements.
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
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:
and in the main thread I have a loop which does
-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
}
- Giovanni
- Site Admin
- Posts: 14452
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1075 times
- Been thanked: 922 times
- Contact:
Re: Debugging improvements.
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
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
- russian
- Posts: 364
- Joined: Mon Oct 29, 2012 3:17 am
- Location: Jersey City, USA
- Has thanked: 16 times
- Been thanked: 14 times
Re: Debugging improvements.
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.
- Giovanni
- Site Admin
- Posts: 14452
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1075 times
- Been thanked: 922 times
- Contact:
Re: Debugging improvements.
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
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
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 5 guests