Hi Dave

Yes to all your questions

I have code that I have written and ran in to the board and works OK

I did modify the bsp code etc and changed the linker script hopefully
so it should work.

Regrads

Jean-jacques

--- In l..., David Hawkins wrote:
> > The project compiles ok and load into the LPC2294
> >
> > 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
> something.
>
> 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.
>
> Cheers,
> Dave
> Start a New Thread

You said earlier that you weren't getting to main(). How did you show
that?

Getting to main() (unless uCOS-II uses constructors and destructors,
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.

Even if there aren't a lot of LEDs on the board, there are probably a
lot of pins you can set/reset as the code progresses. I usually watch
them with a scope but sometimes with a logic analyzer. I don't
usually use JTAG for debugging - mostly because I haven't gotten it to
work under Linux.

It's probably worth the time to get a blinking LED running using a
timer interrupt.

Richard Start a New Thread

Hi Dave

Thanks for all comments

> 1. Did you test stand-alone interrupt code?

Yes, the test code I use has Timer0 interrupt at 10ms

I know that the code does not get to main is that thr very first this
I do is to initialise the LCD display and display a test message
which does not happen

I use the uCos supplied with the book

> 3. Did you try the uCOS stuff with just a make file?
> (i.e., take Eclipse out of the equation for the moment)

No I have not tryied that yet

I do not have LED on test board but I could try using a LPC2148 board
I have which has LED

Regards

Jean-Jacques

--- In l..., David Hawkins wrote:
>
> Hi Jean-jacques,
>
> > 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.
>
> Cheers,
> Dave
> Start a New Thread

Hi Jean-Jacques,

> I know that the code does not get to main is that the
> very first this I do is to initialise the LCD display
> and display a test message which does not happen

I would assert an I/O pin on the board first to
determine whether you are not getting to main, or
are getting to main, but your LCD code has a bug.

Since the example is simplified, I can't recall if
the code handles data aborts etc. Chances are you are
getting an abort of some type, and the processor
is then jumping to an abort handler that is an
infinite loop, or goes off into la-la-land if there
is no handler.

> I use the uCos supplied with the book

Ok, it should be fine.

>> 3. Did you try the uCOS stuff with just a make file?
>> (i.e., take Eclipse out of the equation for the moment)
>
> No I have not tried that yet
>
> I do not have LED on test board but I could try using a LPC2148 board
> I have which has LED

It doesn't have to be an LED, and I/O pin would be fine,
and use a scope. Although if you have an I/O pin its
pretty easy to make an LED+resistor probe to hang off
an I/O pin - everyone writing embedded software should
have several of those lying around :)

Before trying to add your LCD code, make sure the
example code builds and works correctly.

Cheers,
Dave Start a New Thread

Hi Dave

Which of your example is best to try out first ?

I have been try with ex1

Regards

Jean-Jacques
--- In l..., David Hawkins wrote:
>
> Hi Jean-Jacques,
>
> > I know that the code does not get to main is that the
> > very first this I do is to initialise the LCD display
> > and display a test message which does not happen
>
> I would assert an I/O pin on the board first to
> determine whether you are not getting to main, or
> are getting to main, but your LCD code has a bug.
>
> Since the example is simplified, I can't recall if
> the code handles data aborts etc. Chances are you are
> getting an abort of some type, and the processor
> is then jumping to an abort handler that is an
> infinite loop, or goes off into la-la-land if there
> is no handler.
>
> > I use the uCos supplied with the book
>
> Ok, it should be fine.
>
> >> 3. Did you try the uCOS stuff with just a make file?
> >> (i.e., take Eclipse out of the equation for the moment)
> >
> > No I have not tried that yet
> >
> > I do not have LED on test board but I could try using a LPC2148
board
> > I have which has LED
>
> It doesn't have to be an LED, and I/O pin would be fine,
> and use a scope. Although if you have an I/O pin its
> pretty easy to make an LED+resistor probe to hang off
> an I/O pin - everyone writing embedded software should
> have several of those lying around :)
>
> Before trying to add your LCD code, make sure the
> example code builds and works correctly.
>
> Cheers,
> Dave
> Start a New Thread

