Hi everyone,

Suggestion: Add the following line somewhere to the init code:
RX_SYN &= ~(1 << 6);

Rationale:
I just had some "fun time" with a self-made C-port (not very beautiful, 
but it does its job) of the atm128rfa1 RFA1DriverLayerP (and the 
corresponding rfxlink layers).

Letting four ATmega256rfr2-based nodes send out broadcast packets as 
fast as possible (having the whole stack in place, including backoffs 
etc.), lead to RADIO_ASSERT(!radioIrq) being triggered in the RX_END 
ISR. After some happy debugging and thinking (is my protocolstack 
actually to slow in processing the tasklet code stuff?) I was sure that 
this should not be possible.

I then stumbled across a new and greatly-documented feature of the rfr2 
named RX_OVERRIDE, which is enabled on this chip by default (who does 
such things?). This seems to lead to RX_END interrupts which are 
triggered very soon (< 20 us) after the corresponding RX_START. In rare 
circumstances when RX_START was interrupted again by the RadioAlarm 
interrupt (and correspondingly, the TosRandomCollisionLayer 
RadioAlarm.fired() code was executed), service_radio got deferred long 
enough to allow for the RX_END to occur and the RADIO_ASSERT to happen. 
Deactivating RX_OVERRIDE solved the problem.

I do not know (as I could not try out or know how fast the actual TinyOS 
stack handles the code), if this problem would really affect an 
ATmega256rfr2 running TinyOS (which I did not), but I think it at least 
very possible. Considering this, I suggest to add the code shown above 
to the init function of the driver to make the current radio driver safe 
for all rfr2-type chips (also in case someone "ports" the code to rfr2 
and is -- like me -- unaware of this new feature), so that other people 
are spared the pain I just lived through during the last few days

Regards,
Andreas
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to