TMS320F28P550SJ: CRC16/MODBUS Computation utilizing VCU2 on F28P55x

Elias Pareth

Hi everyone

I am currently trying to replace an older implementation of crc-computation for Modbus. On the new F28P55x we now want to utilize the capabilities of the VCU2 module. The crc algorithm I want to achive is this one:

Algorithm		Check	Poly	Init	RefIn	RefOut	XorOut
CRC-16/MODBUS MODBUS		0x4B37	0x8005	0xFFFF	true	true	0x0000

However, my current implementation does not give me the expected results. This is what i have:

uint16_t modbus_CRC(Frame* frame)

{

CRC_Obj crcObj;

CRC_Handle hCrc = &crcObj;

// Initialize CRC object

crcObj.seedValue = 0xFFFF; // Modbus initial value

crcObj.nMsgBytes = ((frame->size) - 2); // exclude last 2 bytes (CRC itself)

crcObj.parity = CRC_parity_even; // LSB first (little endian)

crcObj.crcResult = 0;

crcObj.pMsgBuffer = (uint16_t*)frame->data

crcObj.pCrcTable = 0; // VCU2 doesn't need lookup tables

// Select the reflected polynomial 0x8005

crcObj.run = (void (*)(void *))CRC_run16BitPoly1Reflected;

// Run the CRC computation

crcObj.run(hCrc);

return crcObj.crcREsult;

}

My Frame-struct has the data-fields defined as:

int size;
unsigned char data[254];

--------------------------------------------------------------------------------------------------------
This would be an example input:
https://crccalc.com/?crc=006605778899aaa2&method=CRC-16&datatype=hex&outtype=hex

In my data memory i have it as words (16bit values), {0x0000, 0x0066, 0x0005, 0x0077, 0x0088, 0x0099, 0x00AA, 0x00A2}. I would expect the result to be 0xC5B6.

I assume I need to performe some trickery with the input befor I can run it through the VCU2 but I cant' figure out what. Could somebody provide an example?

Thanks for any help in advance!

Elias

11 months ago

0 Sira Rao80 10 months ago

TI__Mastermind 28255 points

Elias,

Sorry for the delay.

One thing I noticed is that RefOut is true, so you have to flip the final CRC output that the VCRC generates. Did you do that?

If that doesn't help, these threads that I've worked on in the past may help you:

One of the primary reasons for any result differences between our VCU/VCRC HW based approach vs another approach (e.g. the linker generated CRC) is due to the order of byte handling in the VCU/VCRC library. It is LSB first, then MSB.

Refer to this e2e for details

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1300266/tms320f28388d-crc-library-on-c2000-issue-with-crc8-calculation

Another common pitfall is providing data to the VCU/VCRC library in bytes, but specifying the 8-bit byte data type. The C28 doesn't support an 8-bit byte, so it will convert it to 16-bits with padding, resulting in unexpected input data.

Refer to this e2e for details (this e2e also provides parameter mismatch handling advice, which I'll discuss next)

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1260124/tms320f280025-incorrect-output-using-the-crc-routine-provided-on-page-642-of-spruhs1c

Once this is handled, there could still be parameter matching issues that need to be addressed.

Refer to this e2e for example

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1275572/tms320f280039c-vcrc-configuration-to-match-standard-crc-32-algorithm/4834892#4834892

Thanks,

Sira

0 Elias Pareth 10 months ago in reply to Sira Rao80

Prodigy 10 points

Hi Sira

Thank you for your reply!

In the meantime I was able to resolve the problem. I'll describe my solution here for anyone struggeling with similar issues.

As you pointed out, since C28 does not support 8-bit byte data type, some changes in the assembler routine were necessary. I found this thread:

e2e.ti.com/.../crc-calculation-with-vcu2-on-f28377s-launchpad

where Vishal Coelho provided a solution that I slightly adapted to work with Poly1 (non-reflected). To do so, I had to change

VCRC16P2L_1 --> VCRC16P1L_1

Furthermore I had to reflect the input and output before running it through the vcu.

For the input:

// Reflect each byte of the Modbus payload before CRC

for (i = 0; i < (frame->size - 2); i++)

{

tempBuf[i] = reflect8(frame->data[i]);

}

...

And output:

return reflect16(hCrc->crcResult);

Where i used the functions:

unsigned char reflect8(unsigned char b)

{

b = (b & 0xF0) >> 4 | (b & 0x0F) << 4;

b = (b & 0xCC) >> 2 | (b & 0x33) << 2;

b = (b & 0xAA) >> 1 | (b & 0x55) << 1;

return b;

}

uint16_t reflect16(uint16_t x)

{

x = (x & 0xFF00) >> 8 | (x & 0x00FF) << 8;

x = (x & 0xF0F0) >> 4 | (x & 0x0F0F) << 4;

x = (x & 0xCCCC) >> 2 | (x & 0x3333) << 2;

x = (x & 0xAAAA) >> 1 | (x & 0x5555) << 1;

return x;

}

Cheers,

Elias

0 Sira Rao80 10 months ago in reply to Elias Pareth

TI__Mastermind 28255 points

Good to hear, Elias!

However, I don't think you need to spend CPU cycles in reflecting the inputs before feeding them into the VCRC. The VCRC supports an instruction that does this flipping internally (VSETCRCMSGFLIP) and this is used inside the CRC compute functions CRC_run16BitPoly1Reflected and CRC_run16BitPoly2Reflected

The high vs low byte handling solution was described in the 1st link I provided above, and is also available in our library.

Thanks,

Sira

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28P550SJ: CRC16/MODBUS Computation utilizing VCU2 on F28P55x