Commit b43dad00b breaks RF230BB on `avr-raven` and `avr-ravenusb` platforms

[darconeous]

I have noticed that commit b43dad00b ("Cleaned up RF230BB, and refactored FRAME_RETRIES and CSMA_RETRIES") has broken reception of packets for the avr-raven and avr-ravenusb platforms. Sending packets is unaffected. I'm not able to test the effect of this commit on other platforms which use RF230BB.

Reverting the change once again allows these platforms to work properly.

Investigation seems to indicate that the radio interrupt is no longer firing. Before b43dad00b, TIMER1 was being used to generate interrupts because both the avr-raven and avr-ravenusb boards do not connect the IRQ pin on the RF230 to a pin on the µC which can directly generate an interrupt. I'm guessing that this has been disrupted and the timer is no longer generating the interrupts that RF230BB needs.

Tagging @dak664 because he is relatively familiar with this code.

b43dad00b was contributed by @idelamer.

[dak664]

The rf230 irq pin is connected to PD6 on the raven, which is the timer1 input capture trigger. That is a separate interrupt vector than the timer1 overflow used for the mac clock (which was disabled in that commit because it seemed a waste of time).

initialization should do hal_enable_trx_interrupt() where

define hal_enable_trx_interrupt( ) HAL_ENABLE_RADIO_INTERRUPT( )

where

define HAL_ENABLE_RADIO_INTERRUPT( ) ( TIMSK1 |= ( 1 << ICIE1 ) )

which enables the input capture interrupt on PD6

The chart in 14-3 of the datasheet shows the output of the comparator teeing to the capture interrupt and the input capture latch that samples timer1. So it does not appear timer1 needs to be running or have its interrupts enabled for the PD6 interrupt to occur. But maybe the timer does have to be running before the comparator is enabled.

I think that commit worked on the cooja raven mote, but that of course would depend on the correct simulation of timer1. Currently Avrora does not need timer1 to be enabled for the input capture interrupt to work.

[idelamer]

Thanks for reporting, I'll take a look at it.

[idelamer]

In order to enable the Timer1 we can edit the following line:

define HAL_ENABLE_RADIO_INTERRUPT( ) { TCCR1B = ( 1 << ICES1 ) | ( 1 << CS10 ); TIFR1 |= (1 << ICF1); TIMSK1 |= ( 1 << ICIE1 ) ; }

I'm trying to push to my repo but I'm still figuring out GitHub, it seems to be rejecting my push request.

So maybe you can try this edit and see if the interrupts fire again? I will try to push to my Repo and generate a Pull request ASAP.

[idelamer]

OK, the change has been pushed to my repo, if you can test it and it solves your issue I will generate a pull request.

git://github.com/idelamer/contiki.git

[dak664]

Have you found that the timer overflow interrupt needs to be enabled to get radio interrupts on the capture pin?

[darconeous]

I'll have a look either tonight or tomorrow.

[idelamer]

@dak664 I'm not able to test this, but reading the datasheet it seems like we need the timer running for ICP to trigger an interrupt, partly because there is a 4-clock-cycle noise filter. I enabled clock with prescaler = 1 for faster interrupt

@darconeous let me know if this works for you so I can create a Pull request. We then need to "Ack" it so it can be considered for inclusion

[darconeous]

works like a charm. :+1:

[idelamer]

@darconeous @dak664 Ive created pull request #143 could you please "ack" it, we need at least 2 Acks so that it is merged into master.

[idelamer]

Hey Robert,

Just wanted to say thank you for posting this and working through merging this fix into master.

IT was my first commit since Contiki moved to Github so thank you for your patience.

I guess issue #88 can be closed now, it seems like you may have to do it?

Cheers Ivan

On 2013-02-23 19:06, Robert Quattlebaum wrote:

works like a charm.

-- Reply to this email directly or view it on GitHub [1].

Links:

[1] https://github.com/contiki-os/contiki/issues/88#issuecomment-14002038

[darconeous]

Sure thing. Thanks for fixing it!