TMS320F28388D: the AL status code is '0x001b' - sync manager watchdog

Hi,

Can you clarify if this is seen with a TI provided example? Also, is this on a ControlCARD or some other HW platform? Can you also clarify what does "exit debug mode" mean?

The SM watchdog is triggered as there is no successful PD communication and slave move to SAFEOP state. Usually the default timeout is 100ms.

Thanks,

It's not  TI provided example, and application runs  on TI  ControlCARD . "exit debug mode"means power on the Control CARD again(at this moment ,ccs can't debug the application ).I change the 0->s time to 500ms,but it's unsuccessful.  I have change the boot mode to zero boot , I don't known whether the zeros boot mode has effect on the issue.,because before i change the boot mode, the application is ok ,

Hi,

From your description, I infer that the issue is happening when you boot from flash in a standalone manner without debugger connected. And the issue seem to be not present when you boot from RAM with debugger support. Can you please follow the guideline mentioned below on how to convert a RAM configuration to flash and see if that helps?

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/878674/faq-flash---how-to-modify-an-application-from-ram-configuration-to-flash-configuration

Thanks,

Hi: I have verified your solution,and the issue is also exit.  this is my zero boot mode configuration with syscfg tool :

ZONE2 is not selected. I am sure ethercat's '0x001b'- sync manager watchdog' issue is leaded by the zero boot mode ,because I set three card to zeros boot mode and they can't work normal('0x001b'- sync manager watchdog),and other two card didn't , they can work normal.(.out and .bin that is sent to ethercat eeprom are all the same )

Hi,

We will have one of our DCSM experts look  into this issue and get back.

Thanks,

Hi Ranjith:

