headers
Brett Delmage | 1 May 2006 19:52
Picon

cyg_thread_delay on ARM7 crashes randomly

I have a simple test program, a simplification of the TwoThreads program. 
All it does is initialize and resume one thread. The single thread calls 
cyg_thread_delay(1) in a loop.

The target is a minor variation of the Philips LPC 2106, running on a 
Philips LPC2114 ARM7. Compiler is GCC 3.4.2

The program crashes after a random period of time, ranging from almost 
immediately to maybe tens of seconds. But when I enable tracing, dumping 
trace messages to serial port 0 at 9600 baud, the program has run for over 
half an hour without crashing.

There is no other I/O or source of interrupts occuring other than the real 
time clock, that I am aware of.

When the program crashes, my JTAG debugger shows the 
PC at ffff ffd7, and all other registers = ffff ffff

Putting breakpoints on all the vectors except IRQ doesn't trigger when the 
crash occurs. A breakpoint at the IRQ does trigger, indicating the clock 
interrurpt is occurring, and also triggering the debugger breakpoint.

This looks like an interrupt occurring when it shouldn't but who knows.

I'm have no idea why my debugger (Ashling PFARM and Opella) stops when the 
program crashes.

All ideas, including debugging suggestions very much welcomed.

Finally, A big thanks to Daniel Néri whose advise helped me get the LPC
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrew Lunn | 1 May 2006 19:54
Picon

Re: cyg_thread_delay on ARM7 crashes randomly

On Mon, May 01, 2006 at 01:52:26PM -0400, Brett Delmage wrote:
> I have a simple test program, a simplification of the TwoThreads program. 
> All it does is initialize and resume one thread. The single thread calls 
> cyg_thread_delay(1) in a loop.
> 
> The target is a minor variation of the Philips LPC 2106, running on a 
> Philips LPC2114 ARM7. Compiler is GCC 3.4.2
> 
> The program crashes after a random period of time, ranging from almost 
> immediately to maybe tens of seconds. But when I enable tracing, dumping 
> trace messages to serial port 0 at 9600 baud, the program has run for over 
> half an hour without crashing.
> 
> There is no other I/O or source of interrupts occuring other than the real 
> time clock, that I am aware of.
> 
> When the program crashes, my JTAG debugger shows the 
> PC at ffff ffd7, and all other registers = ffff ffff
> 
> Putting breakpoints on all the vectors except IRQ doesn't trigger when the 
> crash occurs. A breakpoint at the IRQ does trigger, indicating the clock 
> interrurpt is occurring, and also triggering the debugger breakpoint.
> 
> This looks like an interrupt occurring when it shouldn't but who knows.
> 
> I'm have no idea why my debugger (Ashling PFARM and Opella) stops when the 
> program crashes.
> 
> All ideas, including debugging suggestions very much welcomed.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brett Delmage | 1 May 2006 20:52
Picon

Re: cyg_thread_delay on ARM7 crashes randomly

On Mon, 1 May 2006, Andrew Lunn wrote:

> Do you have CYGPKG_INFRA_DEBUG enabled? Enabling it might give some
> interesting results.

Yes, with all assert options enabled. Nothing is reported. I only see 
output when I also have CYGDBG_USE_TRACING enabled, but then that seems to 
mask the problem. Heisenbug.

--

-- 
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 | Reply | 1 comment |
headers
Lars Poeschel | 2 May 2006 01:06
Picon

Re: Can you please verify#1fsAkl1apS8g50EZYBVUzpstVFiPpbGv

Am Montag, 1. Mai 2006 07:20 schrieb mark <at> mcselec.com:
> The message you sent requires that you verify that you
> are a real live human being and not a spam source.
>
> I understand that it is not convenient but the large amount of spam we
> receive forced us to use this protection. Simple reply to this email and
> you are verfied.
>
> Leave the subject line intact.
>
> The headers of the message sent from your address are show below:
>
> From ecos-discuss <at> sources.redhat.com Mon May 01 01:20:55 2006
> Received: from albertsm by vps.mcselec.com with local-bsmtp (Exim 4.52)
>  id 1FaQq6-0005um-Oq
>  for mark <at> mcselec.com; Mon, 01 May 2006 01:20:55 -0400
> Received: from localhost by vps.mcselec.com
> 	with SpamAssassin (version 3.1.0);
> 	Mon, 01 May 2006 01:20:55 -0400
> From: ecos-discuss <at> sources.redhat.com
> To: mark <at> mcselec.com
> Subject: Good day
> Date: Mon, 1 May 2006 10:54:50 +0530
> X-Spam-Flag: YES
> X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on vps.mcselec.com
> X-Spam-Level: **********
> X-Spam-Status: Yes, score=10.6 required=5.0 tests=BAYES_50,MISSING_MIMEOLE,
> 	NO_REAL_NAME,PRIORITY_NO_NAME,RCVD_IN_SORBS_WEB,RCVD_IN_XBL
> 	autolearn=no version=3.1.0
> MIME-Version: 1.0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Garnett | 2 May 2006 10:55
Favicon

Re: cyg_thread_delay on ARM7 crashes randomly

Brett Delmage <Brett.Delmage <at> twobikes.ottawa.on.ca> writes:

