From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8414 invoked by alias); 4 Jun 2007 07:40:55 -0000 Received: (qmail 8404 invoked by uid 22791); 4 Jun 2007 07:40:53 -0000 X-Spam-Check-By: sourceware.org Received: from mx27.mail.ru (HELO mx27.mail.ru) (194.67.23.64) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Jun 2007 07:40:47 +0000 Received: from [87.238.119.226] (port=30003 helo=[10.0.0.21]) by mx27.mail.ru with asmtp id 1Hv7BC-000II8-00; Mon, 04 Jun 2007 11:40:43 +0400 Message-ID: <4663C0F5.1000901@mail.ru> Date: Mon, 04 Jun 2007 07:40:00 -0000 From: Alexey Shusharin User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Sergei Gavrikov , ecos-discuss@ecos.sourceware.org References: <465EA85B.4020600@cetoni.de> <465EB804.9040200@mail.ru> <1180617817.12360.70.camel@sg-ubuntu> <4660108D.4050204@mail.ru> <1180705253.12118.40.camel@sg-ubuntu> <46604ADB.70407@mail.ru> <20070601182424.GA13105@ubuntu> In-Reply-To: <20070601182424.GA13105@ubuntu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Re: diag_printf via serial port X-SW-Source: 2007-06/txt/msg00047.txt.bz2 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