[mc1322x] Extra two bytes on xmit

[Jon Smirl]

On Thu, Nov 19, 2009 at 6:51 AM, Mariano Alvira <mar at devl.org> wrote:
> On Wed, Nov 18, 2009 at 06:41:58PM -0500, Jon Smirl wrote:
>> When I change len + 4 to len + 2, the RS (solicitation) packets are
>> correct and the router responds with RA.
>> Why is this +4?
>>
>>       /* set dma tx pointer to the payload */
>>       /* and set the tx len */
>>       reg32(MACA_TXLEN) = (uint32_t)(len+2);
>>       reg32(MACA_DMATX) = (uint32_t)tx_buf;
>>       reg32(MACA_DMARX) = (uint32_t)rx_buf;
>>       reg32(MACA_TMREN) = 0;
>>
>>
>> We aren't hearing the RAs when they come back.
>
> This has it's source in the freescale code:
>
> Weather Station Controller/SMAC/Source/RadioMngmntWrapper.h:
> maca_txlen = (uint32_t)((maMessage_Queu[current_msg]->u8BufSize)+4); \
>
> Weather Station Controller/SMAC/Drivers/Interface/ghdr/maca.h:#define
> maca_txlen_max_rxlen          (127<<16)
>
> And in rftest-tx.c I couldn't account for the + 4 either:
>
>   #define PAYLOAD_LEN 16 /* not including the extra 4 bytes for
>   len+fcs+something\ else */
>   /* maca dmatx needs extra 4 bytes for checksum */
>   /* needs + 4 bytes for len(1 byte) + fcs(2 bytes) + somethingelse */
>
> Is it possible that in Contiki len includes something that I/Freescale
> don't count as the payload? Like the FCS? That could explain why
> changing it to 2 works.

This is why there is a rule against magic numbers in the Linux kernel.

Two bytes is the FSC.  What would the other two bytes be?

I am receiving the response packets but the TCP stack is discarding
them. I'll try and figure out why this morning.

>
> -Mar.
>



-- 
Jon Smirl
jonsmirl at gmail.com