[ECOS] Re: diag_printf via serial port

[ECOS] Re: diag_printf via serial port

[cetoni GmbH - Uwe Kindler]

Hello Alexey,

which serial channel do you use for the serial connection? I also have a 
LPC-E2294 board (Rev. B) here. Do you use the onboard USB connector or 
the onboard RS232 D-Sub connector for serial conection?

Best regards

Uwe

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

[ECOS] Re: diag_printf via serial port

[Alexey Shusharin]

cetoni GmbH - Uwe Kindler пишет:
> Hello Alexey,
> 
> which serial channel do you use for the serial connection? I also have a 
> LPC-E2294 board (Rev. B) here. Do you use the onboard USB connector or 
> the onboard RS232 D-Sub connector for serial conection?
> 
> Best regards
> 
> Uwe
> 
Hello Uwe,

I use USB connector. Do you test Sergei's port? You can find it on his 
home page (http://sgs.gomel.by/sg/articles/olpce2294/index.html).

However, I clear up some of features.

It's not a problem of /dev/ttydiag. I don't understand why, but then I 
use the serial connection instead of the ethernet my thread doesn't 
start (it doesn't perform other work). cyg_user_start() works properly 
and its output appear on the serial port.

Additionally I found that then Hardware serial device drivers is enabled 
thread starts and works fine. It's strange because /dev/haldiag uses a 
RedBoot comm channels.

I found that the thread doesn't start because Cyg_RealTimeClock::dsr 
never be called after Cyg_RealTimeClock::isr. At this moment I know only 
that Cyg_Scheduler::unlock_inner (it calls dsr eventually) never starts. 
I'm newbie in ecos and a process moves slowly.

Best regards
Alexey Shusharin

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

[ECOS] Re: diag_printf via serial port

[cetoni GmbH - Uwe Kindler]

Hello Alexey,

please try the onboard RS232 D-Sub connector instead of USB connector. 
If I debug an application via JTAG the I only see the debug output if I 
connect via RS232 D-SUB connector.

Regards, Uwe

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

Re: [ECOS] Re: diag_printf via serial port

[Sergei Gavrikov]

Alexey Shusharin wrote:
> Uwe Kindler wrote:
> > Hello Alexey,
> > 
> > which serial channel do you use for the serial connection? I also have a 
> > LPC-E2294 board (Rev. B) here. Do you use the onboard USB connector or 
> > the onboard RS232 D-Sub connector for serial conection?
> > 
> > Best regards
> > 
> > Uwe
> > 
> Hello Uwe,
> 
> I use USB connector. Do you test Sergei's port? You can find it on his 
> home page (http://sgs.gomel.by/sg/articles/olpce2294/index.html).
> 
> However, I clear up some of features.
> 
> It's not a problem of /dev/ttydiag. I don't understand why, but then I 
> use the serial connection instead of the ethernet my thread doesn't 
> start (it doesn't perform other work). cyg_user_start() works properly 
> and its output appear on the serial port.

Alexey, as far as I could understand, you try to busy one serial port
(UART0) by a triple work: for the debugging, for the diagnostic and for
the interrupt driven TTY mode, but that isn't possible.

You should use the second port on the board (D-Sub UART1) for TTY mode
(/dev/ser1) and using CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE option to point
what stdio output should appear there, i.e. printf() output (!diag)
shouldn't appear on /dev/ttydiag. By default, stdio output quite flows
via /dev/ttydiag.


-- 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

Re: [ECOS] Re: diag_printf via serial port

[Alexey Shusharin]

Sergei Gavrikov wrote:
 >
 > Alexey, as far as I could understand, you try to busy one serial port
 > (UART0) by a triple work: for the debugging, for the diagnostic and for
 > the interrupt driven TTY mode, but that isn't possible.
 >
 > You should use the second port on the board (D-Sub UART1) for TTY mode
 > (/dev/ser1) and using CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE option to point
 > what stdio output should appear there, i.e. printf() output (!diag)
 > shouldn't appear on /dev/ttydiag. By default, stdio output quite flows
 > via /dev/ttydiag.

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?
As example I wrote a small test:

static void first_thread(CYG_ADDRESS data)
{
	diag_printf("\nWe should see this string\n");
}

void cyg_user_start(void)
{
     diag_printf("enter cyg_user_start()\n");

     cyg_thread_create(4, first_thread, (cyg_addrword_t) 0, "smalltest",
                       (void *)stack, STACKSIZE, &thread, &thread_obj);
     cyg_thread_resume(thread);

     diag_printf("exit cyg_user_start()\n");
}


Then I connect via ethernet:

telnet 172.16.0.2 9000
Trying 172.16.0.2...
Connected to 172.16.0.2 (172.16.0.2).
Escape character is '^]'.
RedBoot> load smalltest.elf
Using default protocol (TFTP)
Entry point: 0x81010040, address range: 0x81010000-0x81016e60
RedBoot> go
enter cyg_user_start()
exit cyg_user_start()

We should see this string     <----- test work properly


Then I connect via serial port:

RedBoot> load -m xmodem 

CEntry point: 0x81010040, address range: 0x81010000-0x81016e60
xyzModem - CRC mode, 478(SOH)/0(STX)/0(CAN) packets, 1 retries
RedBoot> go
enter cyg_user_start()
exit cyg_user_start()

                              <----- I don't see test string


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.

The test began working properly then I has added a read operation of 
UxIIR. I will send a patch to ecos-patches mailing list in a short time.

Best regards
Alexey Shusharin



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

Re: [ECOS] Re: diag_printf via serial port

[Sergei Gavrikov]

В Птн, 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

Re: [ECOS] Re: diag_printf via serial port

[Sergei Gavrikov]

Alexey Shusharin wrote:
> cetoni GmbH - Uwe Kindler wrote:
> > Hello Alexey,
> > 
> > which serial channel do you use for the serial connection? I also have a 
> > LPC-E2294 board (Rev. B) here. Do you use the onboard USB connector or 
> > the onboard RS232 D-Sub connector for serial conection?
> > 
> > Best regards
> > 
> > Uwe
> > 
> Hello Uwe,
> 
> I use USB connector. Do you test Sergei's port? You can find it on his 
> home page (http://sgs.gomel.by/sg/articles/olpce2294/index.html).

Alexey, I forgot about one thing, 2007/01/31 I fixed one issue for my
Olimex boards. What EPK (package) do you use? Is that the latest HAL?
Look here http://sgs.gomel.by/sg/ , please, the latest HAL I put here:
http://sgs.gomel.by/sg/downloads/olpcx2294-latest


Kind 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

Re: [ECOS] Re: diag_printf via serial port

[Sergei Gavrikov]

On Fri, Jun 01, 2007 at 07:26:53PM +0700, Alexey Shusharin wrote:
> 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.
> 
> The test began working properly then I has added a read operation of 
> UxIIR. I will send a patch to ecos-patches mailing list in a short time.

Hello

It seems that you were right. I went to the NXP's documents page and did
choose to read that application notes AN10414/Rev.01 (the appnote is
dated 2006/01/04, the lpc2xxx variant HAL is elder :)
http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/an10414.pdf

The NXP's uart_isr() prototype (from appnote) operates with the
CYGARC_HAL_LPC2XXX_REG_UxIIR, and cyg_hal_plf_serial_isr() don't. More
that, in the application note they talk that is important. I got the
spurrious iterrupt reports with my elder plf HAL for Olimex and I've
done some things in plf HAL. It's possible, that was UxIIR issue.

Well, eCos/LPC2XXX community is looking for your patch ;)


Best 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

Re: [ECOS] Re: diag_printf via serial port

[Alexey Shusharin]

Sergei Gavrikov wrote:
> 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.

Hello Sergei,

Of course, I tryed to run twothreads example. Moreover, I simplifyed it 
  and got my test. Twothreads does't work on my board (via serial). :-(

It's strange, that your board works via serial. Maybe in your 
configuration interrupt driven serial driver is enabled. It overwrites 
variant implementation. In that case, my board works too. But, it 
doesn't matter now.

Thanks for replying. :-)

Best regards
Alexey Shusharin

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

Re: [ECOS] Re: diag_printf via serial port

[Sergei Gavrikov]

On Fri, Jun 01, 2007 at 11:35:39PM +0700, Alexey Shusharin wrote:

> It's strange, that your board works via serial. Maybe in your
> configuration interrupt driven serial driver is enabled. It overwrites
> variant implementation. In that case, my board works too. But, it
> doesn't matter now.

At least one time in a week I rsync the eCos anonymous cvs tree with my
worked copy of the ECOS_REPOSITORY. I've done that today too. I'd done
no changes in Olimex plf HAL since 2007/01/31. So, I would want be sure
that your RedBoot, eCos test and your eCos repository is a freshmeat.
AFAIK, default ecos.ecc (configuration) uses ROM monitor (ROM calling
interface). Therefore, any out dated RedBoot stuff can be a reason of
the difference. 

So, 1) do cvs checkout; 2) download the latest epk, add it to ecos db
(ecosadmin.tcl), apply that CS8900A patch; 3) rebuild/upgrade RedBoot;
4) build the 'examples/twothreads'.

