TMS320F28388D: T_format interface something wrong

Hello,

Here are some debug steps.  Some reference the BOOSTXL_POSMGR but still apply to the IDDK. 

1. Can you confirm which software library you are using? i.e. make sure it is the F2838x library and not the F2837x. Make sure the project uses the F2838x support files (for example driverlib, linker command file).  This is important since the CLB register memory mapping changed between these two devices.
2. Confirm that the encoder supports T-Format.  Some Tamagawa encoders are not T-Format.
3. Check the signals coming out from the C2000:  
   1. TxEN: high during DATA_OUT being sent.
   2. SPICLKB:  
   3. DATA_OUT (SPISOMIB): 
4. If you do not see any activity on SPISOMIB:
   1. Check that SPICLKB is connected to the SPI CLK coming out of the CLB (GPIO7).   SPICLKB must be driven by the CLB (GPIO 7). 
      Note: If you have a LaunchPad and are checking signals without the BOOSTXL-POSMGR connected, you must tie these two pins together in order to see SPISOMIB.  If you are using BOOSTXL-POSMGR, then it connects these two signals.
5. Check that SPICLKB is 2.5 MHz and the bit-width of DATA_OUT is 400ns.  400ns is required for T-Format and if this is not correct, the encoder will not respond. 
   1. If the bit width is not 400ns then the encoder will not respond and the clock needs to be adjusted.
   2. Use the TFORMAT_FREQ_DIVIDER in the file tformat.h.

An additional note:

When I've observed CRC errors it is usually due to the t-format encoder not receiving good power.  Try powering it directly instead of through the IDDK board.

The reason for the extraction from the 13th bit is only a prediction, but due to hardware timing conflicts, the 3-pit unrelated bit was received, which caused the extraction from the 13th bit. I imagine it's because if the length of 10 bits is specified, all the bitches after that will be out of position. In other words, the hardware is imperfect, and the current bit extraction is weird to cover for it. In this case, I think it is unstable how many bits it starts from.

It seems that SPI's SPISTE is always active, but if we activate it 3μseconds after the end of transmission, we can reduce the data length to 10 bits without receiving spurious data. I think this will stabilize the reception.

Hello.
I have a related question, right now I'm thinking of activating the SPISTE signal with a 3μsec delay after transmission.
As the .vcd file is not created as shown on page 15 of SPRUI8A, how can I set up the post build procedure, please let me know. Also, please tell me where the GTKViewer should be.
Thank you very much for your help.

Hello, 

I am looking into your additional questions and will reply back by end of Tuesday in the US.  

Regards

Lori

user805897 said:

0 bits every 10 bits like a continuous bit sequence and turning it into 8 It looks like it is turning it into 8 bits

Per the t-format specification from Tamagawa, the fields within a transmission frame are each 10-bits including a fixed start-bit (0) and delimiter-bit (1).  The 8-bits remaining (minus the start/delimiter is the information within that field.

user805897 said:

Q1. Why don't you set the SPI data length to 10 bits?
Q2.The Tformat encoder is LSB-first, but the SPI is MSP-first, so there is reason to switch MSB and LSB.
Q3. Why do you cut out the 13th bit?

You could try changing the SPI data length to 10 bits as an optimization.  The sendClks may need to be adjusted in order for the alignment to be what you want.

The 13th bit is the START bit which is always 0. 

Because the SPI is always receiving, it will receive a '1' during sendClks.  In the case of, for example DATAID2, sendClks is 18 clocks --> 16 (word 0)  + 2 (word 1 bit 15, bit 14), so the ControlField starts in bit 13 of word 1.