sync0 interrupt is not triggered

[evencewu]

Your code and documents are awesome! Thank you for your sharing.

I used the SOEM example program ''simple test'' to connect to the soes slave and the slave successfully entered the dc state. But the data exchange doesn't seem to be happening, and when I measure the sync0 pin with an oscilloscope, I find that it stays high, which means my sync0 flag is not triggered.

How can I deal with this and should I make changes to the master program?

[kubabuda]

dc state

Do you maybe mean OP state? I had not wrote any SOEM code yet, my testing so far was done with TwinCAT. Example applications in this repo do not have DC enabled either. Have you added DC settings yourself?

[evencewu]

dc state

Do you maybe mean OP state? I had not wrote any SOEM code yet, my testing so far was done with TwinCAT. Example applications in this repo do not have DC enabled either. Have you added DC settings yourself?

Sorry, I didn't express it clearly. My slave station has entered the op state, but the sync0 interrupt is not triggered. In addition, I have made modifications based on soem's routine to support DC synchronization, but the actual situation is that it has no effect.

[kubabuda]

I understand. As said, I got no experience with SOEM but you want to isolate problem. Make sure if it's your SOEM based code that does not emit DC, or ESC/MCU code that eats DC packet but does not emit SYNCx signal.

• You can capture Ethernet session with Wireshark, it has EtherCAT decoder, and look if your master is emitting DC packets.
• Or you can use EtherCAT master that surely has DC working, without line of your code (so you are sure your code did not broke it), as a reference. TwinCAT can do it, in my docs there should be instructions

[evencewu]

Thanks, I also want to confirm another thing: whether the interrupt of the PA3 pin should be triggered continuously during the slave station exchanging data. I found that my slave station will only trigger an interrupt when communicating with the master station.

[kubabuda]

You mean PDI interrupt? I was getting the same IIRC and it sounds right. Why would you expect Protocol Data Interface interrupt, if nothing changed in protocol data?

[evencewu]

You mean PDI interrupt? I was getting the same IIRC and it sounds right. Why would you expect Protocol Data Interface interrupt, if nothing changed in protocol data?

Sorry, I should correct my statement, I mean when the slave communicates with the master, the PDI interrupt will only be triggered once.

[kubabuda]

Ah. This is weird, probably some flag needs to be cleared

[evencewu]

Yes, below is my interrupt callback function

void EXTI9_5_IRQHandler(void) { if (EXTI_GetITStatus(EXTI_Line8) != RESET) { //GPIO_ToggleBits(GPIOB, GPIO_Pin_15); pdi_irq_flag = 1; EXTI_ClearITPendingBit(EXTI_Line8); } }

I used PA8 pin as PDI interrupt pin

[evencewu]

I have detected the line using a oscilloscope in the past few days. What is interesting is that the PDI interruption pinch did not generate a signal, it kept high level。

[kubabuda]

Hi, I have done sanity check (latest SOES_CIA402_AX58100 + TwinCAT with DC) and all is working as expected - follow up PDI IRQs are triggered properly. Either your SOEM master code does something different, or you got some issue with board. Please do test with TwinCAT, or publish and link the SOEM-based project.

[qiayuanl]

I had the same issue (PDI interrupt will only be triggered once) half a year ago. But I don't remember how to solve it. The problem may be about the interrupt priority. I already switched to AX58400 for a while, so I am unable to confirm and reproduce the issue.

[evencewu]

I had the same issue (PDI interrupt will only be triggered once) half a year ago. But I don't remember how to solve it. The problem may be about the interrupt priority. I already switched to AX58400 for a while, so I am unable to confirm and reproduce the issue.

Thanks for the clues you provided, I verified one thing. Using DMA interrupt and PDI interrupt at the same time will cause a conflict: this is specifically manifested in that they will only trigger once. I tried changing their priority relationship but it didn't work, maybe this is an uncommon bug.:joy:

To add, my hardware device pins are different. The PDI interrupt pin uses PA8, and the SPI interface uses spi2.

[kubabuda]

@qiayuanl do you remember if you had this problem using SPI other than SPI1?

BTW what SYNC period have you guys set on master end?

[qiayuanl]

@qiayuanl do you remember if you had this problem using SPI other than SPI1?

BTW what SYNC period have you guys set on master end?

I use STM32CubeMX to generate the code, and different SPI works with the evaluation board of ax58100 and ax58400.

For SYNC, I tested from 100Hz to 2000Hz and validated with an oscilloscope.

[evencewu]

@kubabuda Most of the tests I've done have shown that PDI interrupts are affecting other interrupts, maybe there's something wrong with my hardware design? Whether you add a pull-up/pull-down resistor or a capacitor to the PDI interrupt pin.

[kubabuda]

On my HW there are no pull up/down resistors (nor filter caps) for PDI IRQ, nor SYNC signals.

Do you have these problems when DC and pdo_override are not used?

[evencewu]

On my HW there are no pull up/down resistors (nor filter caps) for PDI IRQ, nor SYNC signals.

Do you have these problems when DC and pdo_override are not used?

Yes, I tried not initializing sync0 but I still have this problem.

I'm not sure what you mean by not using pdo_override, but I tried changing the spi dma transmission to a normal transmission, and there's still have this problem.

If that doesn't work out for a while, I'll make changes to the hardware next. :sob:

[kubabuda]

Hi @evencewu how is your setup debugging going?

[evencewu]

@kubabuda I tried the new hardware and used the connection method of your project, but it still had the same problems as before I doubt it's the settings of eeprom and related programs that affect it