CRC Errors using BISS-C feature of TMDXIDDK379D Design Drive Kit

Hi Brent,

Do the following other two major defines from bissc.h match your encoder:

#define BISS_SCD_CRC_NBITS_POLY1       6
#define BISS_SCD_CRC_POLY1             0x03   //x^6 + x + 1 (inverted output) 1000011

(especially the polynomial)

These are often very encoder specific.


Thank you,
Brett

Brent,

You seem to do the right thing in configuring the 32 bits for position and 6 bit crc.
Can you check all the parameters to the CRC function call?
uint16_t PM_bissc_getCRC(uint16_t input_crc_accum, uint16_t nBitsData, uint16_t nBitsPoly, uint16_t * msg, uint16_t *crc_table, uint16_t rxLen);
Particularly the rxLen - it should match the number of bytes of data for CRC calculation.
It would be great if you can share some data - all the parameters being passed to this function and expected and actual CRC values.
I do understand why  positionBits, numWordsPosCrc, scdBitsParsed are incorrect in your case.
Will you be able to share the project?

-Bharathi.

Hi Brent,

After looking at the code, it appears that the current software has a 30-bit position data limit.  The GetBits function and the biss_data_struct.scd_raw element would be the main troublemakers because they are 32bit data types.

We will work to correct this in a future release of Position Manager within controlSUITE.

However, I believe you can edit the bissc_receivePosition function within bissc.c to workaround most (if not all) of the problem.  I'm thinking something like the below.  Note that this would only allow you to get to 32 bit encoders (because then bissc_data_struct.position becomes a limiting factor).  Also note that I have not tested the below code - it is instead meant to give you an idea of what would be needed - largely because I don't have an encoder that has this much resolution handy :).

uint16_t bissc_receivePosition(uint16_t positionBits, uint16_t crcBits)
{
    uint16_t scdBitsParsed = 1;  //start with 1, we don't need to parse the start bit
    uint16_t crcResult = 0xFFFF;
    uint16_t mask = 0xFFFF;
    uint16_t receiveSuccessful = 0xFFFF;
    uint16_t numWordsPosCrc = 0;
    uint64_t scdRawWorkaround = 0;

    if(bissc_data_struct.cd_status == 1)
    {
        //if CD stream is active, receive CDS bits
        bissc_data_struct.cds_stream = bissc_data_struct.cds_stream << 1;
        bissc_data_struct.cds_stream |= PM_bissc_getBits(1, scdBitsParsed, SPI_FIFO_WIDTH);
    }
    scdBitsParsed++;  //we've now parsed the CDS bit (or didn't need to)

    //CRC is run on position + E + W, parse all these bits as one
    scdRawWorkaround = PM_bissc_getBits(positionBits+2-16, scdBitsParsed, SPI_FIFO_WIDTH)<<8;
    scdRawWorkaround = scdRawWorkaround<<8;   // may not NEED to split into two shifts
    scdBitsParsed = scdBitsParsed + positionBits + 2 - 16;
    scdRawWorkaround = scdRawWorkaround + PM_bissc_getBits(positionBits+2, scdBitsParsed, SPI_FIFO_WIDTH);
    scdBitsParsed = scdBitsParsed + 16;  //positionBits + E + W

    bissc_data_struct.scd_crc = PM_bissc_getBits(crcBits, scdBitsParsed, SPI_FIFO_WIDTH);

    //change the amount of words the CRC will run based on the amount of bits
    numWordsPosCrc = ((positionBits+2)/8)+1;

    crcResult =  PM_bissc_getCRC(0, positionBits+2, BISS_SCD_CRC_NBITS_POLY1, (uint16_t *)&scdRawWorkaround, bissCRCtableSCD, numWordsPosCrc);

    mask = (1 << crcBits) - 1;

    if(crcResult == ((~bissc_data_struct.scd_crc) & mask))
    {
        //crc was correct, so lets populate the following
        bissc_data_struct.scd_error = (~scdRawWorkaround) & 0x00000001;
        bissc_data_struct.scd_warning = ((~scdRawWorkaround) & 0x00000002) >> 1;
        bissc_data_struct.position = scdRawWorkaround >> 2;
        receiveSuccessful = 1;
    }
    else
    {
        receiveSuccessful = 0;
        bissc_data_struct.crc_incorrect_count++;
    }

    return(receiveSuccessful);
}

Hopefully this helps,
Brett

Other thoughts based on your results:

1. If you're debugging your setup with the complicated IDDK code, I might recommend starting with the simpler bissc example project.  It can be found at the below.  You can then use what you've learned and put it into the IDDK project once you get everything right.
   \controlSUITE\libs\app_libs\position_manager\
   
   
