 |
 |
| View previous topic :: View next topic |
| Author |
Message |
apakSeO
Joined: 07 Dec 2016
Posts: 60
Location: Northeast USA
|
| PIC24 CRC module does not appear to generate correct CRC |
 Posted: Fri Mar 24, 2017 12:29 pm |
 |
|
Using:
CCS v5.070
MPLAB X IDE v3.40
PIC24FJ256GB210
I cannot setup the CRC module to generate valid CRC codes. The codes out of the CCS function do not match the de-facto standard CRC calculator from
https://www.lammertbies.nl/comm/info/crc-calculation.html#intr
For debugging transparency, the test code below uses all global variables. When I pause the debugger, I can see that crcSeed and lengthInBytes is correctly displayed.
I've checked the device's datasheet and errata, as well as the test code EX_CRC in CCS's Examples directory, but they reveal nothing of note. I've also scoured this forum and found one or two entries relating to the CRC module, but it was no help.
My code:
| Code: |
#include <24FJ256GB210.h>
#fuses NOWDT,NOWRT,NOPROTECT//,NOWPDIS,NOWPCFG,NOIESO,NOWPFP
#device PIC24FJ256GB210 ICD=TRUE
#use delay(INTERNAL=8MHz, CLOCK=32MHz)
// The CRC16 result of the below byte sequence using the polynomial
// x^16 + x^12 + x^5 + 1 with a initial seed of 0x1D0F should be 0xCA67
unsigned int8 data1[]={0xAB,0xCD,0xEF,0xAA};
unsigned int16 lengthInBytes;
unsigned int16 crcSeed;
unsigned int8* data1_ptr; // Create pointer to start of data1[]
unsigned int16 crcResult;
void main(void)
{
// Initialize values
lengthInBytes = 0;
crcResult = 0x0000;
crcSeed = 0x1D0F;
while(1){
// Check output of crcResult before pushing button in watches
// subwindow of MPLAB X ... should default to 0x0000 as above
if( !input(myButton1) ) { // If button pushed, do the crc calc
data_ptr = data1; // Set pointer to start addr of data1
lengthInBytes = sizeof(data1);
// Initialize & run the CRC module
setup_crc(16,12,5); // x^16 + x^12 + x^5 + 1
crc_init(crcSeed);
crcResult = crc_calc16(data1_ptr,lengthInBytes,8);
delay_ms(100);
}
}//while(1)
return;
}
|
The code above consistently returns a value of 0x28DF after a button push, when a CRC of 0xCA67 is expected. I've tried several other byte sequences and they are all incorrectly output from the calc_crc() function.
Any ideas on where my error may exist?
Last edited by apakSeO on Fri Mar 24, 2017 2:57 pm; edited 1 time in total |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Fri Mar 24, 2017 12:57 pm |
|
|
OK, I don't use that PIC but....
some things to ponder..
1st thought... get rid of the 'push button' code.
do something simple like
power up
delay 2 seconds
do calculation
display result
loop forever.
2nd not too sure why the return at the bottom of the program....
3rd I don't see any 'display results' code, Nothing to say a PC or LCD, so HOW do your KNOW the result is 'bad'?
4th ICD=true WILL affect how the PIC operates,though I never use it.
5th how was it compiled? In 'release' or 'debug' mode if using MPLAB, That WILL affct it! |
|
|
apakSeO
Joined: 07 Dec 2016
Posts: 60
Location: Northeast USA
|
|
| Posted: Fri Mar 24, 2017 1:17 pm |
|
|
| temtronic wrote: | OK, I don't use that PIC but....
some things to ponder..
1st thought... get rid of the 'push button' code.
do something simple like
power up
delay 2 seconds
do calculation
display result
loop forever.
2nd not too sure why the return at the bottom of the program....
3rd I don't see any 'display results' code, Nothing to say a PC or LCD, so HOW do your KNOW the result is 'bad'?
4th ICD=true WILL affect how the PIC operates,though I never use it.
5th how was it compiled? In 'release' or 'debug' mode if using MPLAB, That WILL affct it! |
(1) Push button code is only there so I can observe the values in the "Watch" debug window prior to crc_calc() call, and then observe any changes after the call to crc_calc(). Push button code operates fine; I've tested this block by setting a temp variable equal to the dereferenced data1[] pointer. Then, each subsequent push of the button does a ++data1_ptr; in the Watches tab I can see the value of temp cycle through the bytes in data1[] so I know the pointer is actually pointing to the start of my data1[] array and incrementing correctly. ( This temp code is not posted in my original post however )
(2) Having a return or no return as the last line of main doesn't affect the output; I checked this in code experiments.
(3) I am not using any display results code because I don't have a way to physically display the 16-bit CRC code other than to store it in a global variable and then observe it change in MPLAB's Watches/Debug tab.
(4) I commented out ICD=TRUE; no effect on the output of crc_calc
(5) Since I am running the debugger and ICD3, I am assuming CCS compiles it in debug mode. I don't see how this would affect the result. Please give me an example where running in debug mode corrupts a value of a variable stored in memory.
Additional info:
There a note on endianess in the CCS manual. I've both (a) commented out the CRC_LITTLE_ENDIAN line in the device header file and (b) left it as is. No effect on the CRC output. Next I tried to manually set/unset the "endianness" bit located at CRCCON1.3. This also proved to have no effect, which struck me as mighty odd. |
|
|
apakSeO
Joined: 07 Dec 2016
Posts: 60
Location: Northeast USA
|
|
| Posted: Fri Mar 24, 2017 2:48 pm |
|
|
I also found another piece of information:
When the number of bytes in data1[] is odd, the value of crcResult changes with each subsequent call to crc_calc(). This was odd, as I am resetting everything prior to each call to crc_calc(). However, I found a mention on the Microchip forums stating that the crc module will not work with an odd number of bytes; if you have an odd number of bytes, you have to stuff 0x00 at the tail end to correctly run with the hardware module.
That being said ... when data1[] contains an even number of bytes such as
int8 data1[] = {0xAB,0xCD,0xEF,0x12}
crcResult is returned with the wrong value anyway. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Mar 24, 2017 6:05 pm |
|
|
| Quote: | | The codes out of the CCS function do not match the de-facto standard CRC calculator. |
If this is your complaint, you really ought to ask CCS support about it.
Show them your sample code (and the link) in your email. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19549
|
|
| Posted: Sat Mar 25, 2017 5:03 am |
|
|
Look at this MicroChip thread:
<http://www.microchip.com/forums/m272409.aspx>
Your direction may be wrong.
Standard CRC for RS232 streams, requires the reverse direction.
There is a CCS define to alter the direction.
Have a look also at this thread:
<http://www.microchip.com/forums/m885342.aspx> |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