Hi Jean-Jacques,

> Which of your example is best to try out first ?
>
> I have been try with ex1

Since you're debugging, why not cut things down to
a minimum, i.e., replace the two tasks in ex1 with
just one:

/* Task: blink an LED */
void TestTask1(void *pdata)
{
timer_init();

while(1) {
dbg_led_on();
OSTimeDlyHMSM(0, 0, 1, 0);
dbg_led_off();
OSTimeDlyHMSM(0, 0, 1, 0);
}
}
where dbg_led_on()/off() would be a function to
control a single I/O.

But by your previous comments, you're not even
getting this far, as you state that your LCD
initialization code in main() is not getting
run.

Note that your LED code can not have OS calls
until *after* you start the OS. So if you happen
to initialize semaphores or anything like that,
it should happen in TestTask1.

Try using an I/O pin to indicate where your code
is getting to, and then with that knowledge, you'll
know which piece of code to start debugging.

Cheers,
Dave Start a New Thread

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.

Regards

Jean-Jacques

--- In l..., "FreeRTOS.org Info"
wrote:
>
> > > 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
> > Eclipse part.
>
> For the Eclipse part:
>
> http://www.freertos.org/portlpc2368_Eclipse.html
> http://www.freertos.org/Eclipse.html
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> 13 official architecture ports, 1000 downloads per week.
>
> + http://www.SafeRTOS.com
> Certified by T as meeting the requirements for safety related
systems.
>



Start a New Thread

Hi Dave

I got the code to work. But this is what I had to do

In the start.s file I had to bypass the init data code
See Below <<<<<<<<<<<<<<<< comments

stacks_init:
ldr r0, STACK_START

/* FIQ mode stack */
msr CPSR_c, #FIQ_MODE|IRQ_DISABLE|FIQ_DISABLE
mov sp, r0
sub r0, r0, #FIQ_STACK_SIZE

/* IRQ mode stack */
msr CPSR_c, #IRQ_MODE|IRQ_DISABLE|FIQ_DISABLE
mov sp, r0
sub r0, r0, #IRQ_STACK_SIZE

/* Supervisor mode stack */
msr CPSR_c, #SVC_MODE|IRQ_DISABLE|FIQ_DISABLE
mov sp, r0
sub r0, r0, #SVC_STACK_SIZE

/* Undefined mode stack */
msr CPSR_c, #UND_MODE|IRQ_DISABLE|FIQ_DISABLE
mov sp, r0
sub r0, r0, #UND_STACK_SIZE

/* Abort mode stack */
msr CPSR_c, #ABT_MODE|IRQ_DISABLE|FIQ_DISABLE
mov sp, r0
sub r0, r0, #ABT_STACK_SIZE

/* System mode stack */
/* msr CPSR_c, #SYS_MODE|IRQ_DISABLE|FIQ_DISABLE */
msr CPSR_c, #SYS_MODE
mov sp, r0

bl main <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< main works here

/* Leave the processor in system mode */

/* ----------------------------
* C runtime setup
* ----------------------------
*/
runtime_init:
/* Copy .data */
ldr r0, data_source
ldr r1, data_start
ldr r2, data_end
copy_data:
cmp r1, r2
ldrne r3, [r0], #4
strne r3, [r1], #4
bne copy_data

bl main <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Jump to
main does not work

/* Clear .bss */
ldr r0, =0
ldr r1, bss_start
ldr r2, bss_end
clear_bss:
cmp r1, r2
strne r0, [r1], #4
bne clear_bss

/* Jump to main */
bl main <<<<<<<<<<<<<<<<<<<<<<<<<<<<< does not work passed here

/* Catch return from main */
loop: b loop

I am very greatfull for your halp and the rest of the group

Regards

Jean-jacques