2. Something odd is going on or I'm misinterpreting the data you wrote (in your 15Apr 10:38PM CST post).  For example, if you've set BISS_POSITION_BITS to 32 then numWordsCrc should not end up as 0.
   
   
3. Based on the code I put in my last post, you could follow the below process to help prove the code is working.
   
   1. put the scdRawWorkaround variable into the watch window and change its type to Hex or Bin by clicking in the watch window.  As you rotate your encoder and view the variable, you should see all the 32 bits flip.
   2. similarly, assuming a 6bit CRC, you should see all 6 of the .scd_crc variable's bits flip as you rotate.
   3. Next you can see if crcResult and bissc_data_struct.scd_crc match. 
   4. Etc.

Let us know if you get stuck along the way.


Thanks,
Brett

Hi Brent,

It is good that you were able to get the SystemTest example working.  (and I assume you weren't seeing crc_incorrect_count increment in this project)

===

Keep in mind that, in the IDDK project, the encoder is getting queried for new position data at the ISR frequency (10KHz).  This means that if you are only seeing crc_incorrect_count slowly increase, the errors are actually quite rare. (and this explains the breakpoint behavior you are reporting)

Some thoughts:
1) Does the specification of your encoder enable speeds of 2MHz?  If not, I can see how a project with no noise (like SystemTest) may have worked while a noisier system might fail.
2) Because of the above (or just because of noise in general), I might recommend trying to run the BiSS encoder interface at 1MHz to see what happens by increasing BISS_FREQ_DIVIDER. 
3) How long is the cabling between your encoder from the IDDK board? 
(it is theoretically possible that the time taken to do the encoder communication is long enough that meeting the 10KHz sampling time is no longer feasible.  I don't think this is what you are seeing though)


Thank you,
Brett

Hi Brent,

Notes:
Delay compensation is directly built into the BiSS PM solution you are using.  Do note that, while the PM solution itself can handle high frequency at long cable lengths, the cable length will still have an effect on the time between when the C2000 sends out clocks and begins to receive data.  As a result, latency and back-to-back sampling capabilities are effected by longer cable lengths (there is a transit time, if you will).

Thoughts on experiments:

• Noise may very well be part or all of the problem and better shielding may very well help this.
  (it is odd that reducing the clock frequency is increasing the rate of problems; so this may not be all there is to your issue)
• Just to confirm, when you run the SystemTest project, do you ever see any errors at any of the BISS_FREQ_DIVIDER choices that you experimented with?
• The big difference between SystemTest project and the IDDK project is that the IDDK project is now imposing a 10kHz limit on the transaction.
  • Assuming that the SystemTest project works fully, I wonder what would happen if the PWM/ISR frequency was reduced to 5kHz.  The IDDK software will then only try to get new data from the encoder at half the speed it is currently.  This will provide more headroom for the system.
    (I'm also wondering if the workaround, and its usage of 64bit variables, has increased the amount of cycles being run in the bissc_receivePosition function - optimizations could be made in the workaround if desired)
  • You may want to experiment with increasing the frequency of the BiSS transaction - maybe to ~3-4MHz.  The rationale here is similar to the experiment above. 

Thank you,
Brett

Brett, thanks for the quick response.

The system test project works with no errors at 2 MHz. I'll try some other frequencies soon.

I increased the frequency of the  IDDK project to 3, 4, 5, 6 and 8 MHz. The crc error rate went down steadily as I went to 6 MHz. At 8 MHz there was huge increase in error rate.  I changed freq back to 2 MHz and set breakpoint at CRC failure section and noticed that about 2/3 of the time the scd_crc was 0 and the crcResult was normal. The rawWorkaround would have correspondingly large  strings of 0s toward the lsb.

I'll send result of 5kHz update rate soon.Thanks, Brent.

Brett,

Here's some more info. Biss System Test works with no errors from 250kHz to 7MHz. Substantial amount of CRC errors starting at 8MHz.

IDDK project shows similar error rate at 10kHz, 5kHz and 1kHz pwm/sampling rate.

Thanks for your continued help, Brent 

Brent,

I'll continue to brainstorm with some of the members in my team.

When running BiSS on the IDDK project, are you also running the motor?  Is HV DC power connected?  Are there positions in the encoder's physical range which demonstrate higher-error rates?

FYI: the PM interface on the device will be able to run at a maximum speed of 8MHz (as mentioned in the documentation) - so what you are seeing is expected.


Thank you,
Brett

Hi Brett,

Good news. I have the biss-c code working in the IDDK project without errors. The residual errors I was seeing was apparently due to a corrupted debug configuration file which I found was causing glitches when I went back to run the QEP module. I am going to start tuning the new motor with the biss-c feedback. I may need some help with that if I get stuck but I consider the biss-c interface assistance complete.

Thank you so much for all your help and thanks to Bharathi as well,

Brent

Hi Brent,

That's great news.

By debug configuration file, do you mean the target configuration .ccxml? 
(just trying to better understand in case this is to come up again)


Thank you,
Brett