Friday, May 26, 2006
Tips for April-May, 2006
Q: I’m using OSE5.1 in Eclipse IDE and trying to debug a soft kernel. When I “Run->Debug” I’m getting no debug launch, only “No stack” error instead. If I try to “Run->Run” I see an error complaining about not being able to find lmgr9a.dll. This used to work – what is wrong?
A: Sometimes on some systems, Eclipse does not inherit the environment from windows properly and doesn’t know your path. Specifically, it cannot find the lmgr9a.dll license file required for the soft kernel license. However you’ll only get that hint when you Run and you won’t see this file mentioned when you Debug. There is no good long-term solution I know of, and I don’t why this happens to some users. But the quickest way around it for now is to just copy over the lmgr9a.dll file from $OSE_ROOT/bin/win32/ over to your rtose/sfk-win32 directory. Then it will always be found by the debug launcher.
Q: I’m running a soft kernel with some C++ in the application, and it’s crashing:
(gdb) run -c rtose5.conf
Starting program: /cygdrive/c/ose/ose5.1/refsys/rtose/sfk-win32/obj/rtose_debug/
rtose.exe -c rtose5.conf
SFK: biosCall 0x4a before bios initialized!!
SFK: Cannot error calls or any other syscalls this early, exiting.
A: One possible cause is dead code in the cpp source file of a problem class. The dead code may be outside of the class. For example:
tFILE* gfpStdOut = stdout;
The pointer does not have to be used at all. But referencing this class the SFK will crash, even if the dead code is outside of the class definition. If you don't reference that class the SFK will boot OK.
Q: My application, which is a refsys module, generates a really long compile line and causes this error in Win2k:
The input line is too long.
The syntax of the command is incorrect.
make[1]: *** [obj/rtose_debug/sigdb.c] Error 255
A: Win2k, unlike WinXP, has a 2K line length limit for batch files. If this is a problem, there is a patch for it for OSE5.x available from support.
Q: Trying to use OSE with the ARMulator and want to use “printf”, because ARMulator has restrictions in output (e.g. no file system, no serial port). Does the libc from OSE support printf that goes straight to a software interrupt which allows ARMulator to print out in its own way? Instead of going through efs_stdout() as it normally does in OSE?
A: Yes our libc supports printf(), but not really in this context. To get around this problem for now, you must trick the ARM compiler into using its own printf() rather than OSEs. The easiest way is to change the link order at link time so that ARM’s libc preceeds (overrides) OSE’s. That way you’ll link up to the ARM version of printf() which has the SWI capability built-in.
Q: I’m using Emanate and I’m looking for a MIB browser that works with their stuff.
A: There isn’t one available in the older releases of Emanate, which are all the releases that OSE supports. However the next Emanate release coming up which is 17.1 does have a new GUI MIB browser tool.
Q: I want to do run-time source analysis of our OSE system at the source level. I.e. not System-level like Illuminator, but at the function level, e.g. how many times is a function called and how much time is spent running each function. Is there a vendor that supplies a tool like this that is already OSE-aware?
A: Not at the present time. There are several vendor tools that come close to what you want, and work for other RTOS. With some effort they could be made to work on OSE. Here are some:
-----------------
Site: www.suresofttech.com / www.codescroll.com
Product: CodeScroll
This Korean co. makes an embedded testing software that already works with lots of other OS including Wind River, QNX, Nucleus, and others.
-----------------
Site: www.s2technologies.com
Product: STRIDE
S2 is based in SoCal and their product is a full-blown SDK toolkit with panel, dev studio etc. – all GUI based.
-----------------
Vendor: DDC-I
Site: www.ddci.com
Product: internal
At one time they had a profiling type of tool that worked with OSE, but its been in the archives for a while.
Q: We are using Green Hills as our compiler with OSE4.6.1, but we are running into an undefined reference in librtc to what appears to be a 64-bit math function, __udivdi3, that is only defined in libgcc.a. Are we supposed to link with libgcc even with Green Hills?
A: You'll need to add libgcc.a to the end of your list of libraries input to the linker. That's because we build rtc now with gcc, and gcc apparently doesn't resolve all the math functions till link time. If this library is last, it won't affect anything else.
Q: I’m using MULTI Debugger and I see in the OSE documentation a reference to “oseinit 50000”. I can’t figure out what this is.
A: It’s an obsolete command that no longer works for OSE/MULTI combination. It has been removed in the newer releases, but the “oseserv” command is the correct one.
A: Sometimes on some systems, Eclipse does not inherit the environment from windows properly and doesn’t know your path. Specifically, it cannot find the lmgr9a.dll license file required for the soft kernel license. However you’ll only get that hint when you Run and you won’t see this file mentioned when you Debug. There is no good long-term solution I know of, and I don’t why this happens to some users. But the quickest way around it for now is to just copy over the lmgr9a.dll file from $OSE_ROOT/bin/win32/ over to your rtose/sfk-win32 directory. Then it will always be found by the debug launcher.
Q: I’m running a soft kernel with some C++ in the application, and it’s crashing:
(gdb) run -c rtose5.conf
Starting program: /cygdrive/c/ose/ose5.1/refsys/rtose/sfk-win32/obj/rtose_debug/
rtose.exe -c rtose5.conf
SFK: biosCall 0x4a before bios initialized!!
SFK: Cannot error calls or any other syscalls this early, exiting.
A: One possible cause is dead code in the cpp source file of a problem class. The dead code may be outside of the class. For example:
tFILE* gfpStdOut = stdout;
The pointer does not have to be used at all. But referencing this class the SFK will crash, even if the dead code is outside of the class definition. If you don't reference that class the SFK will boot OK.
Q: My application, which is a refsys module, generates a really long compile line and causes this error in Win2k:
The input line is too long.
The syntax of the command is incorrect.
make[1]: *** [obj/rtose_debug/sigdb.c] Error 255
A: Win2k, unlike WinXP, has a 2K line length limit for batch files. If this is a problem, there is a patch for it for OSE5.x available from support.
Q: Trying to use OSE with the ARMulator and want to use “printf”, because ARMulator has restrictions in output (e.g. no file system, no serial port). Does the libc from OSE support printf that goes straight to a software interrupt which allows ARMulator to print out in its own way? Instead of going through efs_stdout() as it normally does in OSE?
A: Yes our libc supports printf(), but not really in this context. To get around this problem for now, you must trick the ARM compiler into using its own printf() rather than OSEs. The easiest way is to change the link order at link time so that ARM’s libc preceeds (overrides) OSE’s. That way you’ll link up to the ARM version of printf() which has the SWI capability built-in.
Q: I’m using Emanate and I’m looking for a MIB browser that works with their stuff.
A: There isn’t one available in the older releases of Emanate, which are all the releases that OSE supports. However the next Emanate release coming up which is 17.1 does have a new GUI MIB browser tool.
Q: I want to do run-time source analysis of our OSE system at the source level. I.e. not System-level like Illuminator, but at the function level, e.g. how many times is a function called and how much time is spent running each function. Is there a vendor that supplies a tool like this that is already OSE-aware?
A: Not at the present time. There are several vendor tools that come close to what you want, and work for other RTOS. With some effort they could be made to work on OSE. Here are some:
-----------------
Site: www.suresofttech.com / www.codescroll.com
Product: CodeScroll
This Korean co. makes an embedded testing software that already works with lots of other OS including Wind River, QNX, Nucleus, and others.
-----------------
Site: www.s2technologies.com
Product: STRIDE
S2 is based in SoCal and their product is a full-blown SDK toolkit with panel, dev studio etc. – all GUI based.
-----------------
Vendor: DDC-I
Site: www.ddci.com
Product: internal
At one time they had a profiling type of tool that worked with OSE, but its been in the archives for a while.
Q: We are using Green Hills as our compiler with OSE4.6.1, but we are running into an undefined reference in librtc to what appears to be a 64-bit math function, __udivdi3, that is only defined in libgcc.a. Are we supposed to link with libgcc even with Green Hills?
A: You'll need to add libgcc.a to the end of your list of libraries input to the linker. That's because we build rtc now with gcc, and gcc apparently doesn't resolve all the math functions till link time. If this library is last, it won't affect anything else.
Q: I’m using MULTI Debugger and I see in the OSE documentation a reference to “oseinit 50000”. I can’t figure out what this is.
A: It’s an obsolete command that no longer works for OSE/MULTI combination. It has been removed in the newer releases, but the “oseserv” command is the correct one.
Labels: emanate, flexlm, ghs, lmgr9a.dll, sfk, win2k
free invisible web counter
