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.

TMS320F28388D: ESM EEPROM initialization unstable in F28388

Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE

Tool/software:

customer develop Ethercat function base on F28388, and meet ESM EEPROM initialization unstable issue, below is the I2C waveform and initialization code, appreciate double review if any setting wrong?

-  Below is waveform for EEPROM initialization ok, will send 4 bytes 0xFF and initialization return passed, then could continue I2C normal communication, successful rate is around 8 of 10 times.  

-  Below is waveform for EEPROM initialization fail, will send 16 bytes 0xFF and repeat this behavior, finally initialization return failed and cannot go forward for normal communication, fail rate is around 2 of 10 times.

- Below is the initialization code

initialization code.docx

  • Hi Terry, 

    Since this is using the CM core for the ECAT, which examples from our C2000WARE SDK have they leveraged to build their initialization firmware? We have multiple examples showcasing this

    Regards,

    Peter

  • Hi Terry,

    I cannot see the logic analyzer waveforms  / data in the fail case well. Is slave address and data bytes getting ACKed?

    Are you able to tell if issue is with F2838x Master or EEPROM slave device from the logic analyzer?

    Best,

    Kevin

  • Yes, customer initialization firmware is almost same with C2000WARE SDK example, just few parameter in API is difference, I am not sure if it will cause the issue and would like get your review.

  • this is the more detail waveform for fail case, the salve address and data byte has got the ACKed, so I guess the abnormal behavior maybe come from F28388?

  • Hi Terry,

    Are they allocating the ESC to CPU1 or CM core? Can they verify they are following corresponding SW init sequence below? Also, can you tell me if this EEPROM comms issue is occurring during EEPROM loading or some other time?

    Best,

    Kevin

  • Hi Kevin

    Thanks your advice, customer allocate the ESC to CM core, they follow the sequence as below in their firmware but sometime meet the above issue. 

    However they try exchange the step 3 and 4, do the configure CM clock at first, then allocate ESC to CM, found the issue is disappear.  Do you think if exchange step 3 and 4 is ok? 

  • Hi Terry,

    Below is what we have in our C2000WARE f2838x_cpu1_allocate_ecat_to_cm example.

        //
        // Setup AUX Clock for ECAT and CM
        // Configured to 500MHz raw ((25 * 20 IMULT) /1)
        //
        SysCtl_setAuxClock(SYSCTL_AUXPLL_ENABLE | SYSCTL_AUXPLL_OSCSRC_XTAL |
                           SYSCTL_AUXPLL_IMULT(20) | SYSCTL_AUXPLL_FMULT_0 |
                           SYSCTL_AUXPLL_DIV_1);
    
        //
        // Setup GPIOs for EtherCAT
        //
        setupESCGPIOs();
    
        //
        // Allocate Ethercat to CM
        //
        SysCtl_allocateSharedPeripheral(SYSCTL_PALLOCATE_ETHERCAT,
                                        ALLOCATE_TO_CM);
    
        //
        // Setup CM clocks and release from reset to Wait Boot Mode
        //
        configureAndReleaseCMToWait();

    However I noticed in our newer P65x device the CPU eCAT flow is below, where allocating ESC to CPU2 is the last steps on CPU1. I think that's probably a better procedure. We'll need to look into potentially updating the F2838x ESC TRM table.

    Best,

    Kevin