This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MCF8316A: CRC Not matching

Part Number: MCF8316A

Hello,

Recently I have been testing out the MCF8316A, and whenever i encountered an issue i was mainly able to find it throughout the forums, but this is an issue I am struggling to find much information on.

I am using the evaluation module kit (MCF8316AEVM) with external MC (an Arduino) and i have successfully wrote and read from the registers and wrote the registers to the EEPROM, so communication is established (all of this with CRC disabled).

It was when I was writing the speed and reading it (using I2C), and for the most part it would work and be accurate, but sometimes it would stop communicating properly and either wouldn't write the new speed or read a full register, or sometimes full register (aka reading FG_SPEED_FDBK gives me a value of 0xFFFFFFFF). I am aware of the errata with reading registers whist giving speed control using I2C, but shouldn't it be fine to read the register that is meant to be read whilst the motor is running, at least once every second? At least this was my train of thought, so I presumed that because i am not just re-writing the register with the new speed, but rather I am incrementing the DIGITAL_SPEED_CTRL register with a value of 0x06630000 (5% max speed), there was some corruption between the communication and wanted to implement the CRC to make sure the data stream is correct.

I implemented a CRC calculation in my code, and using online calculators i made sure that my results are correct and I am writing or reading the correct CRC value. When reading the MCF for CRC value for a certain data, though, i am getting a completely other value, that doesn't show up in any of the CRC8 algorithms. Now, i came across this forum article: https://e2e.ti.com/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1120366/mcf8316a-cannot-clear-faults, and it does state that it is a custom CRC8, but the initial value and polynomial are the same as the ROHC, so i am using the ROHC look-up table.

Just to confirm the way to structure the CRC with example values of reading 0x440FCEC6 to the MOTOR_STARTUP1 register (0x84)

1) 0x02

2) 0xD0, 0x00, 0x84

3) 0x03 (since datasheet asks for + read bit)

4) 0x44, 0x0F, 0xCE, 0xC6

The calculated result is 0x13 and the value i am reading is 0x20

Is this the right order of doing it? I have also tried on 4) 0xC6, 0xCE, 0x0F, 0x44 , which i calculated to be 0x5D, which is still not the same as the 20 that i am getting from the MCF.

I would really appreciate it if someone could give some insight on why the motor speed write and read possibly bugging out, and the way the MCF calculates the CRC.

Thanks in advance!

Kind regards,

Jordan

  • Hi Jordan,

    We will need some time to look into this. I will aim to get you a response by December 1st at the latest.

    Regards,

    Joshua

  • Hi Jordan,

    For the CRC calculation, using this CRC calculator in CRC-8-ROHC mode: https://www.lddgo.net/en/encrypt/crc I was able to also get 0x5D when inputting "0x02 0xD0 0x00 0x84 0x03 0xc6 0xce 0x0f 0x44" which is how the MCF8316A will receive the data. This CRC-8-ROHC mode has settings "REFIN" and "REFOUT"

    Using the calculator from the linked E2E post: http://www.sunshine2k.de/coding/javascript/crc/crc_js.html and checking "Input reflected" and "Result reflected", on top of custom CRC-8 and initial value 0xFF, I as able to also get 0x5D as the result. The MCF8316A does not reflect the input or result in its CRC calculation, so without "Input reflected" and "Result reflected" checked I did get the result 0x20.

    I would really appreciate it if someone could give some insight on why the motor speed write and read possibly bugging out

    The I2C errata for the MCF8316A will cause the algorithm of the motor driver to get stuck. If the motor driver stops communication totally and only corrects with a power cycle, then unfortunately you are likely experiencing the errata. The only way to guarantee that the errata will not happen is to not communicate over I2C while the motor is operating. The MCF8316C-Q1 does not have this errata and is pin-to-pin compatible with the MCF8316A, if you require a similar device that can be communicated over I2C during motor operation.

    Regards,

    Joshua

  • Hi Joshua, thanks for coming back to me.

    Ah i see, i am quite new to CRC (this is the first time i have encountered it), so i did not even realize that there were "REFIN" and "REFOUT"settings. Something to look into now!

    As for the communication error i thought as much.

    In either case thank you for the info, got some food for thought for now Slight smile

    I will mark it as issue resolved and if something else comes up I will open a new thread.