Closed usedbytes closed 2 years ago
From a quick look on Wikipedia, it seems like for CRC32 you need to initialise dma_hw->sniff_data
to 0xFFFFFFFF first? (and then XOR it with 0xFFFFFFFF again afterwards)
Thank you! That helped a lot.
Using 0xffffffff
as a starting value, XOR with 0xffffffff
on the result, and using Mode 1, I can get values which are bit-reversed versions of the Go numbers.
Curiously, the OUT_REV
control bit doesn't seem to do anything. I think if I could get that to work then Mode 1 + OUT_REV
would give me the same values as Go directly.
---
Data: (16 bytes)
00: 01 00 00 00 00 02 00 00 00 00 03 00 00 00 00 04
DMA_SIZE_32
Mode 0, sniff_ctrl: 0x00000001, result: 0x4c811132
Mode 0, sniff_ctrl: 0x00000401, result: 0x4c811132
Mode 1, sniff_ctrl: 0x00000021, result: 0x4dab62d9
Mode 1, sniff_ctrl: 0x00000421, result: 0x4dab62d9
---
Data: (4 bytes)
00: 00 00 00 00
DMA_SIZE_32
Mode 0, sniff_ctrl: 0x00000001, result: 0x38fb2284
Mode 0, sniff_ctrl: 0x00000401, result: 0x38fb2284
Mode 1, sniff_ctrl: 0x00000021, result: 0x38fb2284
Mode 1, sniff_ctrl: 0x00000421, result: 0x38fb2284
---
Data: (16 bytes)
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
DMA_SIZE_32
Mode 0, sniff_ctrl: 0x00000001, result: 0xaad2dd37
Mode 0, sniff_ctrl: 0x00000401, result: 0xaad2dd37
Mode 1, sniff_ctrl: 0x00000021, result: 0xaad2dd37
Mode 1, sniff_ctrl: 0x00000421, result: 0xaad2dd37
---
Data: (8 bytes)
00: 01 01 01 01 01 01 01 01
DMA_SIZE_32
Mode 0, sniff_ctrl: 0x00000001, result: 0xdb4570d3
Mode 0, sniff_ctrl: 0x00000401, result: 0xdb4570d3
Mode 1, sniff_ctrl: 0x00000021, result: 0xcb448574
Mode 1, sniff_ctrl: 0x00000421, result: 0xcb448574
Go with reverse:
---
Data: (16 bytes)
00000000 01 00 00 00 00 02 00 00 00 00 03 00 00 00 00 04 |................|
CRC32: 0x9b46d5b2, reversed: 0x4dab62d9
---
Data: (4 bytes)
00000000 00 00 00 00 |....|
CRC32: 0x2144df1c, reversed: 0x38fb2284
---
Data: (16 bytes)
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
CRC32: 0xecbb4b55, reversed: 0xaad2dd37
---
Data: (8 bytes)
00000000 01 01 01 01 01 01 01 01 |........|
CRC32: 0x2ea122d3, reversed: 0xcb448574
Curiously, the
OUT_REV
control bit doesn't seem to do anything
That would be disappointing... can you post a code snippet of how you used it
In tidying up my snippet to post, I figured it out - I was reading the result after calling dma_sniffer_disable()
, which clears OUT_REV
.
So, working as intended.
Having a more complete API for the sniffer would be useful so that you don't have to use hardware_structs
to seed SNIFF_DATA
and configure SNIFF_CTRL
.
I'm trying to use the DMA sniffer to calculate the CRC of some data, but it doesn't behave as I'd expect.
In particular, the value it returns for CRC32 of a string of zeroes is zero, which doesn't seem right.
I'm using the following test program:
Which gives this output:
The "Mode f" values look correct (summation of all the input data, 32-bits at a time), so I'm fairly sure my code is working as expected, but I'm not able to get the CRC values to line up with what I'd expect.
For reference, the same tests in
go
and their output below. You can run it online here: https://play.golang.org/p/ZZA9B6oNCswGo's
ChecksumIEEE
is using the IEEE802.3 polynomial, the same as is mentioned in the RP2040 datasheet.As another data point, the
crc32
utility I have on my machine ("This utility is supplied with the Archive::Zip module for Perl.", apparently) produces values which agree withgo
:Can you provide more details on how the DMA sniffer CRC32 algorithm works? Am I using it wrong?