RF230 sends wrong data in large packets when slow SPI or unoptimized (debugged) code

[tinyos-issues]

Original author: M.Cerv...@computer.org (March 11, 2012 13:11:31)

What steps will reproduce the problem?

• try to send packet with length 15 bytes and more of payload without RF230_SLOW_SPI defined or slightly more bytes with RF230_SLOW_SPI defined

What is the expected output? What do you see instead?

• after 14-16 byte of payload appears data from previous packet

Please provide any additional information below.

• logic analyzer on SPI shows that copy loop in RF230Driver*C.RadioSend.send() does not successfully copy all data in time to RF230 hardware (old data are send at the end of packet) - one iteration takes about 36us (atmega1281, 8MHz, compiled without optimization eg. "-O0") but one data byte is sent to wireless in about 32us.
• one iteration at the same platform compiled with optimization "-Os" takes only 3us

====>

I recommend to send packet after all data are copied on slow or debugged platforms (see attached patch).

M.C>

Original issue: http://code.google.com/p/tinyos-main/issues/detail?id=125

[tinyos-issues]

From M.Cerv...@computer.org on March 12, 2012 18:29:07 updated patch.

[tinyos-issues]

From mmar...@gmail.com on March 13, 2012 22:04:13 On what hardware did you test it? It seems to work fine on IRIS.

I can see that RF230_SLOW_SPI should actually call the send path after it has actually uploaded the full payload, but you has to know the consequences: time synchronization will not work, since it is impossible to modify the payload and embed the timestamp in the message.

An alternative solution for RF230_SLOW_SPI would be to leave only the last four bytes in memory before triggering the upload, that should be more than enough.

Miklos

[tinyos-issues]

From M.Cerv...@computer.org on March 13, 2012 23:26:38 Yes, you have right, I overlooked meaning of timesync pointer. I tried to review patch. See new version. My platform is Atmel Zigbit/Meshbean.

M.C>

[tinyos-issues]

From mmar...@gmail.com on March 14, 2012 15:38:10 HI! This patch is not good either:

1) it modifies the behavior when RF230_SLOW_SPI is not defined: you have moved the update of the timestamp right after the SLP_TR.clr() and you use precious time there, you need to pump out bytes as soon as possible. The old code sent out the header at least.

2) You compare against the timesync pointer variable which might be NULL if time stamping was not requested.

Anyhow, I get the idea, I will put together a patch to get the RF230_SLOW_SPI working for you. By the way, do you run your mote at 8 MHz and only the extra debugging makes it slow?

[tinyos-issues]

From M.Cerv...@computer.org on March 14, 2012 17:27:35 Hi.

Create your own patch as you will :-)

But some hints: 1) before first byte from packed is needed there will be send

• CSMA-CA in TX_ARET (128us)
• preamble 4 bytes + SFD 1 byte (in both cases) => it give time more then 176us before first real byte will be send
• but i do not known effect if the PHR/length byte is not set. 2) ok, there is simply hack RF230DriverHwAckP @ 546 'if ((timesync != 0) && (data == timesync))...' but data pointer will not be zero to trigger if statement if timesync is zero. If timesync is zero second statement RF230DriverHwAckP @ 559 line is triggered.

The only change "-O0" to "-Os" change on 8Mhz code "while( length-- != 0 ) call FastSpiByte.splitReadWrite(*(data++));" one iteration from 36us to 3us (measured with external hw logic analyzer).

M.C>

[tinyos-issues]

From mmar...@gmail.com on March 14, 2012 17:36:24 We do NOT use hardware CSMA-CA in both drivers, so you do not have that 128 us, only the 5 bytes preamble before you have to pump in more. Also, in TASKLET_IS_TASK case this routine is running in task context, so you can have other interrupts e.g. ADC or UART.

I am amazed, that -O0 gies 36us and -Os gives 3us, that is truly eye opening and explains your problems.

[tinyos-issues]

From mmar...@gmail.com on March 14, 2012 18:43:30 Ok, what about this patch:

https://github.com/mmaroti/tinyos/commit/3bb5f4f37a099d1e9b65a0b02a299a03c7f2b091#diff-0

Does it work for you? Please test it with RF230_SLOW_SPI and without, also would be nice if you could test FTSP both with RF230_SLOW_SPI and without.

[tinyos-issues]

From M.Cerv...@computer.org on March 15, 2012 10:11:17 Seems ok to me. (do not forget replicate patch to RF230DriverHwAckP.nc).

I have (probably) explanation why do not see the problem on (some) IRIS: I take other my mote (also with internal RC 8Mhz eg. thermally and voltage unstable) and the same SPI loop iteration takes cca 32us (not 36us), that is exactly on the margin (see attached SPI outputs).

I attached some files

• test program
• output from SPI analysis (with or without debug "-O0") (on slight faster internal RC oscillator) => without debug 1 packet (~105B) is send in 3.6ms/4.0ms (noslowspi/slowspi) => with debug 1 packet is send in 4.5ms/7.5ms (noslowspi/slowspi) => in problematic case (debug+noslowspi) you must have <<0.5 ms interrupt processing (in 4.5 ms time window).
• cosmetic patch :-)

M.C>

[tinyos-issues]

From mmar...@gmail.com on October 01, 2012 15:33:09 Checked in final versions to tinyos-main