TMS320F28379D: Biss-C clock glitch

Hi,

I'll get back to you in a couple of days. Most probably early next week.

Hi, 

I have spotted another issue regarding the BiSS-C clock generation after comparing it with a working BiSS-C adapter. I've noticed that when the CDM bit of the clock signal is high, both clocks are identical, however when the CDM is at low level, the clock generated by the C2000 Position manager library has fewer pulses (one less) than the clock generated by the other adapter.

I have tested this using clocks of the same frequency and comparing them with the cursors in the oscilloscope. I am attaching two images comparing the clocks generated by the adapter and by the C2000 library, both with CDM = 1 and CDM = 0.

How could this affect the BiSS-C communication?

Best regards

Hi,

I apologize for the delayed response on your query.
I was trying to refer to https://www.ichaus.de/upload/pdf/BiSS_C_protocol_C6en.pdf specification to find out any specific details of the clocks at the end of the transaction for the CDM bit. 
Did you run into any issue in using the CDM bit with the library? It seems from the tests performed with the encoders (listed in the library document) the transactions did not cause any issues. We do not have a transceiver/adapter for comparing the wave forms and debugging the exact implementation.
Is your CDM/CDS transactions occurring as expected?

Hi, Could you provide information on the queries above? If you think the issue is resolved, please close the thread.

Hi,

Sorry for the lateness in my response. If it helps, the encoder I am trying to communicate with is the MU150 by IC-Haus. The interface that I am using to communicate with it is the MB3U.

I began analyzing this behavior because the CDM/CDS transactions do not work when I interface the encoder using the c2000 microcontroller. However, they do work when using the ICHaus device. 

At the moment I cannot be sure if CDM/CDS transactions not being correct is causing the behavior that I am reporting, or viceversa.

To be more specific, I always receive CDS bits as 1 from the encoder, never 0, regardless of what CDM I send. I'd expect these CDS bits to change when the CDM bits on the register frame change value. 

When using the MB3U interface, the CDS bits do change, so I believe it is not an encoder problem.

Thanks for your time

Hi,

I do not have the adapter or encoder you've mentioned. But can you check few things below.
How are sending the command using the SCD. What parameter are you passing with PM_bissc_setupNewSCDTransfer command.
What are your setting used for BISS_ENCODER_HAS_CD_INTERFACE parameter?
Can you also check the bissc_data_struct.cdm and monitor cd_bits_to_send, remaining_cd_bits etc.?

Hi,

Regarding your question, in the first parameter of the PM_bissc_setupNewSCDTransfer I am setting the frame size of the BiSS-C frame including the CDS bit and the Start bit. In these particular screenshots, this parameter was "29". The SPI_FIFO_WIDTH is configured to 8 bits.

I am not using the bissc_data_struct for decoding, so cd_bits_to_send and remaining_cd_bits are not used by the program. I am handling the decoding of Rx data myself and the transmission of CD data myself. I can properly decode CRC, positions, etc, this is not a problem. I am using the PM_bissc_setCDBit function to set or clear the CDM bit in each clock frame by giving it a "1" or "0" in its input parameter. 

The CDM bit on the clock changes correctly when I command it to change, this part is not the problem. The problem I find is that when the CDM bit on the clock has value 0, the clock signal presents one clock less than when the CDM bit on the clock is 1. This is documented above in a screenshot.

In the ICHaus device, I count 33 rising edges, and the 34th, corresponds to the CDM bit. In the MCU, in one case, I count 33 rising edges, in the other case 32. 

I believe that both this missing clock and the documented glitch on the clock signal might be causing unwanted behaviour in the feedback. Is the CLB changing the clock pin configuration on the fly every time I call PM_bissc_setupNewSCDTransfer? I don't have control over this pin's configuration so I don't know what is happening in this case.

I don't understand why there is a clock missing in one device and not in the other in this case, and why there is a glitch in the clock when I call the PM_bissc_setupNewSCDTransfer function.

What could be causing this behaviour?

Hi,

CLB does change the clock pin configuration every time a new transfer is initiated.
In case when a call to  PM_bissc_setupNewSCDTransfer function call is made the clock output configuration is reset.
But during this period output should be driven High. This is done by the bissc_configEPWM4 in bissc.c
Since the CLB outputs are muxed on the same EPWM pins - during configuration reset, mentioned above, PWM output would be the default value on the clock pin. This is always forced high by bissc_configEPWM4 function call in the beginning. So, the output should continue to remain high when a call to PM_bissc_setupNewSCDTransfer is made. So, there should not be any glitch on the output.

Also, note that now CLB configuration tool is available for users to configure on their own.
Device TRM is also updated with CLB content.

CLB Configuration tool and examples are provided in the latest C2000ware release.
Please download from http://www.ti.com/tool/C2000WARE
Refer to documentation under http://www.ti.com/lit/ug/spruir8/spruir8.pdf 
and examples under C:\ti\c2000\C2000Ware_2_00_00_03\driverlib\f2837xd\examples\cpu1\clb

Hi,

Were you able to resolve the glitch? Did the PWM configuration for the default state, as mentioned in the above post, help in resolving glitch?