Are you saying that the FCS is wrong when this happens but when you read th=
e=20
buffer a second time the data (and FCS) is right?

It could also be a problem with the part that writes the (long-)address for=
 the=20
register that you should read from the RX-FIFO so you are actually reading =
at=20
the wrong address. This doesn't explain the wrong FCS though.

/Ruben

> Hi all,
> I am seeing occasional data corruption when using the Microchip MRF24J40
> 802.15.4 radio modules. The details are really weird, though! When a fram=
e
> arrives over the air, the MRF stores it into a memory buffer. The attache=
d logic
> (MCU/FPGA/whatever) then uses the SPI to disable the receiver, read the b=
ytes
> out of the buffer, and re-enable the receiver. Occasionally, I will read =
out a
> byte from the buffer and see something completely different-often, a byte=
 that
> should be 0x00 is instead 0xB9 (I think I remembered the value correctly)=
..
>=20
> I immediately thought of two obvious possible explanations: either the wr=
ong
> data is being put in at the transmitter end, or the data is being corrupt=
ed in
> the air. However, these explanations are both impossible. The receiving M=
RF
> includes the CRC-16 frame check sequence in its receive buffer (it is als=
o
> supposed to check the FCS and not receive frames that fail). When I read =
out the
> FCS, and verified it in my MCU, it was wrong. The weirder part is that si=
mply
> reading out the frame (or, indeed, even the single erroneous byte) from t=
he
> memory buffer a second time would give the correct data-this is for the s=
ame
> frame; bear in mind the receiver was disabled this whole time!
>=20
> This made me think there was something wrong with my SPI code, but I saw =
exactly
> the same problem on two completely different platforms (an STM32F4 and an=
 FPGA).
> I managed to capture the exact SPI transaction that carried the faulty da=
ta on a
> scope (unfortunately I no longer have a copy of the trace to share), and =
I
> couldn=B4t see anything wrong with CS, clock, or MOSI either-it looked li=
ke a
> perfectly ordinary transaction, except the data the MRF sent back on MISO=
 was
> wrong, and blatantly so, not just by one bit flipped or shifted.
>=20
> Has anyone used these chips and seen anything like this? Any ideas? Thank=
s! --
> Christopher Head
>=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
Ruben J=F6nsson
AB Liros Electronic
Box 9124, 200 39 Malm=F6, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
ruben@pp.sbbs.se
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.