Note: Be sure that you didn't mess any sources in $ECOS_REPOSITORY
before. As I did note, it's better to rsync cvs tree with your worked
tree.

Only in such a case, it will be possible to compare our lab's results. 

A moment ago, I did repeat that lab with 1 only difference. I began do
that with line a 'ecosconfig new olpce2294' instead of that 'ecosconfig
new olpch2294' :-) The results are same (as I got for LPC-H2294). The
'twothreads' worked as expected. I even didn't connect RJ-45 for the
lab :-)

Kind 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

Re: [ECOS] Re: diag_printf via serial port

[Sergei Gavrikov]

On Fri, Jun 01, 2007 at 11:35:39PM +0700, Alexey Shusharin wrote:
> Sergei Gavrikov wrote:
> >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.
> 
> Hello Sergei,
> 
> Of course, I tryed to run twothreads example. Moreover, I simplifyed it 
>  and got my test. Twothreads does't work on my board (via serial). :-(
> 
> It's strange, that your board works via serial. Maybe in your 
> configuration interrupt driven serial driver is enabled. It overwrites 
> variant implementation. In that case, my board works too. But, it 
> doesn't matter now.

At least one time in a week I rsync the eCos anonymous cvs tree with my
worked copy of the ECOS_REPOSITORY. I've done that today too. I'd done
no changes in Olimex plf HAL since 2007/01/31. So, I would want be sure
that your RedBoot, eCos test and your eCos repository is a freshmeat.
AFAIK, default ecos.ecc (configuration) uses ROM monitor (ROM calling
interface). Therefore, any out dated RedBoot stuff can be a reason of
the difference. 

