• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 594 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28379S: No INIT 2 PREOP command from ET1100 after power on

Yiu Hang Li
Intellectual 460 points
Part Number: TMS320F28379S
Other Parts Discussed in Thread: TMDSECATCNCD379D, CONTROLSUITE

Hi there,

We are experiencing a wired problem.

We are testing our new board, after it is powered on and master start to initialize ethercat comm., MCU need to wait for at least 20s before receiving INIT 2 PREOP command (AL control event ET1100 offset 0x220) from ET1100.

The wait time seems random, sometimes even ~2 minutes.

It feels like ET1100 keep resetting itself. (since MCU can’t even receive INIT to PREOP command, or in other word EMIF read back nothing)

We managed to find a temporary solution - after power on, MCU stay idle for ~2s before MCU reset ET1100 again.

This problem only happened when MCU boot from flash, no such problem when using RAM.

The same problem can’t be replicate on our TI TMDSECATCNCD379D. So it is probably a hardware problem.

But we can’t figure out the cause.

We have tried to measure the signal in pin to ET1100 reset (RESn) with oscilloscope, the signal seems normal. (only set low when MCU tried to reset it during initialization, then it always stay high afterward)

We would like to know what may cause ET1100 behave in such way? Or have you experience any similar porblem?

Best Regards,
Thomas Li

  • 0
    TI__Genius 10845 points

    Hi,
    This query has been assigned to the experts. Due to the US Holiday on 25/05, please expect reply by 26/05 US time.

    Thanks
    Vasudha

  • 0
    Intellectual 460 points

    Update to the problem:

    1. The waiting time is even worse on other boards, it seems the wait time will varied from baord to board.

    2. Without waiting, EEPROM loaded check by MCU will passed (by checking ET1100 EEPROM_LOADED), but the subsequent read from ET1100 ESC_PDI_CONTROL_OFFSET (0x0140) will return all 0

    3. Every time flashing ET1100 EEPROM on a brand new board will fail. SSC tool's EEPROM programmer will return success and have wrote ~8500 packets. But fail when tried to establish comm. Only after power off and on again the flashing process will succed (by seeing the programmer return it have wrote 7445 packet)

  • 0 in reply to Yiu Hang Li
    TI__Mastermind 30255 points

    Hello

    I recommend posting to the ETG forums. They are the best experts with ET1100 to assist.

    If you are trying to do similar to TMDSECATCNCD379D, then if you haven't already, there are design files to reference in controlSUITE.

    Best regards

    Chris

  • 0 in reply to Christopher Chiarella
    Intellectual 460 points

    Thanks Christopher , I will bring this problem to ETG forum. We have tried that on TMDSECATCNCD379D, none of the porblems mentioned aboved happened.

    Meanwhile we got another question would love ur opinions on. With more testing yesterday, we suspect it may not be matters related to ET1100 after all. Is there any way booting from flash affect EMIF r/w?

    There is a dedicated pin on ET1100 to inform MCU it is ready to communicate (EEPROM_LOADED). The reading from that pin is expected to be high and indeed it is (at least read from MCU).

    Right after this pin test, with a little delay, we program the MCU is programmed to read out some hard wired constants from ET1100 (model number and RAM size) and check do they match expected value. But all read outs return wrong, doesn't match what's listed on ET1100 data sheet. What's more, this only happened when cold boot from flash! (not even from TI CCS, just power on). When repeat the same test with booting from RAM through TI CCS the readout are completely fine! We didn't even add breakpoint, the value match test is programmed to turn on a LED if passed. 

    If ET1100's EEPROM_LOADED pin is correct, we can only suspect booting from flash somehow affect MCU's EMIF. But how is it possible?

  • 0 in reply to Yiu Hang Li
    TI__Mastermind 30255 points

    Hello

    Booting from flash won't affect EMIF behavior.  TMDSECATCNCD379D solution works from RAM and Flash without issue. I recommend checking your EMIF code flow against that example code.

    Is something being run before the RAM case? Can you detail the flow you test follow for each RAM/Flash? How's the ET1100 data being checked on MCU?

    Best regards

    Chris

  • 0 in reply to Christopher Chiarella
    Intellectual 460 points

    Hi Christopher,

    Thanks for the advise we will check against the example code later.

    Not sure what u mean, it is running the program last flashed on it. The program from RAM and from flash are identical.

    Test are identical for both RAM and flash. Our board have 2 LEDs. First if ET1100's EEPROM_LOADED pin is high, MCU will set a LED on. Then MCU read some ET1100 registers through EMIF. These register's value are hard wired on ET1100 (like model number, RAM size) and their values are known beforehand from ET1100 datasheet. If EMIF is working correctly return value should match datasheet's value. MCU is programmed to set the other LED on if they are matched. 

    When run from RAM or run from flash but through TI CCS both LEDs always on. But when cold boot from flash only EEPROM_LOADED LED is on, the value check LED always fail. 

  • 0 in reply to Yiu Hang Li
    TI__Mastermind 30255 points

    Hello

    Alright, I see. Not sure what would change when doing cold boot.

    Make sure there isn't any variables that aren't initialized.

    Also, might want to add an infinite loop and then connect to the device (with modified target configuration without GEL to avoid device reset, remove from the advanced settings) in the case of the cold boot. Observe and compare the EMIF configuration registers to the working case.

    Best regards

    Chris

  • 0 in reply to Christopher Chiarella
    Intellectual 460 points

    Thanks Chris, we will look into it later. We have never tried to connect to MCU with TI CCS midway, will have to look into it. Are working on other areas for now. I will post an update if anything comes up.

    Not much come up with code comparison. I did remove one line for Emif1ConfigRegs.EMIF1MSEL in etherCAT_slave_c28x_hal.c. But this is necessary for changing from duo core to single core.

  • 0 in reply to Christopher Chiarella
    Intellectual 460 points

    Also mind if u can provide more detail on how to connect to cold boot device? Thanks.

  • 0 in reply to Yiu Hang Li
    TI__Mastermind 30255 points

    Hello

    Sure. So when connecting to device (that was initially running standalone), you want to edit the target configuration file first. In CCS, open the target configuration file, go to the advanced tab, click on CPU1 and for each clear out the path to the GEL file. This was when you connect, you don't reset the device, it will just halt where it currently is.

    Best regards

    Chris

  • 0 in reply to Christopher Chiarella
    Intellectual 460 points

    Hi Chris,

    We figure it out. Turn out is just bad solder on ET1100. The problem gone when heat it up with a heat gun. And it just so happened all prototype board suffer the same problem. Thanks for your help.

    Best Regards,

    Thomas Li

  • 0
    Intellectual 460 points

    We really crack the problem this time! It's not a solder problrm. Turn out is a GPIO config. problem.

    We are connecting GPIO94 to ET1100's EMIF address 15 pin and GPIO94 is not configured when using setup_emif1_pinmux_async_16bit_option2(). So when startup GPIO94 is probably giving logic high voltage hence mess up EMIF's address and ET1100 was r/w the wrong adderess and return wrong reading all along! The problem solved when GPIO94 is configure as GPIO and gives logic low voltage. 

    One question though, what happened when GPIO is set to MUX position that is undefined? Because we were rushing, we set GPIO 94 to MUX positon 2 just to test it out and it work. But on data sheet, GPIO 94 MUX position 2 is undefined. 

  • 0 in reply to Yiu Hang Li
    TI__Mastermind 30255 points

    Thomas

    Glad to hear you've resolved the issue!

    If you select a reserved GPIO mux configuration that is not mapped to either a peripheral or GPIO mode, the state of the pin will be undefined and the pin may be driven.

    Best regards

    Chris