[mc1322x] suggestions for code errata

[Peter Lawrence]

Hmmm... I can't fault your interpretation.  I'm seeing the assembly in
the same way you did.

I think I've figured it out, though.

It seems to be the product of a very efficient compiler as a way to
set r3 to 0x2000 in only two Thumb instructions.

Bit 13 (the bit set by pre-initializing r3 to 0x2000) of POW2,
although NOT documented in the RM, is indicated elsewhere as
controlling whether PA_POS and PA_NEG are used.  (These are the
differential outputs for use with an external PA.)

The mystery r1=1 mode accesses 403e00 (.word   0xffffdfff) which is
used to clear bit 13.

Bit 13 apparently should be set for single port mode (just use
RF_RX_TX), and cleared for dual port mode (use PA_POS and PA_NEG).

So, another way of writing the code could be:

#ifdef USE_PA
reg(ADDR_POW2) = 0xffffdfff & PAVAL[power]; /* single port */
#else
reg(ADDR_POW2) = 0x00002000 | PAVAL[power]; /* dual port */
#endif

Technically speaking, PAVAL already has bit 13 set (so the OR is
unnecessary), but doing the OR makes it more fool-proof.

On Fri, Oct 9, 2009 at 1:53 PM, Mariano Alvira <mar at devl.org> wrote:
> On Fri, Oct 09, 2009 at 01:17:46PM -0400, Peter Lawrence wrote:
>>
>> 1) Line 344 of maca.c (set_power() function) looks suspect:
>>
>>       reg(ADDR_POW2) = (ADDR_POW1>>18) | PAVAL[power];
>>
>> It just seems odd that one would write the MSBs of the value of the
>> address of register POW1 into the register POW2.
>
> Indeed it is odd. Please see
>
>   http://git.devl.org/?p=malvira/mc1322x-tests.git;a=blob;f=doc/ws-dis
>
> around line 6810 to see where this is coming from. It's very possible
> I incorrectly interpreted the assembly.
>
>> 2) XTAL_CNTL is not initialized
>>
>> However, the RM suggests 0x15 coarse and 0x10 fine as starting values.
>>  Using those, I experience much better reception of packets.
>>
>> So, if you experience the same problems, it may be worth trying to
>> write XTAL_CNTL with, say, the value of 0x28E0F52 to see if reception
>> improves.
>
> This is certainly fair. Thanks for the note. Has anyone come up with a
> way to determine what these should be?
>
> -Mar.
>