So, 1) do cvs checkout; 2) download the latest epk, add it to ecos db
(ecosadmin.tcl), apply that CS8900A patch; 3) rebuild/upgrade RedBoot;
4) build the 'examples/twothreads'.

Note: Be sure that you didn't mess any sources in $ECOS_REPOSITORY
before. As I did note, it's better to rsync cvs tree with your worked
tree.

Only in such a case, it will be possible to compare our lab's results. 

A moment ago, I did repeat that lab with 1 only difference. I began do
that with line a 'ecosconfig new olpce2294' instead of that 'ecosconfig
new olpch2294' :-) The results are same (as I got for LPC-H2294). The
'twothreads' worked as expected. I even didn't connect RJ-45 for the
lab :-)

Kind 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

Re: [ECOS] Re: diag_printf via serial port

[Sergei Gavrikov]

On Thu, May 31, 2007 at 06:56:52PM +0700, Alexey Shusharin wrote:
> I use USB connector. Do you test Sergei's port? You can find it on his 
> home page (http://sgs.gomel.by/sg/articles/olpce2294/index.html).
> 
> However, I clear up some of features.
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
Alexey, This would be a reason. What have you fixed there? Check that,
please.

-- 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

Re: [ECOS] Re: diag_printf via serial port

[Mike Arthur]

> It's strange, that your board works via serial. Maybe in your
> configuration interrupt driven serial driver is enabled. It overwrites
> variant implementation. In that case, my board works too. But, it
> doesn't matter now.

Could another difference be that Sergi is running through GDB and
you're loading the ELF file directly?

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

Re: [ECOS] Re: diag_printf via serial port

[Sergei Gavrikov]

On Fri, Jun 01, 2007 at 01:47:55PM -0500, Mike Arthur wrote:
> >It's strange, that your board works via serial. Maybe in your
> >configuration interrupt driven serial driver is enabled. It overwrites
> >variant implementation. In that case, my board works too. But, it
> >doesn't matter now.
> 
> Could another difference be that Sergi is running through GDB and
> you're loading the ELF file directly?

I can load ELF and run it using RedBoot's 'go' as well for the target.
It seems, that the last way, it's to send him (UTFB): redboot.bin.gz,
twothreads.gz. Recently, he wrote about tweaking lpc variant HAL:
lpc2xxx/var/current/src/hal_diag.c as I could understand.

To clean _any_ mess in $ECOS_REPOSITORY at all, I preffer to fulfil
(well that does a script, but this just a way).

i. Checkout

    cd ~/cvs
    cvs -d ... login
    cvs -z3 -d ... checkout ecos ecos-host

ii. Move a worked tree anywhere, this is that case

    mv ~/ecos/ecos{,.bak}

iii. Rsync local 'cvs' and 'worked' tree

    rsync -a ~/cvs/ecos ~/ecos

iv. Add the stuff wasn't being here (in the repository)

    tclsh ecosadmin.tcl add <package-name.epk>

vi. build, test RedBoot/eCos

So, I did suggest Alexey to fulfil almost same things to leave behind
any doubts.


-- 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

Re: [ECOS] Re: diag_printf via serial port

[Alexey Shusharin]

Sergei Gavrikov wrote:
> On Fri, Jun 01, 2007 at 11:35:39PM +0700, Alexey Shusharin wrote:
> 
>> It's strange, that your board works via serial. Maybe in your
>> configuration interrupt driven serial driver is enabled. It overwrites
>> variant implementation. In that case, my board works too. But, it
>> doesn't matter now.
> 
> At least one time in a week I rsync the eCos anonymous cvs tree with my
> worked copy of the ECOS_REPOSITORY. I've done that today too. I'd done
> no changes in Olimex plf HAL since 2007/01/31. So, I would want be sure
> that your RedBoot, eCos test and your eCos repository is a freshmeat.
> AFAIK, default ecos.ecc (configuration) uses ROM monitor (ROM calling
> interface). Therefore, any out dated RedBoot stuff can be a reason of
> the difference. 
> 
> So, 1) do cvs checkout; 2) download the latest epk, add it to ecos db
> (ecosadmin.tcl), apply that CS8900A patch; 3) rebuild/upgrade RedBoot;
> 4) build the 'examples/twothreads'.
> 
> Note: Be sure that you didn't mess any sources in $ECOS_REPOSITORY
> before. As I did note, it's better to rsync cvs tree with your worked
> tree.
> 
> Only in such a case, it will be possible to compare our lab's results. 
> 
> A moment ago, I did repeat that lab with 1 only difference. I began do
> that with line a 'ecosconfig new olpce2294' instead of that 'ecosconfig
> new olpch2294' :-) The results are same (as I got for LPC-H2294). The
> 'twothreads' worked as expected. I even didn't connect RJ-45 for the
> lab :-)
> 
> Kind regards,
> 
> -- Sergei
> 

