[Contiki-developers] Serial interface trouble on TelosB

[Klaus Stengel]

Hi,

I have some trouble getting the serial interface on the TelosB (sky
platform) to work properly. My goal is to upload files to other nodes
via radio from my Desktop. Since I need to communicate over runicast
instead of trickle and need to save memory for other applications, I
decided develop my own solution instead of enhancing the sky-shell
example. The sending node takes lines of base64 coded data from the
serial interface, decodes them and stores them in a buffer. If a packet
is complete, the buffer is given to runicast to send the data. To avoid
any buffer overflows, the node answers with a single dot character on a
line (".\n") when there's enough space again to receive the next line.

With the cooja simulator everything works perfectly, even with large
files (40k). However, running the same firmware on real hardware I get
error messages from my base64 decoder. It seems like some characters are
lost and/or garbled on the way from the PC to the MSP430. In the
opposite direction I sometimes get a garbage character before/after the
dot in the response from the node. I played around a little bit with the
usleep() in the serialdump utility and increasing the delay seems to
help a bit, but I never managed to transfer more than a few kilobytes in
a row without problems.

I also tried to change the baud rate in sky-main from the default 115200
to some lower setting with the result that there was no communication
possible at all. Instead of the startup messages I only received garbage
from the Mote and this happened with every possible setting except
115200 (tried 9600,19200,38400 and 57600). And before you ask, yes, I
did configure the serialdump utility to the the same baud rate as the
node was supposed to have ;) The "miniterm" shipped with mspcc produced
the same results btw. I already had a look at the uart1.c and checked it
against the MSP430 specs from TI, but I can't spot any obvious
mistakes.

Any ideas?

I'm running Debian Etch with Kernel 2.6.26 (vanilla) on the PC, in case
that's relevant.

Regards,
Klaus.

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Contiki-developers mailing list
Contiki-d...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/contiki-developers

[Adam Dunkels]

I have seen similar things happen with serialdump -b115200. It seems
that a byte is sometimes lost when transferring large amounts of data.
But I think I was able to change the bitrate by changing the call to
uart1_init() in contiki-sky-main.c.

Can you pace the dots at the Tmote Sky side and see if it makes a
difference? I.e., wait some time before printing out the dot.

/adam

--
Adam Dunkels <ad...@sics.se>, +46707731614
http://www.sics.se/~adam/

[Klaus Stengel]

Hi,

Adam Dunkels wrote:

> Klaus Stengel wrote:
> > I also tried to change the baud rate in sky-main from the default
> > 115200 to some lower setting with the result that there was no
> > communication possible at all.
>

> I have seen similar things happen with serialdump -b115200. It seems
> that a byte is sometimes lost when transferring large amounts of data.
> But I think I was able to change the bitrate by changing the call to
> uart1_init() in contiki-sky-main.c.

Thanks for your quick reply. I did some more tests and managed to
receive the startup message at lower speeds. My mistake was that I
waited too long between resetting the mote and reading from the serial
port, so the port still had the settings from the programmer tool when
the messages arrived. When I run both tools immediately in a row, I can
see the expected output, but unfortunately I'm still unable to send any
commands to the mote.

I made a small test program that redirects any characters received
immediately back to the output. With any speed except 115200 the TelosB
just seems to receive garbage, for example with 19200:

$ ./msp430-bsl-linux --telosb -r -c /dev/ttyUSB0; ./serialdump-linux \
-x -b19200 /dev/ttyUSB0
MSP430 Bootstrap Loader Version: 1.39-telos-7
Use -h for help
Reset device ...
connecting to /dev/ttyUSB0 (19200) [OK]
436F6E74 696B6920 322E322E 32207374 61727465 Contiki 2.2.2 starte
642E204E 6F646520 69642069 73206E6F 74207365 d. Node id is not se
742E0A52 696D6520 73746172 74656420 77697468 t..Rime started with
20616464 72657373 2038302E 3133350A 4D414320 address 80.135.MAC
30303A31 323A3735 3A30303A 31323A65 363A3837 00:12:75:00:12:e6:87
3A35300A 53746172 74696E67 20274865 6C6C6F20 :50.Starting 'Hello
776F726C 64207072 6F636573 73270A48 656C6C6F world process'.Hello
2C20776F 726C640A , world.a
2C20776F 726C640A FD , world..b
2C20776F 726C640A FDFA , world...c
2C20776F 726C640A FDFAFF , world....d
2C20776F 726C640A FDFAFFFC , world.....e
2C20776F 726C640A FDFAFFFC FD , world......f
2C20776F 726C640A FDFAFFFC FDFE , world.......foo
2C20776F 726C640A FDFAFFFC FDFEFE , world........longdata
2C20776F 726C640A FDFAFFFC FDFEFEFC , world.........

