• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 81 subscribers
  • Views 438 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F280037C: Universal Motor Control Lab - Datalog DMA not working

Aric Gerspacher
Prodigy 120 points
Part Number: TMS320F280037C


Hello,

I have some custom hardware for driving a motor using the Universal Motor Control lab.

So far, I have verified the ADC's are working and calibrated, and the PWM's are functioning correctly in build level 1 and are trying to function correctly in build level 2.

However, I still have some issues getting the motors spinning correctly (motor loudly and slowly spins and draws maximum current).

I believe the ADC's are not quite properly calibrated. The offsets are calibrated, but they still swing between +/-25mA, which I suspect is confusing the control system.

Anyway, I need the datalog setup properly to help diagnose this issue, but the datalogs are not updating at all!

I have set up 4 channels on the datalog like so using the stock Universal Motor Control lab code:

I can watch the pointers, and they correctly point to the ADC data and the FOC angle.

However, the datalog buffers are filled with all zeroes, and of course CCS graphs all zeroes.

I did have to modify the code slightly because the stock code uses 16 bit integers instead of 32 bit floats for the datalog buffer, even though the ADC values are stored as floats and the code everywhere else expects a float.

Anyway, I don't think that's the problem.

Also, digging into this, I don't see any way the DMA actually uses the 'datalog parameters' at all ( the datalogObj->iptr[] ). The 'setupDMAforDLOG' uses the datalog buffer as both the receive and send for the DMA transfer. Therefore, I am totally at a loss as to figuring out how to resolve this issue. I would expect that 'setupDMAforDLOG would use the 'iptr' as a send for the DMA configuration. Maybe the setup is only to get the datalogBuff to wrap, and that begs the question: where is the data actually being passed?

I have used the other labs before on evaluation boards, and they all configure the DMA's in the same way (in 'setupDMAforDLGO',  using the datalogBuff#[0] as recv, and datalogBuff#[1] as send).

How do I get my datalogs working?

  • 0
    Prodigy 120 points

    EDIT: posting to these forums is my instant good luck charm...

    DMA is definitely used to wrap the datalog and the value is simply written to the last position in the datalog, called by the motor drive routine.

    The datalogBuff was not properly wrapping, only writing to position ~200, even though I had allocated more space. It looks like the system was expecting a 200 size buffer and was simply malfunctioning since it was not.

    Here are the settings I used (in datalogIF.h)

    #elif defined(DATALOGF4_EN)
#define DATA_LOG_BUFF_SIZE      200      //**20
#define DATA_SIZE_EXT           2       //

#define DATA_LOG_BUFF_NUM       4       // = 2 for F28002x or = 4 for other devices

#define DLOG_BURST_SIZE         20       // write 200 to the register for
                                         // a burst size of 20

#define DLOG_TRANSFER_SIZE      (1 + 2* DATA_LOG_BUFF_SIZE / DLOG_BURST_SIZE)//10       // [(MEM_BUFFER_SIZE/(BURST)]
#endif  // DATALOGI4_EN

#define DLOG_WRAP_SIZE          DLOG_TRANSFER_SIZE + 1

#define DATA_LOG_SCALE_FACTOR   10        // update every 10 times

    I had to search the entire lab, and change all 'DATALOGI4_EN' to 'DATALOGF4_EN' as well as change the 'int16_t' to 'float32_t' for all the 'datalogBuff'ers to get it working.

    Since I noticed only position 200 was being written to, and the DATALOGF2_EN version only used 200, I guessed that 200 was the size buffer the system was looking for, and it now properly wraps and displays graphs!