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.

TMS320F28069M: Integrate SCI with Instaspin

Part Number: TMS320F28069M
Other Parts Discussed in Thread: MOTORWARE, C2000WARE,

Hello,

I am using a custom board (derived heavily from the DRV8301-HC-EVM evaluation board) to implement InstaSpin FOC for motor control. I have an LCD module that is sending messages to the motor control board (MCB). There are 2 types of messages: 1 is a "GET," which requests data from the MCB, the other is a "SET," which sends new values for various parameters to the MCB, in response to user input. I am successfully controlling the motor now, and want to be able to communicate with the control board in the manner described above, using the SLIP protocol. If there are no substitutions in the message from the LCD (sometimes required so that control characters are not mistaken for data), then the GET message is 12 bytes, and the SET message is 33 bytes.

These messages from the LCD are being transmitted every 500ms at 115.2kBAUD. Let's assume the message is 12 bytes (the smaller one) - that would take 833us to complete. It's really closer to 1ms, when you consider start & stop bits, etc... I'm using Lab 05b, from the InstaSpin Labs as a template for motor control. I've added routines native to MotorWare to handle the serial communications. The motor I'm using is of relatively low inductance (60uH), so I've been using 45kHz as the PWM Frequency. I can lower it to 30kHz, without any immediately obvious adverse effects, but lowering it to 20kHz results in some awful cogging, and a screeching sound. I'm decimating that by a factor of three to derive the ISR frequency. This means that the main interrupt fires at 15 kHz. This allows 66us between interrupts, in order to control the motor with InstaSpin. This doesn't even allow time to pick up a single byte. Even if it did, there's no guarantee that contiguous bytes would have the courtesy to arrive at the Rx input of the micro between interrupts.

I can receive messages successfully, if the interrupts are not present. So, I have the two halves of this project working independently, but they cannot, so far, work together. I've looked into using DMA to disentangle comm from control, but evidently there is no path from SCI to DMA, even though "Multichannel buffered serial port transmit and receive" is listed as one of the "Peripheral interrupt trigger sources" in the TMS320 Technical Reference document (pg. 720). How can I successfully implement serial communications with the LCD module, if the interrupts keep interrupting it, and I can't use DMA?

Here's a screen capture from an oscilloscope showing what's going on. I put a "toggle GPIO" statement at the beginning and end of the main ISR. That's the yellow trace. The blue trace is the serial message from the LCD module.

Best Regards,

Dave Reagan

  • if the interrupts keep interrupting it, and I can't use DMA?

    No. DMA doesn't support the SCI. You may try to use the SCI FIFO if the frame data length is less than 16 bytes.

  • Hi Yanming,

    The maximum number of symbols that the receive data frame could likely assume is about 47 bytes.

    Is there some technique whereby I could collect data on the serial port while these interrupts are firing off every 66us?

    There’s McBSP, but that requires 6 pins and looks kind of like SPI, with its own CLK to gate data in & out. That would require another board spin, and I think management is beginning to lose patience with me on that front. We’d also have to get the subcontractor who wrote the LCD firmware to alter their code (and perhaps their board layout), in order to accommodate the new scheme. Further complicating things, the guy that wrote the code for them has moved on to another company.

    Barring the use of DMA (and therefore McBSP), I could lower the ISR repetition rate to 10kHz (30kHz PWM). That way if I wanted to, at least occasionally, pick up a message from the LCD, I’d have to be able to fit, say, 40 bytes into 100us. That’s 3.2 MegaBAUD. LSPCLK/16 is the maximum BAUD rate for the TMS320 – that’s 5.6MegaBAUD. So, I guess it could be done, as long as the micro in the LCD module is capable of that as well. One value that seems like it might be reasonable is 3.686MegaBAUD.

    But I hate that it would become some statistical game of chance at this point. I should be able to receive and send messages predictably via the serial ports. Otherwise, what's the point of having this technique called InstaSpin? It seems the only thing you can use it for is a constant speed that the user can't reliably change. Unless, of course, you knew beforehand that serial comm wouldn't work; that you'd have to use McBSP and DMA. There should be a warning at the beginning of the User's Manual, in bold print, in bright Red, letting us know that there's only one way to communicate serially with the system, and that's via McBSP. Technically I guess JTAG could be used as well, but we can't ship an XDS110 and a laptop with every product.

    Right now, though, I'm stuck with using the UART. Do you know of some technique to reliably use it?

    Thanks,

    Dave

  • Is it possible to use SPI for this communication? The SPI can support DMA.

    Or you may refer to the example in C2000Ware to use nested interrupt method. You can enable SCI RX and TX interrupts to nest the interrupt for motor control, but try to short the RX and TX ISR execution time.

  • Hi Yanming,

    At this stage I can't use SPI. That would require another board spin for me, and for the subcontractor that developed the LCD Module.

    I'll look into nested interrupts, but I thought the TMS320F28069M was not capable of that?

    Thanks,

    Dave

  • All of the C2000 devices including F28069 can support the nested interrupts. You should try to reduce the SCI ISRs expectation time by only receive/transmit the data in these ISRs.