AM2432: Use (general) ECAPs to generate a clock signal for delta-sigma

Hello Christian

Thank you for the query.

I am reviewing the inputs and also checking internally.

Regards,

Sreenivasa

Hello Christian

I am assigning the query to the expert to support.

Regards,

Sreenivasa

Hi Christian,

Yes, it is possible. You need to configure the following items in SysConfig:

SDCLK Generation From: None

SDFM Clock Configuration:

• ChannelX SDCLK Source: Set the source to the respective channel clock.
• ChannelX SDFM Clock (Hz): SD clock value (equal to the generated clock).

Christian Dev said:

Why there has to be defined a value since the CLK is provided externally?

This value is used in the SDFM firmware to configure the IEP CMP4 event. The IEP CMP4 event is responsible for determining the timing of normal current.

For more details, please refer to the SDFM firmware implementation: AM243x Motor Control SDK: SDFM Interface Design   

Thanks & Regards,

Achala Ram

Hello Achala,

thank you for your answer. Sadly this doesn't solve my problem completely. I use an AMC1306 as external Delta-Sigma Modulator with a shunt resistor for the current measurement. However if i apply a constant current to the shunt resisotr the aquired (raw) sample values change (drastically) if i change the ChannelX SDFM Clock (Hz). How is this possible (Theoretically with a constant current this value should have no effect)? 

Thanks,

Christian

Christian Dev said:

However if i apply a constant current to the shunt resisotr the aquired (raw) sample values change (drastically) if i change the ChannelX SDFM Clock (Hz). How is this possible (Theoretically with a constant current this value should have no effect)? 

In ICSS PRU, Sigma-Delta Sinc filtering is achieved through a combination of PRU hardware and firmware. The PRU hardware provides hardware integrators that perform the accumulation part of the Sinc filtering, while the differentiation part is handled in the firmware.

As mentioned, the ChannelX SDFM Clock (Hz) value is used to configure the IEP CMP4 event, which is responsible for sampling timing. The firmware reads the accumulator output when the CMP4 event is triggered. If you see the doc, the CMP event get updated for the next sample after every time. This update depends on the Sigma-Delta clock, OSR, and Sinc filter parameters. If you change the Sigma-Delta clock value, the firmware will read accumulator output at different times, causing a mismatch where the accumulator buffer has values of different OSR , and the differentiation buffer also has values for different OSR (desired OSR). This will lead to an issue where the accumulation and differentiation OSR for the same sample data will not align

Thanks & Regards,

Achala Ram

Hello Achala,

thank you for your answer. With your explanation i understand the filtering/firmware a little more, but not yet completey. I hope you can help me again with my specific situation. With the (general) ECAPs i generate a clock signal wich is used for the external modulator (AMC1306) and is supplied to each channel individually (SD0_CLK, SD1_CLK). The ECAP is configured to generate a clocksignal of 20 MHz but due the very small calculated register / compare values i measure a signal of about 19 MHz. Without the measurement, i would also set 20MHz for ChannelX SDFM Clock in the sysconfig. My question: Is the deviation relevant? 

The SDFM is configured to process the NC sampling based on the expected clock frequency (20 MHz). A mismatch between the actual clock frequency and the configured frequency can lead to inaccuracies in filtering. This happens because the firmware will read the accumulator output earlier or late than the expected time frame due to the difference in the actual clock value. You need to configure the ChannelX SDFM Clock in sysconfig equal to the actual clock frequency(19MHz).

Thanks & Regards,

Achala Ram

Hello Achala,

thank you for your answer. Isn't his a potential problem? Depending on external influences such as temperature, the generated clock signal will drift from the orginal value. The deviation between the actual clock and the configured clock value for ChannelX SDFM Clock can then lead to a mismatch. Also, high clock rates would be a potential problem if the calculated register/compare values are very small, which would result in deviations. Is there a tolerance margin? What would happen if the generated clock signal had a frequency of 19.7 MHz and in syscfg 20 MHz is configured for the ChannelX SDFM Clock?

