Hello.
On 27/08/15 12:13, Alexander Aring wrote:
On Thu, Aug 27, 2015 at 11:56:43AM +0200, Stefan Schmidt wrote:
Hello.
On 06/08/15 17:21, Alexander Aring wrote:
When transmit is done, indicated by trx_end irq, we do first a force
state change to TX_ON and then checking the trac status, if the trac
status is unequal zero we do a state change to TRX_OFF.
This patch changes to the following behaviour, we first check on trac
status after trx_end occurs and then doing a normal change to TX_ON
without do the state change to TRX_OFF when trac status is unequal zero.
The reasons are that the datasheet doesn't described when the trac
status register is cleared, we should doing to evaluate the trac status
at first. The reason to remove the TRX_OFF change if the trac status is
unequal to zero and it was force is the following paragraph inside The
at86rf2xx datasheets:
"Using FORCE_PLL_ON to interrupt an TX_ARET transaction, it is
recommended to check register bits [7:5] of register address 0x32 for
value 0. If this value is different, TRX_CMD sequence FORCE_TRX_OFF shall
be used immediately followed by TRX_CMD sequence PLL_ON. This performs a
state transition to PLL_ON."
I had a hard time finding a register description of 0x32 in my copies. Are
they outdated or am I just blind? Any hints appreciated. :)
I think this is a mistake in the datasheet, they mean the "TRAC_STATUS"
here, which is the only value which fits in the range of [7:5] in
Register 0x02.
This makes more sense. Thanks.
Code 4 and 6 and marked as reserved which is what you are counting
aggregated in the reserved counter.
Not sure if that really buys us anything. We don't know if we get them
at all (something we will see over time with your patches), we don't
know which one comes in (count be changed when counting them separately)
but most important we don't know what they mean and what we should do. :)
I would say ignore them. The counter has no meaning for us.
regards
Stefan Schmidt
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
