DMA-CRC不产生结果

通过改变我的单元格大小以匹配SRCSIZE，DMA完成回调函数确实被调用。现在确认返回的CRC值…



      以下为原文

    By changing my cellSize to match the srcSize, the dma completion callback function does get called. Now to confirm the CRC value returned...

我很难得到CRC输出来匹配我所期望的。我试图保持简单，并在字节“a”上计算CRC-ccITT，期望输出为0x69f0（如HTTPS://www. LAMMLITBES.NL/COMM/Ifc/CRC计算.html所述）。但是在玩了所有我能找到的设置之后，我只能从0xE176或0xE191的PIC中得到输出，这取决于我是否使用了MaaCrCyBITORADORIGORILLSB ORMAMACRCRBITYORADORIZORMSB。将BUF和DSTBUF的数据集更改为UTI1616T或UTIT32×T并不重要。我的触发代码：事件处理程序：



      以下为原文

    I'm having trouble getting the CRC output to match what I expect.  I'm trying to keep things simple and calculate the CRC-CCITT on the byte 'a', expecting the output to be 0x69F0 (as stated by https://www.lammertbies.nl/comm/info/crc-calculation.html).  But after playing with all the settings I can find, I can only get outputs from the PIC of 0xE176 or 0xE191 depending on whether I use DMA_CRC_BIT_ORDER_LSB or DMA_CRC_BIT_ORDER_MSB. Changing the datasize of buf and dstbuf to uint16_t or uint32_t doesn't seem to matter.
 
My trigger code:

uint8_t __attribute__((coherent)) __attribute__((aligned(16)))buf[14];
uint8_t __attribute__((coherent)) __attribute__((aligned(16)))dstbuf[14];
 
int DmaDoCrcExample(void)
{
/* Allocate DMA channel */
dmaHandle = SYS_DMA_ChannelAllocate(DMA_CHANNEL_ANY);
if (SYS_DMA_CHANNEL_HANDLE_INVALID == dmaHandle) {
while (1); //Trapped
}

SYS_DMA_ChannelTransferEventHandlerSet(dmaHandle, myDMAEventHandler, (__uintptr_t)&thisthat);

SYS_DMA_ChannelSetup(dmaHandle,(SYS_DMA_CHANNEL_OP_MODE_BASIC | SYS_DMA_CHANNEL_OP_MODE_CRC),DMA_TRIGGER_SOURCE_NONE);

/*
crc.type - CRC will calculate an IP header checksum or an LFSR CRC.
crc.mode - Compute the CRC in Background/Append mode.
crc.polyLength - Denotes the length of the polynomial.
crc.bitOrder - CRC is calculated LSb/MSb first.
crc.byteOrder - Byte selection order input pre-CRC Generator
crc.writeOrder - Write byte order selection post-CRC computation
crc.data - Computed/Seed CRC
crc.xorBitMask - Enable/Disable XOR bit mask on the corresponding bits
when mode is LFSR
*/
static SYS_DMA_CHANNEL_OPERATION_MODE_CRC crcMode;

crcMode.type = DMA_CRC_LFSR;
crcMode.mode = SYS_DMA_CHANNEL_CRC_MODE_APPEND;//SYS_DMA_CHANNEL_CRC_MODE_BACKGROUND;//
crcMode.polyLength = 16;
crcMode.bitOrder = DMA_CRC_BIT_ORDER_LSB;//DMA_CRC_BIT_ORDER_MSB;//
crcMode.byteOrder = DMA_CRC_BYTEORDER_NO_SWAPPING;//DMA_CRC_SWAP_BYTE_ON_WORD_BOUNDARY;//DMA_CRC_SWAP_HALF_WORD_ON_WORD_BOUNDARY;//DMA_CRC_SWAP_BYTE_ON_HALF_WORD_BOUNDARY;//
crcMode.writeOrder = SYS_DMA_CRC_WRITE_ORDER_MAINTAIN;//SYS_DMA_CRC_WRITE_ORDER_CHANGE;//
crcMode.data = 0xFFFF;
crcMode.xorBitMask = 0x1021;

SYS_DMA_ChannelCRCSet(dmaHandle, crcMode);
/*
srcAddr - Source of the DMA transfer
srcSize - Size of the source
destAddr - Destination of the DMA transfer
destSize - Size of the destination
cellSize - Size of the cell
*/

buf[0] = 'a';
buf[1] = 'b';
buf[2] = 'c';
buf[3] = 'd';
buf[4] = 'e';
buf[5] = 'f';
buf[6] = 'g';
buf[7] = 'h';
buf[8] = 'i';
buf[9] = 'j';
dstbuf[0] = 1;
dstbuf[1] = 1;
dstbuf[2] = 1;
dstbuf[3] = 1;
dstbuf[4] = 1;
dstbuf[5] = 1;
dstbuf[6] = 1;
dstbuf[7] = 1;
dstbuf[8] = 1;
dstbuf[9] = 1;

void *srcAddr;
void *destAddr;
size_t srcSize;
size_t destSize;
size_t cellSize;
srcAddr = (uint16_t *) &buf[0];
srcSize = 1;
destAddr = (uint16_t*) dstbuf;
destSize = 1;
cellSize = 1;

SYS_DMA_ChannelTransferAdd(dmaHandle, srcAddr, srcSize, destAddr, destSize, cellSize);
if(SYS_DMA_CHANNEL_HANDLE_INVALID == dmaHandle)
{
// Error handling here
}

//SYS_DMA_ChannelEnable(dmaHandle);
SYS_DMA_ChannelForceStart(dmaHandle);
//SYS_DMA_ChannelRelease(dmaHandle);
return (0);
}

 
event handler:

void myDMAEventHandler(SYS_DMA_TRANSFER_EVENT event,
SYS_DMA_CHANNEL_HANDLE handle, uintptr_t contextHandle){
uint32_t output = 0;
/* handler */
output = SYS_DMA_ChannelCRCGet();

while (output > 0){
output--;
}
}

我不确定，因为我从来没有使用过CRC模块，但这是



      以下为原文

    I am not sure 'cause i never used the CRC module, but is this
crcMode.xorBitMask = 0x1021;
correct?

What CRC are you willing to use?

我非常确信0x1021的xOrdScript是正确的，因为它与CCITT多项式匹配：CRC-CCITT0x1021x16+x12+x5+1，我引用了HTTPS://www. LAMMRTBI.NL/CAM/IfO/CRC-Caligal.HTMLSITE，表示：



      以下为原文

    I'm quite sure the xorbitmask of 0x1021 is correct because it matches the CCITT polynomial: 
CRC-CCITT0x1021x16 + x12 + x5 + 1 
Also, I referenced the https://www.lammertbies.nl/comm/info/crc-calculation.html site which indicates:

 

我同意这一点，我只是不确定这个数字，因为它没有被列出在上窗口的那个网站上。所以，下一步是尝试软件解决方案，然后再移动到DMA版本。



      以下为原文

    I agree on that;
I was just not sure about that number at a glance, since it was not listed on that site in the upper window.
 
So, next step would be trying a software solution and then move on to the DMA version.

CRC-ccITT的计算差异是在数据末尾的16位零点增加，如其他论坛所述。为了简单起见，为了得到正确的消息“A”的CRC-ccITT计算，而不是使用一个字节的数据“A”，使用三字节的数据“a”、0x00、0x00。PIC32 MZ CRC算法（MSB，0xFFFF种子，0x1021位掩码）的输出是0x947。我至少可以在CRC计算网站上找到这个值。在HTTPS://www. LAMMRTBI.NL/CAM/IfO/CRC-Caltual.HTML-这个值是0x1D0F种子的结果。在Hopp://Scord.SooCurrF.G.NET/CRC16-ccITT.HTMLL，该值是0xFFFF种子的结果。将数据扩展到“AB”，使用20个字节，PIC32 MZ算法的结果是0xD2BB。再次，在LAMMyTepe上，这与0x1D0F种子匹配。因此，至少我有一致性。



      以下为原文

    The CRC-CCITT calculation difference is found in the 16bit zero augmentation at the end of the data, as touched on in other forums.
For simplicity, in order to get the correct CRC-CCITT calculation for the message "a", instead of having one byte of data 'a', use three bytes of data 'a', 0x00, 0x00. The 16bit zero augmentation is required.
 
The output of the pic32mz crc algorithm (MSB, 0xFFFF seed, 0x1021 bitmask) is 0x9479.
I can at least find this value on the sample crc calculation websites.
On https://www.lammertbies.nl/comm/info/crc-calculation.html that value is the result with the 0x1D0F seed. 
On http://srecord.sourceforge.net/crc16-ccitt.html that value is the result of the 0xFFFF seed.
 
Extending my data to "AB" with two zero bytes, the result of the pic32mz algorithm is 0xD2BB.
Again, on lammertbies this matches the 0x1D0F seed. 
 
So at least I have consistency.