> On Mon, 1 May 2006, Andrew Lunn wrote:
> 
> > Do you have CYGPKG_INFRA_DEBUG enabled? Enabling it might give some
> > interesting results.
> 
> Yes, with all assert options enabled. Nothing is reported. I only see 
> output when I also have CYGDBG_USE_TRACING enabled, but then that seems to 
> mask the problem. Heisenbug.

Since this problem is timing based, using tracing is not going to
help. You could try turning on instrumentation and when the crash
occurs take a look at the instrumentation buffer from JTAG and see
what was happening just before.

Given that eCos doesn't exhibit this problem on other platforms, the
most likely cause of this is a bug in the LPC2xxx HAL. So you should
probably concentrate your efforts there. 

-- 
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts

--

-- 
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 | Reply | 0 comments |
headers
Ram Sudhir Tadavarthi | 3 May 2006 16:26
Picon

printf or diag_printf prints $O48656c6c6f2c20776f726c64210a#75

Hello all,

AIM:
To print "hello world\n" on console with eCos kernel in the project. 

WHAT I DID:
I am a beginner to embedded world. I tried to bring up eCos on Motorola
pq2fads(MPC 8260 powerpc) evaluation board. I used vads HAL as starting
point and mostly finished the porting and was able to bring up the redboot
ROM monitor. Serial and network interfaces are functional from redboot.

PROBLEM DESCRIPTION:
Redboot console messages are displayed properly. I have created an eCos
image with hello world example(hello.c) and downloaded it over TFTP through
redboot "load" command and had given the "go" command.

I have seen the following message as output instead of "Hello, world!\n"

$O48656c6c6f2c20776f726c64210a#75

After searching in google, I understood this message is some gdb response to
hello world message. But I did not use the debugger to download the image
nor to run it. I did not understand why gdb came into picture when we try to
execute the image from redboot. 

This is the first time I have ever created an eCos Image. I hope it is not a
configuration error in my project.

I am surprised why redboot which uses the same HAL works but the eCos Image
doesn't.
(Continue reading)

Permalink | Reply | 0 comments |
headers
llandre | 3 May 2006 16:40
Picon

Re: ecos-discuss Digest 3 May 2006 14:26:26 -0000 Issue 2208

Probably you have to disable the GDB mangler (see "Mangler used on diag 
output" in HAL options).

HTH,
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2 <at> dave-tech.it

> Subject:
> printf or diag_printf prints $O48656c6c6f2c20776f726c64210a#75
> From:
> "Ram Sudhir Tadavarthi" <ram.tadavarthi <at> netco.de>
> Date:
> Wed, 3 May 2006 16:26:04 +0200
> To:
> <ecos-discuss <at> ecos.sourceware.org>
> 
> To:
> <ecos-discuss <at> ecos.sourceware.org>
> 
> 
> Hello all,
> 
> AIM:
> To print "hello world\n" on console with eCos kernel in the project. 
> 
> WHAT I DID:
> I am a beginner to embedded world. I tried to bring up eCos on Motorola
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ram Sudhir Tadavarthi | 4 May 2006 09:39
Picon

Re: printf or diag_printf prints $O48656c6c6f2c20776f726c64210a#75


-----Ursprüngliche Nachricht-----
Von: Ram Sudhir Tadavarthi [mailto:ram.tadavarthi <at> netco.de] 
Gesendet: Donnerstag, 4. Mai 2006 09:13
An: 'Andrew Dyer'
Betreff: AW: [ECOS] printf or diag_printf prints
$O48656c6c6f2c20776f726c64210a#75

Dear Mr.Andrew & Mr.llandre,

That was it. I disabled the gdb mangler in the HAL and I can see the correct
output on the console. So I conclude that enabling gdb mangler redirects the
serial output to gdb remote protocol. Time for me to read and understand gdb
manuals to understand the things correctly.

Thanks a lot for your valuable info. 

Thanks & Regards,
Ram

-----Ursprüngliche Nachricht-----
Von: Andrew Dyer [mailto:amdyer <at> gmail.com] 
Gesendet: Mittwoch, 3. Mai 2006 19:43
An: Ram Sudhir Tadavarthi
Betreff: Re: [ECOS] printf or diag_printf prints
$O48656c6c6f2c20776f726c64210a#75

gdb has a facility to allow passing character streams across the gdb remote
protocol link.  That's what this message is (ignore the $O at the front and
the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Praveen Prabhakar , Bangalore | 4 May 2006 12:07
Picon
Favicon

Write to Data bus in MPC565

Hello All ,
        i wanted to write data into Data bus of MPC565.

        For this i have set  'SC' bit in SIUMCR Register which will set the databus as  data or Gpio
        i have set this as data .

       Next how to write into the data bus ?

Thanks
Praveen

--

-- 
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 | Reply | 0 comments |
headers
robert sebestyen | 4 May 2006 13:28
Picon
Favicon

invalid conversion from void* to void**

First, I would like to apologize myself  for disturbing you with my problem.

I implemented a lwIP into an existing project running on OS ecos, when i 
call the data i receive always invalid conversion from void* to void**! I 
call the lwIP with the following code:

static void

httpget(void *arg)

{

            int k=1;

            int res;

            struct netconn *conn;

            static char httpreq[255];

            struct ip_addr addr;

            char *data;

                cyg_uint16 len, i;

            while(1)

            {
(Continue reading)

Permalink | Reply | 11 comments |

Gmane