--- In l..., David Hawkins wrote:
>
> Hi Jean-Jacques,
>
> > Which of your example is best to try out first ?
> >
> > I have been try with ex1
>
> Since you're debugging, why not cut things down to
> a minimum, i.e., replace the two tasks in ex1 with
> just one:
>
> /* Task: blink an LED */
> void TestTask1(void *pdata)
> {
> timer_init();
>
> while(1) {
> dbg_led_on();
> OSTimeDlyHMSM(0, 0, 1, 0);
> dbg_led_off();
> OSTimeDlyHMSM(0, 0, 1, 0);
> }
> }
> where dbg_led_on()/off() would be a function to
> control a single I/O.
>
> But by your previous comments, you're not even
> getting this far, as you state that your LCD
> initialization code in main() is not getting
> run.
>
> Note that your LED code can not have OS calls
> until *after* you start the OS. So if you happen
> to initialize semaphores or anything like that,
> it should happen in TestTask1.
>
> Try using an I/O pin to indicate where your code
> is getting to, and then with that knowledge, you'll
> know which piece of code to start debugging.
>
> Cheers,
> Dave
> Start a New Thread

Hi Richard

I know all this setup stuff for c code is important, but I wanted to
get this going. The code works !!!!! but why without the init code?

I am using your orginal .ld file with the memory linits changed

2294 has 256K Flash and 16K ram , so I changed that

Also the STACK_START changed to 0x400001EC in start.s

The code works oK with 2 tasks going so I am happy so far

Regards

Jean-jacques

--- In l..., "rtstofer" wrote:
>
> > /* System mode stack */
> > /* msr CPSR_c, #SYS_MODE|IRQ_DISABLE|FIQ_DISABLE */
> > msr CPSR_c, #SYS_MODE
> > mov sp, r0
> >
> > bl main <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< to
> > main works here
>
> Note that you are branching to main() with interrupts disabled and
in
> system mode. This is ok because, in system mode, you can change
CPSR_c.
>
> >
> > /* Leave the processor in system mode */
> >
> > /* ---------------------------
-
> > * C runtime setup
> > * ---------------------------
-
> > */
> > runtime_init:
> > /* Copy .data */
> > ldr r0, data_source
> > ldr r1, data_start
> > ldr r2, data_end
> > copy_data:
> > cmp r1, r2
> > ldrne r3, [r0], #4
> > strne r3, [r1], #4
> > bne copy_data
> >
> > bl main <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Jump
to
> > main does not work
>
> Are data_source, data_start and data_end defined in your linker
> script? Take a look at the .elf file and see what values are passed
> by the linker. Do this by creating a .lss file with your makefile:
>
> OBJDUMP=arm-elf-objdump
> ODFLAGS = -h -S -t
>
> list : ${TARGET}.elf
> ${OBJDUMP} ${ODFLAGS} ${TARGET}.elf > ${TARGET}.lss
>
> or from the command line like:
>
> arm-elf-objdump -h -S -t .elf > .lss
>
> Wander down the list until you find the dissassembly code for the
> startup section.
>
> >
> > /* Clear .bss */
> > ldr r0, =0
> > ldr r1, bss_start
> > ldr r2, bss_end
> > clear_bss:
> > cmp r1, r2
> > strne r0, [r1], #4
> > bne clear_bss
> >
> > /* Jump to main */
> > bl main <<<<<<<<<<<<<<<<<<<<<<<<<<<<< does not work passed
here
> > Same problem: are bss_start and bss_end defined by the linker
script?
>
> Not being able to initialize .data and .bss for a C program is a
> serious problem. C depends on initial values.
>
> Richard
> Start a New Thread

--- In l..., "jdauchot" wrote:
>
> Hi Dave
>
> I got the code to work. But this is what I had to do
>
> In the start.s file I had to bypass the init data code
Now it is time to go back and find out why your RAM initialization
code failed, or you are likely to have some very interesting problems
in the future using this start.s file with RAM initialization
bypassed, if you have less than trivial C code. Start a New Thread