Thanks in advance,

Christian

Christian Dev said:

What would happen if the generated clock signal had a frequency of 19.7 MHz and in syscfg 20 MHz is configured for the ChannelX SDFM Clock?

Can you please specify the version of the motor control SDK that you are using?

Thanks & Regards,

Achala Ram

Hello Achala,

i am using the version 09.02.00

Greetings,

Christian

Yes, the sampled value will be incorrect when the SD clock is unstable or has jitter and variations. This is because CMP4 will be configured based on a ChannelX SDFM Clock (20MHz) so for next the sample CMP4 will be triggered after 960 IEP counts (at IEP @300MHz, 64 OSR). However, if the actual clock frequency deviates from the configured ChannelX SDFM Clock (20MHz), the actual sample time frame will change. For example, if the actual clock frequency is 20.5MHz, For the correct sampling firmware should read after 937 IEP counts. But the ChannelX SDFM clock is configured for 20MHz, the firmware will read the sample after 960 IEP counts. This will cause the problem of incorrect sample values 

Are you using overcurrent for error detection?

We have another mode/implementation for normal current sampling that can handle this type of scenario, which does not rely on the SD clock and IEP CMP4 for sampling. This mode is not available in the current SDK release but will be included in the next SDK release.

Thanks & regarding,

Achala Ram

Hello Achala,

thank you for your answer! I am very interested in the mode which does not rely on the SD clock and IEP CMP4 for sampling. Could you tell me, when the new SDK version, which includes this implementation will be released? 

Yes, i am planning to use overcurrent detection & fast over current detection for my application.

Your answer raises a furhter question for me: If (currently) devation from the configured ChannelX and actual clock are a potential problem, it would be better to supply the two delta-sigma modulatios from a single ECAP. What would be the best way to realize this in hardware? A clock distribution module would possible lead to delays/devations again. Do you have a recommendation?

Thanks in advance,

Christian

Christian Dev said:

thank you for your answer! I am very interested in the mode which does not rely on the SD clock and IEP CMP4 for sampling. Could you tell me, when the new SDK version, which includes this implementation will be released? 

It is planned for the end of this month!

Christian Dev said:

Yes, i am planning to use overcurrent detection & fast over current detection for my application.

Can you share the use case for both overcurrent and fast overcurrent? and what OSR, SD clock & number of channels are you going to use for your application?

With another version of SDFM, there are some limitations with overcurrent. If you share the requirements for sdfm, I can suggest a possible solution

Thanks & regards,

Achala Ram 

Hi Achale,

thanks for your answer. After further consideration of the technical documentation of the AM243x, i see no toher way to adapt the pin mapping / hardware layout so that the delta-sigma current measurement (including over current measurement & fast detect) works properly. Pleas find attached a block diagram of my entire proposed circuit. I would appreciate your feedback if this is possible, or you have suggestions for improvement.

The (external) Delta-Sigma would be operated with a clock frequency of 20MHz. Channel 0 & 1 would be used for current measurement (SINC3, OSR=64 (or 128), the other two channels for a temperature measurement. 

Another important question i have, since i want to use the trip events for the automatic shutdown of the EPWMs, is also the correct mapping/usage. Since the EPWMs do not have direct access to the trip zone events, these signal(s) must be routed externally via PWM_TZ_OUT to EHRPWM_TZn_IN0. The datasheet of the AM243x states, that TZ_OUT is high-active and TZ_IN is low active. This means that a level inversion would have to be carried out in hardware sot that the automatic termination of the EPWMs works. Is this correct, or is there another solution?

Thanks in advance,

Christian

Christian Dev said:

This means that a level inversion would have to be carried out in hardware sot that the automatic termination of the EPWMs works. Is this correct, or is there another solution?

There is no other way; it must be handled by external hardware only

Thanks & Regards,

Achala Ram