2014-02-02 06:04 PM
The original post was too long to process during our migration. Please click on the attachment to read the original post.
2014-09-30 12:33 PM
2014-09-30 04:02 PM
Did you get the right answer on modbus CRC16 using the hardware CRC on STM32F3 ???
Assume that it does and that I provided code that demonstrates such.2014-10-07 07:56 AM
I've made a BIG STUPID mistake kakaakakaka
But I asked you because I'm using a proprietary hardware and I'm not using the driver functions that ST provide.But everything worked well here.Thanks for the code.2016-04-15 08:54 AM
Hi everybody,
I was testing around the F7 functionalities and the CRC was giving me some headache, searching for a solution I landed here. The code provided by Clive was not working for me, I had to change the function CRC_HardwareBlock to consider the reversal bit order when the buffer is not multiple of 4bytes This is my functionuint32_t CRC_HardwareBlock(int Size, const uint8_t *Buffer)
{
uint32_t data32;
uint16_t data16;
uint32_t data8;
CRC->CR = (CRC->CR&0x9F) | 0x60;
while(Size >= 4) // Do as much as we can at 32-bits
{
data32 = *((uint32_t *)Buffer);
CRC->DR = data32;
Buffer += 4;
Size -= 4;
}
CRC->CR = (CRC->CR&0x9F) | 0x40;
while(Size >= 2) // Perhaps one of these
{
*((uint16_t *)&CRC->DR) = *((uint16_t *)Buffer);
Buffer += 2;
Size -= 2;
}
CRC->CR = (CRC->CR&0x9F) | 0x20;
while(Size--) // Perhaps one of these
*((uint8_t *)&CRC->DR) = *Buffer++;
return(CRC->DR); // Return final CRC computation
}
CRC->CR is overwritten and doesn't care about your initialization
I also had problem with the F7 and the optimization, had to compile the code with optimization level 0 in keil.
2016-04-15 10:05 AM
This would likely remedy the optimization issues
*((volatile uint16_t *)&CRC->DR) = ...2016-04-15 10:08 AM
Can you provide some specific detail of the CRC, polynomial, shift-direction, that has an issue and a couple of test cases for this?