The above one is my customer. His current situation is that other programs such as CAN, SPI, I2C can run normally under the flash & 0 boot pin mode. But only the EtherCAT program has a problem (error: 0x001b'- sync manager watchdog). And the same program can run normally in flash &non-zero pin mode.

Therefore, he doubts whether the EtherCAT error is related to the 0 pin boot mode.

Best regards

Hi Deng,

0-boot pin configuration and flash boot are same so it should really not matter. Also since you have SCI/CAN and other peripheral working with 0-boot pin configuration, your settings should be fine.

On the boards where you are using flash boot, are you using default bootpins (GPIO72/GPIO84) ? If yes, then I see these pins are muxed with some of EtherCAT function as well. Are you using EtherCAT function on these pins ? Also on the boards where you are configuring 0-bootpin, do you still have pulls on GPIO72/GPIO84 pins (assuming those are boot pins on other boards). I am basically trying to see if there is any difference in board setup apart from 0-bootpin configuration.

Regards,

Vivek Singh

Hi Vivek and Deng: 

Pin of ethercat  function  are as follow:

GPIO72/GPIO84 are not used by ethercat  function.the board that is set to 0-boot mode ,pin GPIO72/GPIO84 are not pulled up.

the three board are bought from TI, it seems no difference in board setup apart from 0-bootpin configuration. 

//
// Configure GPIOs for ECAT
//

//
// PHY CLK
//
GPIO_setPinConfig(GPIO_154_ESC_PHY_CLK);

//
// PHY Reset
//GPIO_setPinConfig(GPIO_155_ESC_PHY_RESETN);

//
// I2C for EEPROM
//
GPIO_setPinConfig(GPIO_150_ESC_I2C_SDA);
GPIO_setQualificationMode(150, GPIO_QUAL_ASYNC);
GPIO_setPadConfig(150, GPIO_PIN_TYPE_PULLUP);
GPIO_setPinConfig(GPIO_151_ESC_I2C_SCL);
GPIO_setQualificationMode(151, GPIO_QUAL_ASYNC);
GPIO_setPadConfig(151, GPIO_PIN_TYPE_PULLUP);

//
// P0 TX and RX DATA
//
GPIO_setPinConfig(GPIO_158_ESC_TX0_DATA0);
GPIO_setQualificationMode(158, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_159_ESC_TX0_DATA1);
GPIO_setPinConfig(GPIO_160_ESC_TX0_DATA2);
GPIO_setQualificationMode(160, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_161_ESC_TX0_DATA3);
GPIO_setQualificationMode(161, GPIO_QUAL_ASYNC);

GPIO_setPinConfig(GPIO_165_ESC_RX0_DATA0);
GPIO_setQualificationMode(165, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_166_ESC_RX0_DATA1);
GPIO_setQualificationMode(166, GPIO_QUAL_ASYNC);

GPIO_setPinConfig(GPIO_167_ESC_RX0_DATA2);
GPIO_setQualificationMode(167, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_168_ESC_RX0_DATA3);
GPIO_setQualificationMode(168, GPIO_QUAL_ASYNC);

//
// P0 TX Enable, RX DV, RX ERR
//
GPIO_setPinConfig(GPIO_156_ESC_TX0_ENA);
GPIO_setQualificationMode(156, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_162_ESC_RX0_DV);

GPIO_setQualificationMode(162, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_164_ESC_RX0_ERR);
GPIO_setPadConfig(164, GPIO_PIN_TYPE_STD);

//
// P0 TX and RX Clk
//
GPIO_setPinConfig(GPIO_157_ESC_TX0_CLK);
GPIO_setQualificationMode(157, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_163_ESC_RX0_CLK);
 GPIO_setQualificationMode(163, GPIO_QUAL_ASYNC);

//
// P0 Linkstatus and Link Active LED
//
GPIO_setPinConfig(GPIO_148_ESC_PHY0_LINKSTATUS);
GPIO_setPadConfig(148, GPIO_PIN_TYPE_STD);

GPIO_setPinConfig(GPIO_143_ESC_LED_LINK0_ACTIVE);
GPIO_setQualificationMode(143, GPIO_QUAL_ASYNC);
GPIO_setPadConfig(143, GPIO_PIN_TYPE_INVERT);

//
// P0+P1 MDIO CLK and Data
//
GPIO_setPinConfig(GPIO_152_ESC_MDIO_CLK);
GPIO_setPinConfig(GPIO_153_ESC_MDIO_DATA);

//
// P1 TX and RX DATA
//
GPIO_setPinConfig(GPIO_131_ESC_TX1_DATA0);
GPIO_setQualificationMode(131, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_132_ESC_TX1_DATA1);
GPIO_setQualificationMode(132, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_134_ESC_TX1_DATA2);
GPIO_setQualificationMode(134, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_135_ESC_TX1_DATA3);

GPIO_setQualificationMode(135, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_139_ESC_RX1_DATA0);
GPIO_setQualificationMode(139, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_140_ESC_RX1_DATA1);

GPIO_setQualificationMode(140, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_141_ESC_RX1_DATA2);
GPIO_setQualificationMode(141, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_142_ESC_RX1_DATA3);

GPIO_setQualificationMode(142, GPIO_QUAL_ASYNC);

//
// P1 TX Enable, RX DV, RX ERR
//
GPIO_setPinConfig(GPIO_129_ESC_TX1_ENA);
GPIO_setQualificationMode(129, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_136_ESC_RX1_DV);

GPIO_setQualificationMode(136, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_138_ESC_RX1_ERR);
GPIO_setPadConfig(138, GPIO_PIN_TYPE_STD);

//
// P1 TX and RX Clk
//
GPIO_setPinConfig(GPIO_130_ESC_TX1_CLK);
GPIO_setQualificationMode(130, GPIO_QUAL_ASYNC);
GPIO_setPinConfig(GPIO_137_ESC_RX1_CLK);
 GPIO_setQualificationMode(137, GPIO_QUAL_ASYNC);

//
// P1 Linkstatus and Link Active LED
//
GPIO_setPinConfig(GPIO_149_ESC_PHY1_LINKSTATUS);
GPIO_setPadConfig(149, GPIO_PIN_TYPE_PULLUP);
GPIO_setPinConfig(GPIO_144_ESC_LED_LINK1_ACTIVE);
GPIO_setQualificationMode(144, GPIO_QUAL_ASYNC);
GPIO_setPadConfig(144, GPIO_PIN_TYPE_INVERT);

GPIO_setPinConfig(GPIO_125_ESC_LATCH0);
GPIO_setPinConfig(GPIO_126_ESC_LATCH1);
GPIO_setPinConfig(GPIO_127_ESC_SYNC0);
GPIO_setPinConfig(GPIO_128_ESC_SYNC1);
GPIO_setDirectionMode(127, GPIO_DIR_MODE_OUT);
GPIO_setDirectionMode(128, GPIO_DIR_MODE_OUT);

GPIO_setDirectionMode(ESC_RUN_LED_GPIO, GPIO_DIR_MODE_OUT);//146
GPIO_setDirectionMode(ESC_ERR_LED_GPIO, GPIO_DIR_MODE_OUT);//145

Ok, thanks. If I understand correctly, the code work fine in standalone mode (with GPIO72/84 pulled high to boot from flash) but not if BOOT setting is configured as 0-bootpin. If that correct ? I am asking this again because in both case ( 0-bootpin or with GPIO72/GPIO84 pulled high), it boot to flash in same manner and if application SW is exactly same then it's very strange that in one case it's not working. 

Regards,

Vivek Singh

 "If I understand correctly, the code work fine in standalone mode (with GPIO72/84 pulled high to boot from flash) but not if BOOT setting is configured as 0-bootpin. If that correct ?"  

Yes, your understanding is exactly right. and I can only locate the problem on a macro level , if you need my ccs project for analyzing the issue  ,i can send to your mailbox (you can send me your mailbox number )

Thanks .

Hi,

You should be able to emulate standalone mode with CCS connected. Please follow below step for the same -

• Connect to CCS (CPU1)  --- Assuming you are loading code on CPU1 only ?
• Open CCS memory watch window and check address 0xD01
• Write 0xA500 at address 0xD01
• Issue reset from CCS
• Click on "Run"

This will run the device like in standalone mode and then you should be able to debug the failure. 

Regards,

Vivek Singh

Hi:

I  do the  following  operation according to your suggestion:

1 、Before modify the  0xD01,wnen in ccs debug mode, the esc slave can step into op . and  re-power the esc slave , it can't step into the op.

     error :'0x001b' - sync manager watchdog

2、Change the   0xD01 and do not reset the ccs, the esc slave can step into op.

3、Change the   0xD01 and  reset the ccs, the esc slave can't step into op. error :'0x001b' - sync manager watchdog

4、Now I can debug  in flash emulation debug mode, I find the  PDI_Isr();   Sync0_Isr();  Sync1_Isr() three interrupt function can't be excuted because of the breakpoint can't  work.

"2、Change the   0xD01 and do not reset the ccs, the esc slave can step into op."    

 when state in the above 2 , the PDI_Isr();   Sync0_Isr();  Sync1_Isr() can be excuted  , so I don't know why 

Hi, 

I am glad that you are able to replicate the issue with CCS connected. You have to reset the the CPU to take effect of the write @0xD01 address. If no reset then this value has no meaning because this is read by BOOTROM code.

On below issue -

user5363809 said:

Now I can debug  in flash emulation debug mode, I find the  PDI_Isr();   Sync0_Isr();  Sync1_Isr() three interrupt function can't be excuted because of the breakpoint can't  work.

You may be copying this code from flash to RAM and then executing from RAM. If that is correct then please make sure that you are setting up the breakpoint after execution of memcpy  function. 

Regards,

Vivek Singh

Hi Vivek:

I  define a static variable ii that can be send over can as follow , when  in css debug mode ,I can see the ii changes over time, slave stack works normal (op mode ),then I reset cpu (click the menu),the slave stack also works normal(op mode), ii also changes over time.but when i re-power the control card ,the ii is always 0 that be send over can ,the slave stack show error :'0x001b' ,so  the PDI_Isr() in standalone mode can't be triggered after  be set zero boot mode. I don't know why?  

I set zero boot mode for the reason that GPIO72  conflicts with emif data[12]. do you have any other solution?

Hi,

At what address location variable "ii" is placed ? It look like you are placing something in RAM which is volatile memory and content is not retain after power up hence it work when you are loading the code via CCS but after power up since RAM is not loaded, it's not working. Please review your linker cmd file to make sure you are no placing anything in RAM which is supposed to be in flash (non-volatile memory). 

Also earlier, you were able to replicate the issue with debugger connected (emulating standalone mode). Are you not able to debug using that ? One thing you need to do that with debugger connected, you should not load the code again because code is already loaded in flash. Just launch the target configuration file (do not us debug launch) then connect to CCS and then follow the step for running in standalone mode. That would be the best way to debug this issue.

Regards,

Vivek Singh

Hi: 

1、cmd is 2838x_FLASH_lnk_ecat_cpu1.cmd .it provided by TI,and  I add the follow the content in the cmd file for emif communication

memory:

EMIF1_CS0n : origin = 0x80000000, length = 0x10000000
EMIF1_CS2n : origin = 0x00100000, length = 0x00100000
EMIF1_CS0_CS2n : origin = 0x00200000, length = 0x00100000
EMIF1_CS3n : origin = 0x00300000, length = 0x00080000
EMIF1_CS4n : origin = 0x00380000, length = 0x00060000
EMIF2_CS0n : origin = 0x90000000, length = 0x10000000
 EMIF2_CS2n :origin = 0x00002000, length = 0x00001000

sections

emif_cs0_nonfar : > EMIF1_CS0_CS2n
.farbss : > EMIF1_CS0n
.farconst : > EMIF1_CS0n
.em1_cs0 : > EMIF1_CS0n
.em1_cs2 : > EMIF1_CS2n | EMIF1_CS0_CS2n
.em1_cs3 : > EMIF1_CS3n
.em1_cs4 : > EMIF1_CS4n
.em2_cs0 : > EMIF2_CS0n
.em2_cs2 : > EMIF2_CS2n

2、“Are you not able to debug using that ? One thing you need to do that with debugger connected, you should not load the code again because code is already loaded in flash. Just launch the target configuration file (do not us debug launch) then connect to CCS and then follow the step for running in standalone mode. That would be the best way to debug this issue.”

I have test the the method that you told me step by step, unfortunately it made no difference.

PDI_Isr() is triger by twincat (master), I have capture the message by wireshake , the twincat  has send the triger signal(pdo out),but PDI_Isr() also can't be executed meanwhile in debug mode it can be executed.

3、Deng told me you can have a meeting with me to solve my problem,  can you tell when (beijing time) and  What kind of web conferencing software?

When are you initializing the EMIF interface in your code? By default EMIF interface is not enabled so you can not access any variable from it unless EMIF module is setup. 

I'll request Deng to setup the Webex.

Regards,

Vivek Singh

Hi: 

I am sorry that  I can't explain the issue clearly.

Emif communication is right ,but if I don't set F28388d to zero mode boot, the GPIO72 is always be pull up（ensure boot from flash successfully ） ,meanwhile the GPIO72 is also the emif's data[12] line, so that why I set hardware to zero mode boot.

Then after  zero mode boot, the ethercat function is wrong。