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.

MCF8329A: I2C Read Write operation

Part Number: MCF8329A

Tool/software:

"Hello,

I have a few questions.

  1. Currently, I am controlling the motor using I2C. I understand that if I input values into the shadow register, they are written to the RAM area, and then by writing 0x8A500000 to the 0xEA register, the values in the shadow register from 0x000080 to 0x0000AE are written to the EEPROM. Is this correct?

  2. It is mentioned to allow about 100µs of stabilization time after writing to the shadow register. However, it takes about 1ms for the values to be properly written. Is this delay of around 1ms actually required for stable writes? And what exactly does this 100µs delay refer to?

  3. For the read option, if I write 0x40000000 to the 0xEA register, the data from EEPROM is loaded into the shadow register (from 0x000080 to 0x0000AE). Is this correct? I put arbitrary values into the shadow register and performed the read operation, but the values in the shadow register did not change, which is why I’m asking.

  4. Lastly, in some other EEPROMs, I noticed the ability to read multiple registers consecutively. Does the MCF8329A support this function? If not, when I want to read the values from the EEPROM, do I need to read each shadow register value one by one after startup?

Thank you."

  • Hi 

    Quick clarification for the 1st question, yes your understanding is correct.

    I will provide brief document (steps) for EEPROM Reading and writing procedure by tomorrow.

    Thanks and Best Regards

    Venkatadri S

  • "Thank you for your kind response. I will make sure to click the 'Resolved' button once the answers to my other questions are completed."
  • Hi

    1. Currently, I am controlling the motor using I2C. I understand that if I input values into the shadow register, they are written to the RAM area, and then by writing 0x8A500000 to the 0xEA register, the values in the shadow register from 0x000080 to 0x0000AE are written to the EEPROM. Is this correct?

      [ANS] Yes correct, also monitor for 0xEA will become zero after successful completion of EEPROM writing.
    2. It is mentioned to allow about 100µs of stabilization time after writing to the shadow register. However, it takes about 1ms for the values to be properly written. Is this delay of around 1ms actually required for stable writes? And what exactly does this 100µs delay refer to?

      [ANS] The delay is required during I2C communication. Wait time of 100us is needed during I2C transaction between each byte transmitted. 
    3. For the read option, if I write 0x40000000 to the 0xEA register, the data from EEPROM is loaded into the shadow register (from 0x000080 to 0x0000AE). Is this correct? I put arbitrary values into the shadow register and performed the read operation, but the values in the shadow register did not change, which is why I’m asking.

      [ANS] Shadow register value are updated once at power up from the EEPROM, after that user may have changed for tuning purpose, hence EEPROM will be updated only for those registers which are not updated by user.
    4. Lastly, in some other EEPROMs, I noticed the ability to read multiple registers consecutively. Does the MCF8329A support this function? If not, when I want to read the values from the EEPROM, do I need to read each shadow register value one by one after startup?

      [ANS] We have to address each register individually and read.

    Please make sure to follow below listed procedure for successful programing of EEPROM

    1. Up on power up write 0x80000000 word value to register 0xEC (ALGO_DEBUG1). This enables speed command OVERRIDE (Bit 31) .This word also ensures zero speed command is written so that Motor is in MOTOR IDLE state. In this state EEPROM writes will be successful.
    2. After step 1 start sending rest of the tuning registers via I2C. Maintain interbyte delay of 100us
    3. After all register data transfer to device via I2C completed, read back the data and verify
    4. Now issue EEPROM write command 0x8A500000 to the register 0xEA(ALGO_CTRL1)
    5. Wait for 750ms
    6. Read back 0xEA and ensure values in 0xEA are automatically cleared after successful EEPROM programming.
    7. Do no power off until 0xEA values have become zero.
    8. Once 0xEA gets cleared power cycle the board and re check by reading the content

    Example of using Interbyte delay while communicating on I2C

    • Every Frame starts with 4 byte

    –1st Byte [Target Address[7:1] : R/W[0]]

    • Wait for 100uS

    –CONTROL WORD 0 [OP_R/W[7]:CRC_EN[6]:DLEN[5:4]:MEM_SEC[3:0]]  ->Total 8 bits

    • Wait for 100uS

    –CONTROL WORD 1 [MEM_PAGE[8:5]:MEM_ADDR[3:0]]

    • Wait for 100uS

    –CONTROL WORD 2 [MEM_ADDR[7:0]]  //  Example  if we want to address 0x80 ISD_CONFIG write 0x80 here

    • Wait for 100uS

    Thanks and Best Regards

    Venkatadri S

  • "Thank you for your response. After checking, it appears that the 100µs delay in the driver section is implemented correctly. Currently, I am accessing the shadow register by sending 32 bits at once. The protocol I use for writing data to the 0x80 address is as follows: {0x10, 0x00, 0x80, 0x00, 0x00, 0x00, 0x44}. After this, when writing data to the 0x82 address, it seems necessary to include a delay of approximately 1ms between 0x80 and 0x82 to ensure proper operation. Could you explain this in more detail? I need to read the values of 3 shadow registers within a 10ms task, and I’m wondering if it’s correct to include a 1ms delay between each request.

    Example: The protocol I use for writing: I send {0x10, 0x00, 0x80, 0x00, 0x00, 0x00, 0x44}, wait for 1ms
                    then send {0x10, 0x00, 0x82, 0x02, 0x18, 0x94, 0x19}

                    The protocol I use for reading: I send {0x90, 0x00, 0x80, 0x00, 0x00, 0x00, 0x00}, wait for 1ms
                    and then receive 4 bytes to {0x00, 0x00, 0x00, 0x00}."

  • Hi

    After sending the frame device has to parse the data for R/W, verify if CRC is enabled then it has to be computed etc. Hence delay will be needed between each frame.

    You need to adjust your scheduler to accommodate the delays needed. 

    Thanks and Best Regards

    Venkatadri S