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

[GoogleCodeExporter]

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 reported on code.google.com by M.Cerv...@computer.org on 11 Mar 2012 at 1:11

[GoogleCodeExporter]

updated patch.

Original comment by M.Cerv...@computer.org on 12 Mar 2012 at 6:29

[GoogleCodeExporter]

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

Original comment by mmar...@gmail.com on 13 Mar 2012 at 10:04

[GoogleCodeExporter]

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>

Original comment by M.Cerv...@computer.org on 13 Mar 2012 at 11:26

Attachments:

• rf230_slow.patch

[GoogleCodeExporter]

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?

Original comment by mmar...@gmail.com on 14 Mar 2012 at 3:38

[GoogleCodeExporter]

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>

Original comment by M.Cerv...@computer.org on 14 Mar 2012 at 5:27

[GoogleCodeExporter]

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. 

Original comment by mmar...@gmail.com on 14 Mar 2012 at 5:36

[GoogleCodeExporter]

Ok, what about this patch:

https://github.com/mmaroti/tinyos/commit/3bb5f4f37a099d1e9b65a0b02a299a03c7f2b09
1#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.

Original comment by mmar...@gmail.com on 14 Mar 2012 at 6:43

[GoogleCodeExporter]

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>

Original comment by M.Cerv...@computer.org on 15 Mar 2012 at 10:11

Attachments:

• mc20120315.tar

[GoogleCodeExporter]

Checked in final versions to tinyos-main

Original comment by mmar...@gmail.com on 1 Oct 2012 at 3:33

• Changed state: Fixed