Thursday, March 16, 2006
Tips for the week : March 16
Q: I am migrating to refsys and I can’t find dbgprintf anywhere. Where is it?
A: dbgprintf has been replaced by ramlog_printf in the refsys model. The ramlog_printf version stores in a RAM area that survives a restart. If it doesn’t suit your needs though, you’ll need to port dbgprintf over to your refsys build yourself. There is some tricky business to this, particularly if you want to send debug output to the serial port, so consult support before you attempt it.
Q: I am creating a new refsys modules in OSE5.1 for my application, and I want to pull in the standard C includes which are OSE-adapted. However there are multiple versions of certain includes in the 5.1 distribution, e.g. assert.h exists in both OSE5.1/include and OSE5.1/cygwin/usr/include . Which one should I use?
A: To pull to your module source the OSE-aware versions of the includes, use the standard include brackets e.g. “include < assert.h >”. Make sure your local myapp.mk file for your app has the OSE include directory added to the include path:
INCLUDE += -I$(OSEROOT)/include
Q: I’m trying to debug some code that’s in a refsys module, and I’m not able to attach the debugger to the process that came from the module. The debugger prints out an error and a bad PC counter when it attaches. What could be wrong?
A: One thing to check is your refsys/rtose/< board >/Makefile entry for “mods” target. It is always “release” by default, and FLAVOR=debug option doesn’t always generate debuggable code for some boards. You can change this in the Makefile to be “debug” instead for the mods target. This is known to be a problem in EST8260 and perhaps other boards as well.
A: dbgprintf has been replaced by ramlog_printf in the refsys model. The ramlog_printf version stores in a RAM area that survives a restart. If it doesn’t suit your needs though, you’ll need to port dbgprintf over to your refsys build yourself. There is some tricky business to this, particularly if you want to send debug output to the serial port, so consult support before you attempt it.
Q: I am creating a new refsys modules in OSE5.1 for my application, and I want to pull in the standard C includes which are OSE-adapted. However there are multiple versions of certain includes in the 5.1 distribution, e.g. assert.h exists in both OSE5.1/include and OSE5.1/cygwin/usr/include . Which one should I use?
A: To pull to your module source the OSE-aware versions of the includes, use the standard include brackets e.g. “include < assert.h >”. Make sure your local myapp.mk file for your app has the OSE include directory added to the include path:
INCLUDE += -I$(OSEROOT)/include
Q: I’m trying to debug some code that’s in a refsys module, and I’m not able to attach the debugger to the process that came from the module. The debugger prints out an error and a bad PC counter when it attaches. What could be wrong?
A: One thing to check is your refsys/rtose/< board >/Makefile entry for “mods” target. It is always “release” by default, and FLAVOR=debug option doesn’t always generate debuggable code for some boards. You can change this in the Makefile to be “debug” instead for the mods target. This is known to be a problem in EST8260 and perhaps other boards as well.
Labels: dbgprintf, migration, OSE5.3, refsys
free invisible web counter
