[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Problem of debug on a design with MCM



Title: Message
Also turn off the watchdog if you print a lot form kernel space to avoid surprises.
 
/Mikael
-----Original Message-----
From: owner-dev-etrax@xxxxxxx.com] On Behalf Of girerd
Sent: Tuesday, September 09, 2003 4:36 PM
To: Mikael Starvik
Cc: dev-etrax
Subject: Re: Problem of debug on a design with MCM

Hi Mikael,
Your are right, now it works  perfectly well !!
Thank you ..

Claude

Mikael Starvik a crit:
The file is attached.

-----Original Message-----
From: owner-dev-etrax@xxxxxxx.com [mailto:owner-dev-etrax@xxxxxxx.com] On Behalf
Of girerd
Sent: Monday, September 08, 2003 10:07 AM
To: dev-etrax
Subject: Problem of debug on a design with MCM


Hi,

We have an application which runs correctly on an MCM during about one 
hour and then craschs ... The MCM is no longer
accessible through Ethernet. I send you in attachement an extract of  
messages printed by sermon on the debug port.

The beginning corresponds to a normal execution.

Call interrupt handler fifoNotEmpty = 0    //  in interrupt handler
Clear interrupt                                         //in  interrupt 
handler
Data received fifoNotEmpty = 1                            //  in read 
function wake up
Reading the interrupt status register : 800c             //  in read
Number of words in the FIFO CYCLE : 12          //  in read

After we see an unexpected message and a <4> printed before each line.
 I'am interested to understand the meaning of this number.

Call interrupt handler fifoNotEmpty = 0 
handler fifoNotEmpty = 0      <=  ??? I don't anderstand this message it 
seems to be, the same as the previous one,  but truncated
<4>Clear interrupt
<4>Data received fifoNotEmpty = 1
<4>Reading the interrupt status register : 800c
<4>Number of words in the FIFO CYCLE : 12

Finaly, the messages on the debug port become  unreadable and the MCM 
crashs, it  is no longer
accessible through Ethernet we need a hardware reset to restart the system.

<4>Call interrupt handler fifoNotEmpty = 0 
 
  
DbbeMMMMMMMMMMMMMMMMMMMMMM
    
MMcNcN

I will try to build a more simple application without interrupt ... but 
I'am interested by any idea and advice to debug in this situation

best regards

Claude