As you can see, I send the lines "a", "b", "c", ... "longdata" and the
mote just received "FD FA FF FC FD FE FE FC" in hex. When running with
115200 baud it works just as expected:

$ ./msp430-bsl-linux --telosb -r -c /dev/ttyUSB0; ./serialdump-linux \
-x -b115200 /dev/ttyUSB0
MSP430 Bootstrap Loader Version: 1.39-telos-7
Use -h for help
Reset device ...
connecting to /dev/ttyUSB0 (115200) [OK]
436F6E74 696B6920 322E322E 32207374 61727465 Contiki 2.2.2 starte
642E204E 6F646520 69642069 73206E6F 74207365 d. Node id is not se
742E0A52 696D6520 73746172 74656420 77697468 t..Rime started with
20616464 72657373 2038302E 3133350A 4D414320 address 80.135.MAC
30303A31 323A3735 3A30303A 31323A65 363A3837 00:12:75:00:12:e6:87
3A35300A 53746172 74696E67 20274865 6C6C6F20 :50.Starting 'Hello
776F726C 64207072 6F636573 73270A48 656C6C6F world process'.Hello
2C20776F 726C640A , world.a
2C20776F 726C640A 610A , world.a.b
2C20776F 726C640A 610A620A , world.a.b.c
2C20776F 726C640A 610A620A 630A , world.a.b.c.f
2C20776F 726C640A 610A620A 630A660A , world.a.b.c.f.foo
2C20776F 726C640A 610A620A 630A660A 666F6F0A , world.a.b.c.f.foo.

However, this doesn't solve my problem with the lost characters, but
maybe those two are related somehow.

> > To avoid any buffer overflows, the node answers with a single dot
> > character on a line (".\n") when there's enough space again to
> > receive the next line.
>

> Can you pace the dots at the Tmote Sky side and see if it makes a
> difference? I.e., wait some time before printing out the dot.

Well, it helps if I wait some time _after_ printing out the dot. As it
turns out, the garbage characters seem to be caused by entering low
power mode too early. My program is sending the dot line and then the
protothread immediately blocks because it's waiting for new data. If
there aren't any other events pending, the CPU reduces its clock speed
while sill transmitting the last character. When I add the line
while((UTCTL1 & TXEPT) == 0);
after TXBUF1 = c; in uart1.c the garbage is gone, but I guess the more
correct solution was to perform this check only before entering low
power mode instead of doing it after each and every character.

[Adam Dunkels]

This is great bughunting! Just to confirm: is the problem due to the LPM
mode? Does everything work, including transfer 40k+ binaries, with your
workaround in uart1.c?

/adam

--
Adam Dunkels <ad...@sics.se>, +46707731614
http://www.sics.se/~adam/

------------------------------------------------------------------------------

[Klaus Stengel]

Hi,

Adam Dunkels wrote:
> This is great bughunting! Just to confirm: is the problem due to the LPM
> mode?

As far as I can tell, yes. The UART clock is derived from the processor
clock and if it enters some low power mode while still transmitting a
character you'll just see garbage on the PC.

> Does everything work, including transfer 40k+ binaries, with your
> workaround in uart1.c?

The workaround only fixed the bad data I received from the TelosB.

Sending large files doesn't work yet, because I'm still getting lost/bad
in the other direction, i.e. from the PC to the TelosB.

With lower baud rates, my program on the Mote only receives garbage from
the PC, while the communication from Mote to PC seems to work properly:
I can see the startup messages but I'm unable to send any command or
data.

Hope the situation is clear now.

[Adam Dunkels]

Klaus Stengel wrote:
>> This is great bughunting! Just to confirm: is the problem due to the LPM
>> mode?
>
> As far as I can tell, yes. The UART clock is derived from the processor
> clock and if it enters some low power mode while still transmitting a
> character you'll just see garbage on the PC.

Ok, good.

>> Does everything work, including transfer 40k+ binaries, with your
>> workaround in uart1.c?
>
> The workaround only fixed the bad data I received from the TelosB.
>
> Sending large files doesn't work yet, because I'm still getting lost/bad
> in the other direction, i.e. from the PC to the TelosB.