Hello Sergei,

I found a differences in our results. It was my inattentiveness :-( . I 
got a olpce2294.epk via a reference in your article, which points to the 
old epk. Then I had gotten the latest one our results had coincided.

static void first_thread(CYG_ADDRESS data)
{
	while(1)
	{
		cyg_thread_delay(100);
		diag_printf("\nWe should see this string\n");
	}
}

arm-elf-gdb -q -nx /home/alex/smalltest.elf
(gdb) set remotebaud 38400
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
0x00007e20 in ?? ()
(gdb) load
Loading section .rom_vectors, size 0x40 lma 0x81010000
Loading section .text, size 0x69a4 lma 0x81010040
Loading section .rodata, size 0x2dc lma 0x810169e4
Loading section .data, size 0x348 lma 0x81016cc0
Start address 0x81010040, load size 28680
Transfer rate: 25493 bits/sec, 295 bytes/write.
(gdb) cont
Continuing.
enter cyg_user_start()
exit cyg_user_start()

We should see this string

We should see this string

We should see this string                 <---------- press Ctrl + C

[New Thread 3]

Program received signal SIGINT, Interrupt.
[Switching to Thread 3]
cyg_hal_user_break (regs=0x0) at 
/opt/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
(gdb) cont
Continuing.
We should see this string

We should see this string

We should see this string


As far as I understand, In the latest epk you masked the interrupt to 
prevent unceasing calling. But the error isn't in your code and changes 
in your layer are not necessary. Moreover, this changes leads to other 
issues. As example:

RedBoot> load -m xmodem 

CEntry point: 0x81010040, address range: 0x81010000-0x81017008 

xyzModem - CRC mode, 482(SOH)/0(STX)/0(CAN) packets, 1 retries 

RedBoot> go 

enter cyg_user_start() 

exit cyg_user_start() 


We should see this string 


We should see this string

We should see this string                 <---------- press Ctrl + C

We should see this string                 <---------- oops

We should see this string


Then I use your epk v1.0 with my patch of cyg_hal_plf_serial_isr 
application works as provided.

RedBoot> load -m xmodem 

CEntry point: 0x81010040, address range: 0x81010000-0x81016efc 

xyzModem - CRC mode, 478(SOH)/0(STX)/0(CAN) packets, 2 retries 

RedBoot> go 

enter cyg_user_start() 

exit cyg_user_start() 


We should see this string 


We should see this string

We should see this string                 <---------- press Ctrl + C
$T02thread:00000001;0f:40300181;0d:0ca40181;#bb

:-)

