Re: [ECOS] Re: diag_printf via serial port

[Sergei Gavrikov <w3sg at SoftHome dot net>]

Ð ÐÑÐ, 01/06/2007 Ð 19:26 +0700, Alexey Shusharin ÐÐÑÐÑ:
> Hello, Sergei
> 
> No, I don't use interrupt driven serial driver. On the contrary, I 
> wouldn't use it. Did you try load and start application on Olimex 
> LPC-E2294 via serial port?

Yes, I did that, certainly. That works.

> As example I wrote a small test:
> 
> static void first_thread(CYG_ADDRESS data)
> {
> 	diag_printf("\nWe should see this string\n");
> }

Ups, your thread exits at once :)

Alexey, with a default eCos settings the eCos 'examples/twothreads'
works without any tricks. You have to agree that is a bit complex test
than your.

Just now I haven't LPC-E2294 board on my desk, but I have the LPC-H2294.
That target has just single serial channel at all. Both boards use
lpc2xxx variant. Do you agree?

I did fulfil this "lab" just now as I do it as well

ecosconfig new olpch2294
ecosconfig tree
make -s

make -C $ECOS_REPOSITORY/../examples INSTALL_DIR=`pwd`/install clean
make -C $ECOS_REPOSITORY/../examples \
INSTALL_DIR=`pwd`/install twothreads

arm-elf-gdb -q -nx $ECOS_REPOSITORY/../examples/twothreads
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
0x00005794 in ?? ()
(gdb) load
Loading section .rom_vectors, size 0x40 lma 0x81008000
Loading section .text, size 0xb728 lma 0x81008040
Loading section .rodata, size 0x39c lma 0x81013768
Loading section .data, size 0x3bc lma 0x81013b04
Start address 0x81008040, load size 48832
Transfer rate: 24416 bits/sec, 295 bytes/write.
(gdb) cont
Continuing.
Entering twothreads' cyg_user_start() function
Beginning execution; thread data is 0
Beginning execution; thread data is 1
Thread 0: and now a delay of 239 clock ticks
Thread 1: and now a delay of 230 clock ticks
Thread 1: and now a delay of 221 clock ticks
Thread 0: and now a delay of 214 clock ticks
Thread 1: and now a delay of 224 clock ticks
[New Thread 4]

I press ^C to interrupt a run (just for demo):

Program received signal SIGINT, Interrupt.
[Switching to Thread 4]
cyg_hal_user_break (regs=0x0)
at /home/sg/ecos/ecos/packages/hal/common/current/src/hal_misc.c:138
138
CYGARC_HAL_GET_RETURN_ADDRESS_BACKUP(_cyg_hal_compiler_dummy);
Current language:  auto; currently c

Resume the run:

(gdb) cont
Continuing.
Thread 0: and now a delay of 243 clock ticks
Thread 1: and now a delay of 210 clock ticks
Thread 0: and now a delay of 224 clock ticks
Thread 1: and now a delay of 207 clock ticks

It's enough. Interrup run again and detach from target

Program received signal SIGINT, Interrupt.
cyg_hal_user_break (regs=0x0)
at /home/sg/ecos/ecos/packages/hal/common/current/src/hal_misc.c:138
138
CYGARC_HAL_GET_RETURN_ADDRESS_BACKUP(_cyg_hal_compiler_dummy);
(gdb) detach
Ending remote debugging.
(gdb) q

You see that quite works with GDB 5.3. That executable works with
RedBoot too.

> I found a bug in the variant layer of hal. It locates in 
> cyg_hal_plf_serial_isr() (/hal/arm/lpc2xxx/var/current/src/hal_diag.c). 
> This function handles UART interrupt but does't read UxIIR register in 
> order to clear the interrupt flag. So, the cyg_hal_plf_serial_isr()
> calling never stops and prevents dsr and thread execution.

I doubt that lpc2xxx variant HAL has the bug, but who knows. I will look
that place tonight.

regards,

-- Sergei



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss