This sounds like a _very_ "low probability" race condition,
something that shouldn't overlap but does only after
millions of cycles...
You could be right about missing a TX interupt. Look in
the ATMEGA spec book for what happens to internal ints,
I would think that they carry over and fire when ints
are re-enabled but there could be some other condition
that clears it to soon.
Welcome to the world of concurrent programming, where
the impossible is only improbable, and the improbable
is guaranteed to happen eventually.
Sorry I can't be much more help. But if you were able
to find the "state" variable problem without going
entirely loony I have every faith that you'll bag
the race condition too...
MS
jose m wrote:
Hello,
Recently, I've made lots and lots of questions about
transmitting data by UART port, because I have this
bug and cannot solve it (a little more, and I'll be a
lunatic). My problem is this: if my system runs
several days, one of these days (any one, any time),
no more UART transmission is done. The funny thing:
the system is still working normally, send and receive
radio packets, update internal data, etc, etc.
Debugging and testing during hours allows me to
conclude this: for some reason (hiding to me), in
component UARTM, the variable "state" remains TRUE,
and calls to UARTM's txByte(<data>) FAILs.
What can be the misterious reason of this problem? I
suspect that the tx interrupt never executes, but this
has low probability. If the ATMega128's interrupts are
disabled and enabled again, what happens with the
interrups signalled when they were disabled?
José
-------------------------------------------------------
async event result_t HPLUART.putDone() {
bool oldState;
atomic {
dbg(DBG_UART, "intr: state %d\n", state);
oldState = state;
state = FALSE;
}
/* Note that the state transition/event signalling
is not atomic.
It is possible, after state has been set to
FALSE, that
someone calls txByte before txDone is
signalled. The event
handler therefore may not be able to transmit.
Sharing
the byte level can be very tricky, unless we
assure non-preemptiveness
or have client ids. The UART implementation is
non-preemptive,
but is not assuredly so. -pal*/
if (oldState) {
signal ByteComm.txDone();
signal ByteComm.txByteReady(TRUE);
}
return SUCCESS;
}
-------------------------------------------------------
___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
