Hi all,
I found an interesting behaviour.
Sending to UART over SP (with deprecated GenericComm) with
call SendMsg.send(TOS_UART_ADDR, sizeof(WorosDataMsg), &datamessage)
did not always run successfully, so I investigated on that and found out
that in SPDataM.nc there is a uninitialized pointer.
module SPDataM {
...
}
implementation {
sp_message_t* m_uartmsg;
...
Everything runs in simple cases ok even with the uninitialized pointer,
because it points in simple applications to 0x00000. This address is
needed by following check in SPDataM:
command result_t SPSend.sendAdv[uint8_t id](...
if ((msg->addr == TOS_UART_ADDR) || (msg->dev == SP_I_UART)) {
if (m_uartmsg == NULL) {
if (call UARTSend.send(msg->msg) == SUCCESS) {
m_uartmsg = msg;
return SUCCESS;
}
}
return FAIL;
}
// try to insert the message in the message pool
return call Pool.insert(msg);
}
the returning event UARTSend.sendDone sets the pointer back to NULL
event result_t UARTSend.sendDone(TOS_MsgPtr msg, result_t success) {
sp_message_t* _stack = m_uartmsg;
if (m_uartmsg != NULL && msg == m_uartmsg->msg) {
...
m_uartmsg = NULL;
signal SPSend.sendDone[_stack->id](_stack, _stack->flags,
(success != SUCCESS));
}
return SUCCESS;
}
In some cases, the pointer is not initialized at the beginning
(boot) to 0x0000 and SP does block and send nothing over UART.
conditions for this:
there needs to be a big enough array (in testapp: uint16_t
testSig[2000]) in the RAM and the variables need to be named in a
certain order (because of arrangement in the RAM)*.
so the following Patch solves this Problem SPDataM.nc
implementation {
sp_message_t* m_uartmsg = NULL;
...
To demonstrate the behaviour I have 3 different test apps:
WorosDebugOk (TestSig, SPDataM patched, is running correctly)
WorosDebugBAD (Same as WorosDebugOk without patched SPDataM, blocking)
WorosDebugBADnoTestSig (unpatched SPDataM, no TestSig in RAM, running
correctly)
To reproduce yourself the behavior contact me to get code and binaries.
My environment:
Boomerang 2.0.4 with the Patches from your website
GCC:
Configured with: /opt/birodist/build-mspgcc/build/gcc-3.2.3/configure
--target=msp430 --prefix=/opt/msp430
Thread model: single
gcc version 3.2.3
NCC: nescc: 1.2.8a
(Debian/Linux)
*For example if I rename my variable result[] to myresult[], the
application runs ok, because it is ordered differently.
Regards
Reinhard Bischoff
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
