• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 30 subscribers
  • Views 68 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MCF8315D: Several questions during EEPROM write/read on MCF8315D

Ernest Cho
Expert 3311 points
Part Number: MCF8315D


Hi team,

My customer is implementing I2C communication for EEPROM and has some questions.

  1. For parity bit, it seems to be different to handle than MCF831xC version. (Datasheet added parity parts)
    It seems that customer have to input the parity bit before writing, and this is even parity. Is it correct?
  2.  Datasheet specified as below and it specified "parity issued at read command". Does this "read" mean that once I write EEPROM with wrong parity then read EEPROM again?
    And is it also the same result when I write(with wrong parity) and read in the shadow register?
    6.3.24.12 EEPROM Fault
    MCF8315D provides an EEPROM fault detection feature to prevent device operation when there is EEPROM data mismatch due to an interrupted EEPROM write (UVLO during EEPROM write), EEPROM aging etc., MCF8315D implements a CRC and parity check whenever an EEPROM read command is issued - if there is a CRC or parity mismatch, an EEPROM fault is recognized and action taken according to EEP_FAULT_MODE.
  3. Could you explain what are the reason for address 0xEA(ALGO_CTRL1) are not reset to 0x0 after the read or write command issued with pretty long wait(200ms, 1s accordingly)? (my customer case, sometimes reset to 0x0 but not clear 0x0 for the other. They are not using CRC byte yet)
  4. Sometimes customer tried to run the motor via I2C, but 0x18E(ALGORITHM_STATE) stayed at MOTOR_ISD and do not go to next state. Do you know what is the reason?

Thank you.

Ernest Cho

  • +1
    TI__Mastermind 27367 points

    Hi Ernest,

    Answer to Question 1:

    The parity bit is calculated by the device; this is read-only for the end user.

    For MCF8316C, these bits are reserved, and for MCF8315D/16D, parity is calculated by the device for the values written by the application.

    Let me provide a short description below:

      a. Parity: This bit is calculated for every word, and the 31st bit will be updated with the parity of the word in the EEPROM. The application cannot write this; the device EEPROM controller calculates the PARITY and writes it.

     b. CRC of EEPROM: The application is not required to calculate CRC. The device calculates CRC for all the registers, and the device internally stores the CRC when an EEPROM write command is issued. Hence, whenever an EEPROM read command is issued, the device verifies Parity and CRC, and if there is any mismatch, a fault will be reported.

    Answer to Question 2: The explanation for question 1 is applicable to this as well.

    Answer to Question 3: This indicates EEPROM writes are not successful or EEPROM write action is gated. The reasons are:

    1. The device is not in IDLE state or Latched Fault state (If Fault state is in retry mode, EEPROM writes can be interrupted)

    2. When VM drops below UVLO before EEPROM write is completed

    3. When the delay is less than recommended (750ms) and the device goes through a power cycle, or the device is out of IDLE state due to a speed command or recovery from Fault state

    The underlying requirement is that the device should not be spinning the motor; in that condition, EEPROM writes/reads will be ignored. Please refer to the application note.

    : MCF83xx and MCT83xx EEPROM Read and Write Procedure

    Anwer to Question4:

    MOTOR_ISD can be in ISD brake state, and brake time can be longer.

    We need more observation to confirm the exact condition. Can you get the motor specifications and JSON files to review? Did they try the Smart Tune feature?

    Thanks and Best regards

    Venkatadri S