Hi Alex,
I've changed the Kernel module so that i read the Framebuffer as SRAM
and not as FrameBuffer.
I've write a 0x00n followed by 0x00 to determine a SRAM read from the
addr 0.
But the Kernel Module can not identity the frame length any more.
The Sniffed packages (all Packages have 143 byte length) do not show the
behaviour any more.
Maybe the SRAM read access is protected and the Frame-buffer Read not...?
Best Regards
Sebastian Balz
Am 31.07.2017 um 15:48 schrieb Alexander Aring:
Hi,
On Sat, Jul 29, 2017 at 8:05 AM, Balz <Sebastian.balz@xxxxxxxxxx> wrote:
Hi Alex,
The Atmel/Microchip Team ask me to do not a Frame-Buffer Reader but a SRAM read(addr 0x00-0x7F)
I locked through the Code but could not find the Frame-Buffer reading part.
We start the read frame buffer command at [0].
I would like to recompile the corresponding part and check if that changes something
For me it sounds weird. You definitely lost the frame buffer
protection with that.
Is there some errata released where it stands you should use SRAM access?
If I would be atmel, then maybe try to use manual locks, see register
bits "RX_PDT_DIS". If they don't trust that automatic way doesn't
work.
You can change the code as well to use the manual way.
- Alex
[0] http://elixir.free-electrons.com/linux/latest/source/drivers/net/ieee802154/at86rf230.c#L758
--
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
