2015-07-27 19:28 GMT+02:00 Alexander Aring <alex.aring@xxxxxxxxx>: > On Mon, Jul 27, 2015 at 05:55:27PM +0200, Baptiste Clenet wrote: >> 2015-07-27 17:13 GMT+02:00 Baptiste Clenet <bapclenet@xxxxxxxxx>: >> >>> Then forget that and make some at86rf230 driver debug messages. See >> >>> "print_hex_dump" [0]. Add this add skb->data in at86rf230_xmit and >> >>> at86rf230_rx_read_frame_complete (but after the skb is filled with data, >> >>> otherwise it makes no sense). >> >>> >> >>> This will allow us to see what's the lowest layer is. If the transmit >> >>> side looks correct, but receive side looks weird then I suppose >> >>> something is wrong again with your spi setup. >> >>> >> >>> The reason is that we get the lowest dump of the transmitted and >> >>> received buffer and nobody touched that buffer then. >> > >> > I dump the packet in at86rf230_xmit and >> > at86rf230_rx_read_frame_complete (just before >> > ieee802154_rx_irqsafe(lp->hw, skb, lqi)). This is wireshark analyse of >> > the two packets. The first one is correct and comes from the sender, >> > the second is from the receiver (I manually created the hex dump file) >> > which is wrong! So something seem to occur when the frame goes to the >> > transceiver. > > ah, sorry I misunderstood you. So you have capture the raw data for > transmit and receiving and it differs. Then I have still no idea what's > wrong on your side. :-) > > - Alex Yes it's what I did :-) But you gave me an idea by saying that I should send only 0xabcd and see if I receive the same. Which is the easiest way to send 0xabcd as a raw value? at86rf230_xmit requires struct ieee802154_hw *hw, struct sk_buff *skb and at86rf230_xmit_start a void *context. Why don't we have a simple at86rf230_send_raw_data :-) -- Baptiste -- 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