Do you know how many bytes in a row that is needed to provoke this
problem? The default serial buffer size is 80 characters. Is this
correlated to the lost bytes, you think? (I.e., is the problem with
interrupt processing taking too long, or with lower level things such as
LPM.)

Thanks,

/adam

> With lower baud rates, my program on the Mote only receives garbage from
> the PC, while the communication from Mote to PC seems to work properly:
> I can see the startup messages but I'm unable to send any command or
> data.
>
> Hope the situation is clear now.
>
> Regards,
> Klaus.
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Contiki-developers mailing list
> Contiki-d...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/contiki-developers
>

--
Adam Dunkels <ad...@sics.se>, +46707731614
http://www.sics.se/~adam/

------------------------------------------------------------------------------

[Klaus Stengel]

Hi,

Adam Dunkels wrote:
> Klaus Stengel wrote:

> > Sending large files doesn't work yet, because I'm still getting lost/bad
> > in the other direction, i.e. from the PC to the TelosB.
>
> Do you know how many bytes in a row that is needed to provoke this
> problem? The default serial buffer size is 80 characters. Is this
> correlated to the lost bytes, you think? (I.e., is the problem with
> interrupt processing taking too long, or with lower level things such as
> LPM.)

I use lines with 60 characters. After each character I pause for 10
milliseconds (usleep(10000)) on the PC. In this configuration I need to
send about 16 kb data to the Mote before the problem occurs.

Now that I removed the LPM handling from the main loop so that the CPU
always stays in full power mode, I managed to send the complete 49k file
over the serial line successfully. Even the lower baud rates work
properly now.

So there's definitively some serious problem with the LPM part.

[Klaus Stengel]

Hi,

Klaus Stengel wrote:
> Adam Dunkels wrote:
> > Klaus Stengel wrote:
> > > Sending large files doesn't work yet, because I'm still getting lost/bad
> > > in the other direction, i.e. from the PC to the TelosB.
> >
> > Do you know how many bytes in a row that is needed to provoke this
> > problem? The default serial buffer size is 80 characters. Is this
> > correlated to the lost bytes, you think? (I.e., is the problem with
> > interrupt processing taking too long, or with lower level things such as
> > LPM.)
>
> I use lines with 60 characters. After each character I pause for 10
> milliseconds (usleep(10000)) on the PC. In this configuration I need to
> send about 16 kb data to the Mote before the problem occurs.
>
> Now that I removed the LPM handling from the main loop so that the CPU
> always stays in full power mode, I managed to send the complete 49k file
> over the serial line successfully. Even the lower baud rates work
> properly now.
>
> So there's definitively some serious problem with the LPM part.

Found the problem. The wakup code in the uart1 interrupt handler is OK,
but there's nothing that prevents the CPU from entering sleep mode again
before the character is completely received. Whenever the PC starts
transmission just before the mote wants to fall asleep, the interrupt
handler won't keep the UART clock alive long enough. The problem becomes
even worse with lower transmission speeds and below 115200 baud it often
takes longer to receive a single byte than doing one iteration of the
process list. That's why the lower settings stopped working entirely.

The attached patch should fix the problem by checking the current status
of the UART before entering LPM. It keeps the CPU running in case there
are any transmissions in progress.

Regards,
Klaus.

[Joakim Eriksson]

Thanks Klaus,

Really good work finding and fixing the bug - I think this will go
into several of the MSP430 based Contiki platforms! I will also try to
add some functionality into MSPSim so that it prints a warning if the
processor goes into LPM3 or above when the USART is still sending.

Best regards,
-- Joakim Eriksson, SICS

Klaus Stengel skrev:

> ------------------------------------------------------------------------

>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
>
>

> ------------------------------------------------------------------------

[Klaus Stengel]

Hi,

Joakim Eriksson wrote:
> Thanks Klaus,
>
> Really good work finding and fixing the bug

You're welcome.

However, I noticed a little typo in my patch. I've added the line

IFG2 &= URXIFG1;

to uart1_init() in order to clear any pending RX interrupts, but in fact
this clears all the other flags instead. The correct line is

IFG2 &= ~URXIFG1;

On real hardware it doesn't seem to have any negative impact, but with
mspsim programs run into an endless loop because of that mistake. I'm
sorry for any inconvenience this may have caused.

Regards,
Klaus.

[Joakim Eriksson]

Thanks for pointing that out!

I have fixed the Tmote Sky platform in Contiki and also added
a warning in MSPSim that is printed when transmission is active
while MCU is in LPM3 or above.

Best regards,
-- Joakim Eriksson, SICS

Klaus Stengel skrev: