tools chain. I have it for the IAR KS but would like to use it on the
GNU as my code may go over 32K.
> Has anyone ported the Micoc/OS-II to the LPC2000 ARM to Eclipse/GNU
> tools chain. I have it for the IAR KS but would like to use it on the
> GNU as my code may go over 32K.
Yes. Well, GNU tools anyway, you can figure out the
The code excludes the uCOS-II source code. I used the
2nd Edition book source, and several more recent versions
without any issues.
> > tools chain. I have it for the IAR KS but would like to use
> it on the
> > GNU as my code may go over 32K.
> Yes. Well, GNU tools anyway, you can figure out the
> Eclipse part.
For the Eclipse part:
13 official architecture ports, 1000 downloads per week.
Certified by T as meeting the requirements for safety related systems.
Sent: Monday, October 15, 2007 1:28 PM
Subject: [lpc2000] Re: Micrium UCOS-II
I am trying to port this software to a LPC-E2294 Olimex board.
Its is not working and need to know which files I need to build to
get a basic system going.
There is an example in the Files section:
Amateur radio call-sign G1HSM
Yaesu FT-817ND and FT-857D transceivers
Suzuki SV1000S motorcycle
the startup code
--- In l..., "Leon" wrote:
> ----- Original Message -----
> From: "jdauchot"
> Sent: Monday, October 15, 2007 1:28 PM
> Subject: [lpc2000] Re: Micrium UCOS-II
> Hi Richard
> I am trying to port this software to a LPC-E2294 Olimex board.
> Its is not working and need to know which files I need to build to
> get a basic system going.
> There is an example in the Files section:
> Leon Heller
> Amateur radio call-sign G1HSM
> Yaesu FT-817ND and FT-857D transceivers
> Suzuki SV1000S motorcycle
> not get passed the startup code
Could you clarify?
From the previous messages in your post, it looked
like you were trying to build the gcc_and_ucosii.zip
code from within Eclipse.
So do you have a working command-line version built,
and its the Eclipse setup you're having trouble with,
or something else?
The project compiles ok and load into yhe LPC2294
But it does not get the main.c
Van you help
--- In l..., David Hawkins wrote:
> > I have this and I am having problems with is, it does
> > not get passed the startup code
> Could you clarify?
> From the previous messages in your post, it looked
> like you were trying to build the gcc_and_ucosii.zip
> code from within Eclipse.
> So do you have a working command-line version built,
> and its the Eclipse setup you're having trouble with,
> or something else?
> But it does not get the main.c
> Can you help
Sure, I can tell you how to solve your problems,
but you'll have to do the work so that you learn
I don't have a LPC2294 kit. However, I did play with
both the Keil LPC2138 kit, and an Olimex LPC-E2129
when I wrote the code.
The main difference regarding the processor was to
get the linker file correct. The board differences
were related to LED addresses, so for each board
you'd create a board-support-package (BSP) specific
set of LED functions.
So I suspect you have a linker error.
Before trying to get a uCOS-II program running,
did you go through and get an assembler-based
blink-LED, or toggle I/O pin working, and then
graduate up to a C-coded version?
Only after confirming those two work is it worth
then trying the OS programs.
If the LPC2294 is a processor with an external bus,
and you want to run from SRAM/Flash on the internal
bus. Then that is another set of iterations.
So, to start with, 'walk, don't run'; try to use
the internal Flash with very simple programs, i.e.,
try the non-OS programs.
> Yes to all your questions
> I have code that I have written and ran in to the
> board and works OK
Ok, so stand-alone code works.
> I did modify the bsp code etc and changed the linker
> script hopefully so it should work.
Ok, next questions:
1. Did you test stand-alone interrupt code?
2. Is the problem only with uCOS-II code?
3. Did you try the uCOS stuff with just a make file?
(i.e., take Eclipse out of the equation for the moment)
When I was developing the uCOS-II code, I did it using
an LED. I edited the uCOS-II source, or the port source
and added a lock-up-and-die statement that turned on an
LED when it got to that line of code. That way, using 2
LEDs, I could track down that I was getting to point A,
but not to point B. Most definitely a poor-mans debugger,
but it wasn't a big deal as I didn't have to do that
too many times.
So if you're down to debugging why uCOS-II code is not
working, I'd add this sort of code to your first task
to see if its getting called, and if its not, then
back-off to OSStart() etc. However, I know this code works,
and I'm pretty sure other people have used it, so I
don't think the ported code is going to be the source
of your problem.
What version of the uCOS-II source code are you using?
It was written for using the code that comes with the
2nd Edition of the book; although I did test it with
a couple of more recent versions, and it worked fine.
If you are using very recent OS source, then back-off to
the book version and start there.
> which I doubt), is as simple as finishing the crt.s code.
> So, is crt.s reasonable? Is it branching to main() with interrupts
> enabled? Some tutorial versions leave the processor with interrupts
> disabled and running in user mode.
> So, that's another point: what mode are you in when you branch to
> main(). It should be SYSTEM, not USER.
Lots of good debugging tips.
If you used the original makefiles that came with the
projects, and edited them appropriately (to your specific
setup). Then the appropriate crt.s should be getting
picked-up. I can't recall, I might have called it
start.s just to force readers of the tutorial to understand
that crt0.s code was 'special' in that you had to code it.
Use objdump on the final elf files produced, and you can compare
the disassembly output to the various pieces of code you were
expecting to show up in the elf file.