• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 83 subscribers
  • Views 367 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.

TMS320F280049C: TMS320F280049C

Thomas Hecht
Expert 1080 points

Part Number: TMS320F280049C
Other Parts Discussed in Thread: C2000WARE, , DRV8323

Tool/software:

Hello,
I use the TMS320F280049C in conjunction with the CCS v12. My project is based on the is07 project of C2000Ware_MotorControl_SDK_5_02_00_00.
The hardware is an in-house development based on the Evalboard of the TMS320F280049C and the DRV8323 board. A BLDC motor is controlled. Now the following happens from time to time: The motor runs at the specified speed, then suddenly stops and the current consumption increases rapidly. If you now set a breakpoint in the mainISR, you realise that the code is no longer executed. However, the for(;;) loop continues to run, as do the Timer_ISR, the I2C_ISR and the analogue measured values are also still updated, only the mainISR() is no longer executed. The software sequence is taken from Lab is07 (PWM triggers ADC, when ADC SOC ready then trigger mainISR). Do you have an idea how to debug this error (are there CCS tools) or what could be the cause?

The following changes have been made
- SCI interrupt routine for RX data
- I2C interrupt routine
- acknowledge of mainISR() at the end of the interrupt routine

mainISR()
{
motorVars.pwmISRCount++;

//
// toggle status LED
//
counterLED++;

#ifdef EVALBOARD
if(counterLED > (uint32_t)(USER_ISR_FREQ_Hz / LED_BLINK_FREQ_Hz))
{
HAL_toggleLED(halHandle, HAL_GPIO_LED2);
counterLED = 0;
}
#endif
//
// acknowledge the ADC interrupt
//
// HAL_ackADCInt( halHandle, ADC_INT_NUMBER1 );

//
// read the ADC data with offsets
//
HAL_readADCDataWithOffsets( halHandle, &adcData );
:
:
//
// Force trig DMA channel to save the data
//
HAL_trigDlogWithDMA( halHandle, 0 );
HAL_trigDlogWithDMA( halHandle, 1 );
HAL_trigDlogWithDMA( halHandle, 2 );
HAL_trigDlogWithDMA( halHandle, 3 );
#endif // DATALOG_ENABLE

#ifdef _STEP_RESPONSE_EN_
// Collect predefined data into arrays
GRAPH_DATA(&gGraphVars, &gStepVars);
#endif // _STEP_RESPONSE_EN_

//
// acknowledge the ADC interrupt
//
HAL_ackADCInt( halHandle, ADC_INT_NUMBER1 );

return;
} // end of mainISR() function


Best regards

Thomas

  • 0
    TI__Genius 11076 points

    Thomas,

    Based on your description, it sounds like for one cycle, the ISR execution time is longer than the ISR period. With the acknowledge at the end of the function, this means that the first time this happens and the ISR does not reach this function in time, it will never execute again.

    I would lower your ISR frequency, shorten it, and/or move the ack to the beginning.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Expert 1080 points

    Hello Jason
    so far my understanding was that when an interrupt is triggered, further interrupts from that source are disabled then the code jumps into the ISR, now if the same source generates further interrupts, they remain pending and remain disabled until the interrupt acknowledge comes.
    If the acknowledge is triggered at the end of the ISR, it is ensured that the code in the ISR is processed undisturbed.
    When the acknowledge is set at the beginning of the ISR, it can happen that the ISR is not processed, of course this only occurs if the time between the ISR calls is shorter than the execution time for the ISR itself, which should not actually happen.

    So is this more of a philosophical question - or is there a justified advantage to placing the acknowledgement at the beginning of the ISR?

    But in no case should the cyclic call of the ISR be cancelled or stoped.

    best regards
    Thomas

  • 0 in reply to Thomas Hecht
    Guru 56298 points

    Hi Thomas

    Thomas Hecht said:
    So is this more of a philosophical question - or is there a justified advantage to placing the acknowledgement at the beginning of the ISR?

    Yet the Technical Resource Manual (TRM) states to place group ACK at the end of the ISR contrary to SDK examples.

    The example cleared the ISR and group ACK upon ISR entrance 12.5µs FAST loop. We also moved group ACK to end of ISR similar to your original thoughts above. Is it possible the symptom due to another nested ISR that randomly interferes with core group priority order? Such as SCI or SPI interrupts within the same ADC group.

    BTW: Still need to clear the ADC interrupt top of the ISR to stop reentrance most all interrupt handlers, group ACK near the end. 

  • 0 in reply to Genatco
    TI__Genius 11076 points

    Thomas and all,

    Apologies, I was oversimplifying for ease of explanation- perhaps too much! The long and short of the issue (as I understand it) is that the ADC interrupt is overflowing, and there are some known conditions where an ADC interrupt overflow will cause the device to fail to trigger additional ADC interrupts- this can happen when the ADC interrupt acknowledge and the next ADC interrupt trigger are happening at the same time.

    Refer to the following device silicon errata for the 004x, section title "ADC: Interrupts may Stop if INTxCONT (Continue-to-Interrupt Mode) is not Set"

    https://www.ti.com/lit/er/sprz439h/sprz439h.pdf

    When the ack is placed at the beginning of the interrupt, this becomes significantly less likely. (Alternatively, as the errata section title indicates, setting continue-to-interrupt mode should also avoid this particular issue.)

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Expert 1080 points

    Firstly, thank you very much,
    I investigated the phenomenon a little further (with some digital outputs and an oscilloscope), I just wanted to know what was ‘slowing down’ the system. It turned out that the background loop could not be interrupted by the mainISR (from time to time). This was due to the call of the function ‘ADC_getTemperatureC’, in this function two calls (offset and gain) are made to the OPT memory. If you read these values once during initialisation and save them in variables, which are then used for the calculation, everything works as desired.

    Thanks again for the backgound information of the ADC interrupt. I will put the interrupt acknowledge back at the beginning.
    Best regards
    Thomas