* [ECOS] Re: diag_printf via serial port @ 2007-05-31 12:01 cetoni GmbH - Uwe Kindler 2007-05-31 12:30 ` Alexey Shusharin 0 siblings, 1 reply; 17+ messages in thread From: cetoni GmbH - Uwe Kindler @ 2007-05-31 12:01 UTC (permalink / raw) To: ecos-discuss; +Cc: mrfinch 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [ECOS] Re: diag_printf via serial port 2007-05-31 12:01 [ECOS] Re: diag_printf via serial port cetoni GmbH - Uwe Kindler @ 2007-05-31 12:30 ` Alexey Shusharin 2007-05-31 13:25 ` cetoni GmbH - Uwe Kindler ` (3 more replies) 0 siblings, 4 replies; 17+ messages in thread From: Alexey Shusharin @ 2007-05-31 12:30 UTC (permalink / raw) To: ecos-discuss, cetoni GmbH - Uwe Kindler 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [ECOS] Re: diag_printf via serial port 2007-05-31 12:30 ` Alexey Shusharin @ 2007-05-31 13:25 ` cetoni GmbH - Uwe Kindler 2007-05-31 14:29 ` Sergei Gavrikov ` (2 subsequent siblings) 3 siblings, 0 replies; 17+ messages in thread From: cetoni GmbH - Uwe Kindler @ 2007-05-31 13:25 UTC (permalink / raw) To: Alexey Shusharin; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-05-31 12:30 ` Alexey Shusharin 2007-05-31 13:25 ` cetoni GmbH - Uwe Kindler @ 2007-05-31 14:29 ` Sergei Gavrikov 2007-06-01 12:27 ` Alexey Shusharin 2007-06-01 14:04 ` Sergei Gavrikov 2007-06-01 18:47 ` Sergei Gavrikov 3 siblings, 1 reply; 17+ messages in thread From: Sergei Gavrikov @ 2007-05-31 14:29 UTC (permalink / raw) To: Alexey Shusharin; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-05-31 14:29 ` Sergei Gavrikov @ 2007-06-01 12:27 ` Alexey Shusharin 2007-06-01 13:42 ` Sergei Gavrikov 2007-06-01 16:00 ` Sergei Gavrikov 0 siblings, 2 replies; 17+ messages in thread From: Alexey Shusharin @ 2007-06-01 12:27 UTC (permalink / raw) To: Sergei Gavrikov, ecos-discuss 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-06-01 12:27 ` Alexey Shusharin @ 2007-06-01 13:42 ` Sergei Gavrikov 2007-06-01 16:35 ` Alexey Shusharin 2007-06-01 16:00 ` Sergei Gavrikov 1 sibling, 1 reply; 17+ messages in thread From: Sergei Gavrikov @ 2007-06-01 13:42 UTC (permalink / raw) To: Alexey Shusharin; +Cc: ecos-discuss Ð ÐÑн, 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-06-01 13:42 ` Sergei Gavrikov @ 2007-06-01 16:35 ` Alexey Shusharin 2007-06-01 18:25 ` Sergei Gavrikov ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Alexey Shusharin @ 2007-06-01 16:35 UTC (permalink / raw) To: Sergei Gavrikov, ecos-discuss 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-06-01 16:35 ` Alexey Shusharin @ 2007-06-01 18:25 ` Sergei Gavrikov 2007-06-04 7:40 ` Alexey Shusharin 2007-06-01 18:31 ` Sergei Gavrikov 2007-06-01 18:48 ` Mike Arthur 2 siblings, 1 reply; 17+ messages in thread From: Sergei Gavrikov @ 2007-06-01 18:25 UTC (permalink / raw) To: Alexey Shusharin; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-06-01 18:25 ` Sergei Gavrikov @ 2007-06-04 7:40 ` Alexey Shusharin 2007-06-04 8:35 ` Sergei Gavrikov 0 siblings, 1 reply; 17+ messages in thread From: Alexey Shusharin @ 2007-06-04 7:40 UTC (permalink / raw) To: Sergei Gavrikov, ecos-discuss 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-06-04 7:40 ` Alexey Shusharin @ 2007-06-04 8:35 ` Sergei Gavrikov 2007-06-04 17:44 ` Sergei Gavrikov 0 siblings, 1 reply; 17+ messages in thread From: Sergei Gavrikov @ 2007-06-04 8:35 UTC (permalink / raw) To: Alexey Shusharin; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-06-04 8:35 ` Sergei Gavrikov @ 2007-06-04 17:44 ` Sergei Gavrikov 0 siblings, 0 replies; 17+ messages in thread From: Sergei Gavrikov @ 2007-06-04 17:44 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-06-01 16:35 ` Alexey Shusharin 2007-06-01 18:25 ` Sergei Gavrikov @ 2007-06-01 18:31 ` Sergei Gavrikov 2007-06-01 18:48 ` Mike Arthur 2 siblings, 0 replies; 17+ messages in thread From: Sergei Gavrikov @ 2007-06-01 18:31 UTC (permalink / raw) To: Alexey Shusharin; +Cc: eCos discuss list 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-06-01 16:35 ` Alexey Shusharin 2007-06-01 18:25 ` Sergei Gavrikov 2007-06-01 18:31 ` Sergei Gavrikov @ 2007-06-01 18:48 ` Mike Arthur 2007-06-01 20:15 ` Sergei Gavrikov 2 siblings, 1 reply; 17+ messages in thread From: Mike Arthur @ 2007-06-01 18:48 UTC (permalink / raw) To: Alexey Shusharin; +Cc: Sergei Gavrikov, ecos-discuss > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-06-01 18:48 ` Mike Arthur @ 2007-06-01 20:15 ` Sergei Gavrikov 0 siblings, 0 replies; 17+ messages in thread From: Sergei Gavrikov @ 2007-06-01 20:15 UTC (permalink / raw) To: Mike Arthur; +Cc: eCos discuss list 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-06-01 12:27 ` Alexey Shusharin 2007-06-01 13:42 ` Sergei Gavrikov @ 2007-06-01 16:00 ` Sergei Gavrikov 1 sibling, 0 replies; 17+ messages in thread From: Sergei Gavrikov @ 2007-06-01 16:00 UTC (permalink / raw) To: Alexey Shusharin; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-05-31 12:30 ` Alexey Shusharin 2007-05-31 13:25 ` cetoni GmbH - Uwe Kindler 2007-05-31 14:29 ` Sergei Gavrikov @ 2007-06-01 14:04 ` Sergei Gavrikov 2007-06-01 18:47 ` Sergei Gavrikov 3 siblings, 0 replies; 17+ messages in thread From: Sergei Gavrikov @ 2007-06-01 14:04 UTC (permalink / raw) To: Alexey Shusharin; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [ECOS] Re: diag_printf via serial port 2007-05-31 12:30 ` Alexey Shusharin ` (2 preceding siblings ...) 2007-06-01 14:04 ` Sergei Gavrikov @ 2007-06-01 18:47 ` Sergei Gavrikov 3 siblings, 0 replies; 17+ messages in thread From: Sergei Gavrikov @ 2007-06-01 18:47 UTC (permalink / raw) To: Alexey Shusharin; +Cc: eCos discuss list 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2007-06-04 17:44 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-05-31 12:01 [ECOS] Re: diag_printf via serial port cetoni GmbH - Uwe Kindler 2007-05-31 12:30 ` Alexey Shusharin 2007-05-31 13:25 ` cetoni GmbH - Uwe Kindler 2007-05-31 14:29 ` Sergei Gavrikov 2007-06-01 12:27 ` Alexey Shusharin 2007-06-01 13:42 ` Sergei Gavrikov 2007-06-01 16:35 ` Alexey Shusharin 2007-06-01 18:25 ` Sergei Gavrikov 2007-06-04 7:40 ` Alexey Shusharin 2007-06-04 8:35 ` Sergei Gavrikov 2007-06-04 17:44 ` Sergei Gavrikov 2007-06-01 18:31 ` Sergei Gavrikov 2007-06-01 18:48 ` Mike Arthur 2007-06-01 20:15 ` Sergei Gavrikov 2007-06-01 16:00 ` Sergei Gavrikov 2007-06-01 14:04 ` Sergei Gavrikov 2007-06-01 18:47 ` Sergei Gavrikov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).