• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 81 subscribers
  • Views 318 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28379D: TIDM-1010 BiSS Reference Design not triggering SPI RX FIFO interrupt

Chaitanya Sindagi
Intellectual 300 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: CONTROLSUITE, C2000WARE, BOOSTXL-POSMGR, TIDM-1010

Pretty much all in the title. I'm using the provided sample code for the position manager in ControlSuite since C2000Ware doesn't have BiSS support yet. I'm using the 379D control card in the provided docking stand with some jumper wires to connect them all together. I'm fairly certain I have it all connected correctly, I have checked this many times. 

The CLB portion seems to work correctly, the Start bit is detected, the clock to the encoder is stopped right after the correct number of bits and the clock to the SPI is stopped after 24bits, which is fifo_level(2) * fifo_width(12). However, the "bissc_spiRxFifoIsr" never runs and therefore the main loop is stuck at

while (bissc_data_struct.dataReady != 1) {}

I'm convinced there is some issue in the software or setup of the interrupt but I haven't changed the provided sample code at all so I can't quite figure it out. Is there something specific I should be doing for debugging if I want interrupts to stay active? Perhaps I'm using the incorrect mode which is disabling interrupts? Another piece of information I can provide is when I pause debug at the line where it gets stuck waiting for dataReady, the Rx buffer always has the same value in it even if I rotate the encoder and observe different data on the scope, it always looks like what is seen below, regardless of what data it actually received

 

  • 0
    TI__Guru* 89465 points

    Chaitanya Sindagi said:
    I'm using the 379D control card in the provided docking stand with some jumper wires to connect them all together.

    Does your hardware include a RS-485 transceiver?  The TIDM-1010 BiSS-C example assumes there is a BOOSTXL-POSMGR attached to a launchPad.  The BOOSTXL-POSMGR includes the transceiver. 

    Another things to check:

    • The encoder is powered correctly and not current limited.  
    • Monitor the pins with an oscilloscope to see if the encoder responds. 

    Regards

    Lori

  • 0 in reply to Lori Heustess
    Intellectual 300 points

    Hi Lori

    I can confirm that the encoder and CLB are operating correctly. Below is an oscilloscope screenshot of the SIMO(yellow) and CLK(GREEN) that the control card is receiving as measured at pins 75 and 79. The Clock signal is stopping right after the correct number of bits have been transmitted and the data changes when I restart the program and run it again after rotating the resolver, so the CLB and resolver are definitely operating correctly. 

    The hardware I'm using is the control card+baseboard and the POSMGR board. Since I didn't have a launchpad I connected them with jumper cables, but everything is working nevertheless. I connected the TX_EN, GPIO6, GPIO7, SPI_SIMO, SPI_SOMI, SPI_CLK, SPI_STEB. Is there some other pin necessary for this to work? 

    I am using the RM44DC 13-bit resolver for reference

    In addition, I was under the impression that the SPIDAT register updated when data was collected, however, I'm noticing that there is no data in that register after the transaction is complete. Is this normal? 

    Also, in the process of debugging, in the "bissc_configXBAR()" function, I had to change the following line to say 24, without this  the CLB was not detecting the start bit, could this have messed up something? The original code had it as 63 which seemed to be the wrong pin.

    InputXbarRegs.INPUT1SELECT = 24;    // GPTRIP XBAR TRIP1 -> GPIO63 
    //// Used to be - InputXbarRegs.INPUT1SELECT = 63;  ////

    Thanks

  • 0 in reply to Chaitanya Sindagi
    Intellectual 300 points

    I connected it to the wrong set of SPI pins. I didn't realise it had been configured for GPIO63-66 instead of GPIO24-27. I'm having a lot of CRC error however, though this is likely due to all the loose cabling that I have and not an actual issue since the data is still being received correctly some of the time