Hello, On 6/20/11, Werner Almesberger <wer...@almesberger.net> wrote: > I wrote: >> A way to avoid this should be to retrieve the PHR with an SRAM >> read and to use the frame buffer read only for the payload. > > Hmm no, that doesn't work either. SRAM read can't retrieve the PHR :-( > > I've now verified that, if packet reception is followed by a frame > buffer read, a pause, and then a second frame buffer read, a packet > received during the pause will overwrite the first packet. So the > race condition exists. > > Looking at the SPI subsystem API, I can't see a clean way to read > the PHR without also ending the frame buffer read and thus removing > the protection. Any ideas ?
I think Alexander also has added static buffer protection, which should help exactly in this case. Another possibility can be to force allocation of buffer large enough to contain max frame (128) + all necessary extra space, download frame in one fbread and then process PHR to trim skb to the length. -- With best wishes Dmitry ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
