From: Jamie Guinan <guinan@bluebutton.com>
To: Ecos Discussion List <ecos-discuss@sourceware.cygnus.com>
Subject: [ECOS] SMC2 - no interrupts?
Date: Tue, 09 Nov 1999 19:36:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.10.9911092234090.10663-400000@gemini.home.net> (raw)
Hi all,
[ Note - I'll also send a formal bug report related to this under
my client's support contract, so some Cygnus folks may see this twice. ]
I'm using eCos on an MBX 821 board, and I'm trying to coerce SMC2
into a functioning state. A few weeks ago I got as far as figuring out
I needed a transceiver (duh), and I verified that the port was operational
by sending EPPCBug's console out SMC2.
I've been studying quicc_smc_serial.c, and I'm a bit stumped as to
why nothing is coming out the SMC2 port in my test application.
My simple test app is attached, but in a nutshell, the code goes,
const char *device = "/dev/ser2";
char *msg;
cyg_io_handle_t handle;
int len;
cyg_io_lookup(device, &handle);
msg = "Hello from SMC2\n";
len = strlen(msg);
cyg_io_write(handle, msg, &len);
and nothing comes out the port. Debugging the driver, I found that
after it fills the transmit buffer, it calls quicc_smc_serial_flush(),
which sets the R and I bits (Ready/Interrupt) in the tx buffer descriptor,
so that an interrupt will be generated once the data is sent. It *should*
work, but since nothing was happening I decided to add some counter
variables (see attached patch file) and guess what- neither
quicc_smc_serial_ISR() nor quicc_smc_serial_DSR() seem to get called. :/
I'm working out of CVS at the moment (updated late night, Nov 8th).
My configuration goes,
tclsh .../packages/pkgconf.tcl --target powerpc --platform mbx --startup ram --disable-uitron
Then I manually tweak some pkgconf settings,
hal.h:
#define CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK
#define CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE 4096
#undef CYGSEM_HAL_COMMON_INTERRUPTS_ALLOW_NESTING
#undef CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT
#undef CYGIMP_HAL_COMMON_INTERRUPTS_CHAIN
#undef CYGIMP_HAL_COMMON_INTERRUPTS_IGNORE_SPURIOUS
#undef CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM
#define CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
#define CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT
#undef CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT
#define CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT
io_serial.h:
#define CYGPKG_IO_SERIAL_POWERPC_QUICC_SMC
#define CYGPKG_IO_SERIAL_POWERPC_QUICC_SMC_SMC1
(defaults, 38400, etc.)
#define CYGPKG_IO_SERIAL_POWERPC_QUICC_SMC_SMC2
(defaults, 38400, etc.)
hal_powerpc_mbx.h:
#define CYGHWR_HAL_POWERPC_BOARD_SPEED 40
infra.h:
#define CYGPKG_INFRA_DEBUG
#define CYGDBG_INFRA_DIAG_USE_DEVICE
Is there anything else I need to do to get the interrupts into
operation? Maybe its a cache issue?
For what its worth, here is a dump of the smc_chan structure passed
to quicc_smc_serial_flush(). It looks Ok to me (pram, txbd, etc. seem
reasonable at least),
(gdb) p *smc_chan
$1 = {channel = 176, int_num = 55, brg = 0xff0009f4, pram = 0xff003f80,
ctl = 0xff000a90,
txbd = 0xff002840, rxbd = 0xff002860, tbase = 0xff002840, rbase =
0xff002860, txsize = 16,
rxsize = 16, serial_interrupt = {vector = 55, priority = 0, isr =
0x130dc <quicc_smc_serial_ISR>,
dsr = 0x12ce0 <quicc_smc_serial_DSR>, data = 322024, dsr_count = 0,
next_dsr = 0x0},
serial_interrupt_handle = 322208, tx_enabled = 0}
Thanks in advance...
-Jamie
================================================================
Jamie Guinan Blue Button Solutions, Inc.
guinan@bluebutton.com http://www.bluebutton.com
================================================================
next reply other threads:[~1999-11-09 19:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-11-09 19:36 Jamie Guinan [this message]
1999-11-10 0:57 ` Jesper Skov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.10.9911092234090.10663-400000@gemini.home.net \
--to=guinan@bluebutton.com \
--cc=ecos-discuss@sourceware.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).