MCU-PLUS-SDK-AM243X: AM243x

Maor Shalom said:

Have you ever encountered this issue in the past ?

Hi Maor,

Firmware will always get stuck here if the CMP event is not getting hit. When the CMP event occurs, a task switch happens, and the firmware starts executing the normal current.

One possible issue if the firmware is always stuck here is that the IEP is not getting reset, which is why the CMP event does not occur periodically.

As you mentioned, this happens sometimes. Can you check the EPWM sync-out signal? Is it being always generated periodically or not?

Thanks & regards,

Achala Ram

which CMP event are you referring to ?

Achala Ram

Hi Achala

This happens when we plug cable back.

We are going to check behavior of EtherCAT SYNC0 with logic.

What if SYNC0 is stuck at "0" or "1"? How this can influence the work of SDFM?

How length of EtherCAT SYNC0 pulse influences SDFM firmware?

Is it possible to apply some signal shaping to SYNCin or SYNCout or input to IEP?

Thanks

Rasty

IEP counter is getting reset by the EPWM sync-out event, and the CMP4 event gets triggered periodically to start sampling for SDFM normal current. Refer to the mentioned document for more details.AM243x Motor Control SDK: SDFM Interface Design  If the IEP is not getting reset, then CMP4 will not get triggered periodically, and the firmware will remain stuck in an endless loop.

Rasty Slutsker said:

What if SYNC0 is stuck at "0" or "1"? How this can influence the work of SDFM?

If it is stuck at '0' or '1', then the EPWM will not generate SYNC0 out event periodically, so CMP4 will not get triggered periodically because the IEP will be in free-run mode, and the firmware will remain stuck in an endless loop. 

Also, could you please share the details of the SDFM example and the SDK version you are using? what SDFM configuration you are doing ? what is EPWM SYNC out event rate ?

Thanks & regarding,

Achala Ram

Hi 

We will share requested details.

Before that. We found that SDFM implementation of in PRU is sensitive to timings.

If we stop and resume is with debugger it stuck in busy wait and does not produce interrupts anymore.

Single failure to meet some condition causes complete dead-lock, similar to what we see.

I think that SYNC0 irregularity can produce the same effect.

Thanks

Rasty

Rasty Slutsker said:

If we stop and resume is with debugger it stuck in busy wait and does not produce interrupts anymore

Yes, stopping PRU can cause this problem, as IEP will be continue running, but the firmware will not clear the CMP4 event and will not update the CMP4 register for the next SDFM sample.

Rasty Slutsker said:

I think that SYNC0 irregularity can produce the same effect.

What value are you configuring for the SDFM sample trigger time? And what is the minimum time between two consecutive sync events? Because if the IEP is getting reset before the sample trigger point, then the CMP4 event will not get set and it will get stuck in wait loop 

BR, 

Achala Ram 

Hi

EtherCAT SYNC0 is connected to PWM0 SYNCin, which is reflected in PWM SYNCOut, which goes to PRU.

When cable is disconnected/connected I assume anomalies on SYNC0.

Normally EtherCAT produced short pulse on SYNC0 every 0.5/1/2/4 miliSec

What type of anomaly on SYNC0 can cause SDFM dead-lock? 

How to recover?

Thanks

Rasty

Rasty Slutsker said:

Normally EtherCAT produced short pulse on SYNC0 every 0.5/1/2/4 miliSec

EtherCAT produces short pulses continuously, but the timing between pulses is not fixed—it can be 0.5, 1, 2, or 4 milliseconds, with a minimum interval of 0.5 milliseconds. Am i right ?? 

Hi

Interval is constant, selected by controller.

At the beginning some jitter may occur due to clock syncronization.

Thentime is fixed and intervals are very precise.

If we remove/insert cable, some jitter is expected again due to re-syncronization.

Thanks

Rasty

Rasty Slutsker said:

What type of anomaly on SYNC0 can cause SDFM dead-lock? 

1) if  cable is not connected then CMP4 event will get hit due to IEP free run 

2)  if time interval between two continuous sync plus is less then sdfm trigger time then also cmp4 will not get hit because IEP counter will get reset before cmp4 hit 

Can you list API and for SDFM settings?

We tried to generate pulse manually (with EPW, soft pulse) did not help.

What is recovery strategy if we detect stall?

Can you check the following IEP register values when you reconnect EtherCAT sync cable:

• IEP_COUNT_REG0/IEP_COUNT_REG1: These get reset continuously when the EtherCAT SYNC0 cable is connected.
• IEP_CMP_CFG_REG: Bit 5 should be set as it corresponds to CMP4.
• IEP_CMP_STATUS_REG: Bit 4 shows the status of the CMP4 event.
• IEP_CMP4_REG0/IEP_CMP4_REG1: The CMP4 registers values should not exceed the maximum IEP count value. 

6.4.14.9 PRU_IEP_IEP Registers: AM64x/AM243x Technical Reference Manual (Rev. H) 

Hi

Rasty Slutsker said:

Normally EtherCAT produced short pulse on SYNC0 every 0.5/1/2/4 miliSec

Can you also clarify this? Can you share a logic analyzer or scope screenshot? What pulse width are you configuring?

Regards

Dhaval

Hi Dhaval,

Register of ESC 0x0982 reads 100.

We did not manage to capture it with scope, because it happens at randomly in one of many boards.

I can tell that SYNC0 is not stuck at "1", we tested it by manually reprogramming PWM SYNCin pin to GPIO and checking its state.

We can restart SFDM frimware from ARM and recover. 

What condition can cause this behavior?

Too short SYNC0 pulse? too long SYNC0 pulse? too short  distance between 2 SYNC0 pulses?

Thanks

Rasty

Rasty

Which hardware platform are you using for these tests?

Regards

Dhaval

Hi,

We test it with Omron PLC.

Problem detected when multiply drives are connected and network is in OP.

Disconnection and reconnection of EherCAT cable from last drive in the line causes random dead-lock SFDM in other drives.

Since SYNC0 should be aligned in all devices on network i'd expect "more consistent" dead-lock in multiple devices.

What bothers me that I do not understand the nature of this problem. Without full understanding I cannot rule out random deadlocks due to SYNC0 drifts that can vary from one master to another.

Thansk

Rasty

Rasty

I wanted to understand if you are using TI's LP-AM243 or TMDSAM243EVM or custom board.

Regards

Dhaval

AM2434BSDGGIALVR

DP83826IRHBR

custom board.

Hi Rasty,

Rasty Slutsker said:

Too short SYNC0 pulse? too long SYNC0 pulse? too short  distance between 2 SYNC0 pulses?

A short distance between two SYNC0 pulses can cause issues, but again this depends on the configured value for the SDFM trigger point.

Here is an explanation of how a short distance or an SDFM trigger point value greater than the time between two pulses can lead to this behavior. The SDFM firmware uses CMP4 to start SDFM sampling so you can think like CMP4 event = SDFM trigger point.

• The CMP4 event will be missed if the time between two consecutive pulses is less than the configured value for the CMP4 event.
• Alternatively, if the CMP4 configured value is greater than the time between two consecutive pulses, the SDFM task will not be executed.

Thanks & regards,

Achala Ram