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.

Compiler/LAUNCHXL-F28069M: Standalone Instaspin project - Stuck in initial ADC calibration

Part Number: LAUNCHXL-F28069M
Other Parts Discussed in Thread: MOTORWARE, CCSTUDIO

Tool/software: TI C/C++ Compiler

Following this process , I created an independent Instaspin project which builds without errors. However, I am unable to run lab01.

I have LaunchXL-28069M kit and lab01, without the modifications for making a standalone project, runs well. So it is definitely a software problem.

With the independent project, the program gets stuck in HAL_AdcOffsetSelfCal() function inside HAL_Cal().

//Select VREFLO internal connection on B5
  ADC_enableVoltRefLoConv(obj->adcHandle);

  //Select channel B5 for all SOC
  HAL_AdcCalChanSelect(handle, ADC_SocChanNumber_B5);

  //Apply artificial offset (+80) to account for a negative offset that may reside in the ADC core
  ADC_setOffTrim(obj->adcHandle, 80);

  //Capture ADC conversion on VREFLO
  AdcConvMean = HAL_AdcCalConversion(handle);

Inside HAL_AdcCalConversion(), the program tries to sample all ADCs a few times to calculate mean offset.

ADC_setSocFrcWord(obj->adcHandle, 0x00FF);

  while( index < SampleSize )
    {
      //Wait for ADCINT1 to trigger, then add ADCRESULT0-7 registers to sum
      if (ADC_getIntFlag(obj->adcHandle, ADC_IntNumber_1) == 0){}

      //Must clear ADCINT1 flag since INT1CONT = 0
      ADC_clearIntFlag(obj->adcHandle, ADC_IntNumber_1);
 
      Sum += ADC_readResult(obj->adcHandle, ADC_ResultNumber_0);
      Sum += ADC_readResult(obj->adcHandle, ADC_ResultNumber_1);
      Sum += ADC_readResult(obj->adcHandle, ADC_ResultNumber_2);

This will enable a software trigger for ADC and on completion the mean will be calculated.

It appears that ADC_setSocFrcWord does not actually trigger a conversion and the program gets stuck at the ADCINtFLG check. I tried to comment it out, but immediately get a bad ISR interrupt. Any attempt to bypass or comment out this calibration leads to a bad ISR interrupt. As this exact code runs in the normal project, I am not sure where to check for bugs.

Any ideas on why this would happen ?

e2e.ti.com/.../529701

  • 1. Please make sure all files are ported and indexed correctly first, like the all driver header files, hal.h and .cmd files, especially check if the hal.h is for F2806xF/M.
    2. Ensure that HAL_acqAdcInt() is called in mainISR() to clear the ADC interrupt status flag for next entry.
    3. Ensure that the global interrupt is disable before HAL_setParams() was called.

    Would you like to have a detailed description about how did you port the project if you have any questions again? That maybe help me to understand your question.
  • 1. Yes I have checked the files and am fairly sure that hal.h is for F2806xF/M. As far as detailed description is concerned, the process mainly consisted of copying all included header files to /inc directory and editing paths. The project builds correctly, so it is not a case of unresolved references.
    2. Yes, HAL_acqAdcint() is called in mainISR. I did not modify that part.
    3. I think I need to try this. That might be why I get a badISR after commenting out ADC code.

    I'll try option 3 and let you know if it solves the issue.
  • Just wanted to check in and see if there is any update from your side. Please let me know if you have any questions. We would like to close this thread if no any further questions. Thanks.
  • Based on further work, this seems to be an issue with Motorware directory structure and location of files rather than an ADC issue.

    I made a new folder named test inside \sw\modules\hal\boards and copied hal.c from
    \sw\modules\hal\boards\boostxldrv8301_revB\f28x\f2806x\src into this folder.
    I made sure the directory structure was similar to default so the final location of hal.c was \sw\modules\hal\boards\test\f28x\f2806x\src.
    I removed the link to hal.c in lab01 and then linked the new hal.c. I verfied that the link was resolved properly in the project properties. The project compiled successfully.

    When I ran this modified project, it got stuck waiting for PLL to lock.

    When I ran lab01 unmodified, it ran successfully, so there was no issue with hardware, only software compile/link problem.

    I had made changes to hal.c for my project. If I placed modified hal.c in
    \sw\modules\hal\boards\boostxldrv8301_revB\f28x\f2806x\src, the project ran successfully with my changes. So it is not a question of error in my code.

    So it seems to be that, if the location of the file is changed from the default motorware structure, it compiles successfully but doesn't run and gets stuck either waiting for ADC interrupt or PLL to lock or sometimes even in flash init routine or something random.

    It is not a hardware issue, nor an issue with code but some linking or CCstudio issue.
    Have you observed this before ?

    If my problem is too vague, then you can close this thread. Sorry for the delay in providing an update.
  • You might check the hal.c and is correct in this lab project. Tested some lab projects that worked well. Let me know if you have any further questions. Thanks.
  • Thanks for your help. My problem is resolved and I have no problem changing directory structure and linking files.

    I don't know exactly why it did not work initially, must have been my inexperience. Everything's ok now.