Best regards
Alexey Shusharin


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

Re: [ECOS] Re: diag_printf via serial port

[Sergei Gavrikov]

Hello Alexey,

I didn't return to epk v1_0, I just set FIX_GDB_ISR to 0 (that is same,
you see). I aplied your patch and test it. Hardware: LPC-H2294,
software: GDB5.3, sz+RedBoot. Test: stress_threads (from kernel test
suite).

All works very smoothly. Thanks for your "lab" :-) I'm really didn't
suppose that lpc2xxx variant had a missing (UxIIR).

Kind regards,

Sergei

В Пнд, 04/06/2007 в 14:36 +0700, Alexey Shusharin пишет:
> Sergei Gavrikov wrote:
> > On Fri, Jun 01, 2007 at 11:35:39PM +0700, Alexey Shusharin wrote:
> > 
> >> It's strange, that your board works via serial. Maybe in your
> >> configuration interrupt driven serial driver is enabled. It overwrites
> >> variant implementation. In that case, my board works too. But, it
> >> doesn't matter now.
> > 
> > At least one time in a week I rsync the eCos anonymous cvs tree with my
> > worked copy of the ECOS_REPOSITORY. I've done that today too. I'd done
> > no changes in Olimex plf HAL since 2007/01/31. So, I would want be sure
> > that your RedBoot, eCos test and your eCos repository is a freshmeat.
> > AFAIK, default ecos.ecc (configuration) uses ROM monitor (ROM calling
> > interface). Therefore, any out dated RedBoot stuff can be a reason of
> > the difference. 
> > 
> > So, 1) do cvs checkout; 2) download the latest epk, add it to ecos db
> > (ecosadmin.tcl), apply that CS8900A patch; 3) rebuild/upgrade RedBoot;
> > 4) build the 'examples/twothreads'.
> > 
> > Note: Be sure that you didn't mess any sources in $ECOS_REPOSITORY
> > before. As I did note, it's better to rsync cvs tree with your worked
> > tree.
> > 
> > Only in such a case, it will be possible to compare our lab's results. 
> > 
> > A moment ago, I did repeat that lab with 1 only difference. I began do
> > that with line a 'ecosconfig new olpce2294' instead of that 'ecosconfig
> > new olpch2294' :-) The results are same (as I got for LPC-H2294). The
> > 'twothreads' worked as expected. I even didn't connect RJ-45 for the
> > lab :-)
> > 
> > Kind regards,
> > 
> > -- Sergei
> > 
> 
> Hello Sergei,
> 
> I found a differences in our results. It was my inattentiveness :-( . I 
> got a olpce2294.epk via a reference in your article, which points to the 
> old epk. Then I had gotten the latest one our results had coincided.
> 
> static void first_thread(CYG_ADDRESS data)
> {
> 	while(1)
> 	{
> 		cyg_thread_delay(100);
> 		diag_printf("\nWe should see this string\n");
> 	}
> }
> 
> arm-elf-gdb -q -nx /home/alex/smalltest.elf
> (gdb) set remotebaud 38400
> (gdb) target remote /dev/ttyUSB0
> Remote debugging using /dev/ttyUSB0
> 0x00007e20 in ?? ()
> (gdb) load
> Loading section .rom_vectors, size 0x40 lma 0x81010000
> Loading section .text, size 0x69a4 lma 0x81010040
> Loading section .rodata, size 0x2dc lma 0x810169e4
> Loading section .data, size 0x348 lma 0x81016cc0
> Start address 0x81010040, load size 28680
> Transfer rate: 25493 bits/sec, 295 bytes/write.
> (gdb) cont
> Continuing.
> enter cyg_user_start()
> exit cyg_user_start()
> 
> We should see this string
> 
> We should see this string
> 
> We should see this string                 <---------- press Ctrl + C
> 
> [New Thread 3]
> 
> Program received signal SIGINT, Interrupt.
> [Switching to Thread 3]
> cyg_hal_user_break (regs=0x0) at 
> /opt/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
> (gdb) cont
> Continuing.
> We should see this string
> 
> We should see this string
> 
> We should see this string
> 
> 
> As far as I understand, In the latest epk you masked the interrupt to 
> prevent unceasing calling. But the error isn't in your code and changes 
> in your layer are not necessary. Moreover, this changes leads to other 
> issues. As example:
> 
> RedBoot> load -m xmodem 
> 
> CEntry point: 0x81010040, address range: 0x81010000-0x81017008 
> 
> xyzModem - CRC mode, 482(SOH)/0(STX)/0(CAN) packets, 1 retries 
> 
> RedBoot> go 
> 
> enter cyg_user_start() 
> 
> exit cyg_user_start() 
> 
> 
> We should see this string 
> 
> 
> We should see this string
> 
> We should see this string                 <---------- press Ctrl + C
> 
> We should see this string                 <---------- oops
> 
> We should see this string
> 
> 
> Then I use your epk v1.0 with my patch of cyg_hal_plf_serial_isr 
> application works as provided.
> 
> RedBoot> load -m xmodem 
> 
> CEntry point: 0x81010040, address range: 0x81010000-0x81016efc 
> 
> xyzModem - CRC mode, 478(SOH)/0(STX)/0(CAN) packets, 2 retries 
> 
> RedBoot> go 
> 
> enter cyg_user_start() 
> 
> exit cyg_user_start() 
> 
> 
> We should see this string 
> 
> 
> We should see this string
> 
> We should see this string                 <---------- press Ctrl + C
> $T02thread:00000001;0f:40300181;0d:0ca40181;#bb
> 
> :-)
> 
> Best regards
> Alexey Shusharin
> 


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

Re: [ECOS] Re: diag_printf via serial port

[Sergei Gavrikov]

On Mon, Jun 04, 2007 at 11:35:43AM +0300, Sergei Gavrikov wrote:
> Hello Alexey,
> 
> I didn't return to epk v1_0, I just set FIX_GDB_ISR to 0 (that is same
                                      ^^^^^^^^^^^^^^^^^^^^

Ups, there is my errata, it's need either undef FIX_GDB_ISR, or remove
this tweak at all, or downgrade the lcp{h,e,l}2294 packages to v1_0
version.  Certainly, you have to apply that Alexey's patch to test it.
I finish to test the tweaked lpc2xxx variant hal_diag.c for Olimex
LPC-H2294, LPC-E2294 boards. Alexey's innovation works just perfect for
me. The SIR (Spurrious Interrupts Report) did occur never on serial
debug channel

> you see). I aplied your patch and test it. Hardware: LPC-H2294,
> software: GDB5.3, sz+RedBoot. Test: stress_threads (from kernel test
> suite).
> 
> All works very smoothly. Thanks for your "lab" :-) I'm really didn't
> suppose that lpc2xxx variant had a missing (UxIIR).


-- 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