• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 926 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.

ADCIntClear() -- Running through debugger fails. Running without debugger works.

snellr
Intellectual 715 points

Other Parts Discussed in Thread: EK-TM4C123GXL, TM4C123GH6PM

  1. Using Windows 8 (compatibility for Win7) x64
  2. Using Code Composer Studio Version: 5.5.0.00077
  3. Using Tiva C LaunchPad EK-TM4C123GXL REV A
  4. Test Case/Diagnostic logs:  4670.6862.HFX219_archive.zip

Issue Summary:

The program structure is as follows:  A hardware timer triggers the ADC to start a sequence of 8 samples.  The ADC completion of 8 samples triggers an ADC processing interrupt.  The TI-RTOS runs in the background. (The two interrupts are registered static HWIs.)  When the ADC has completed 60 million samples [1MSPS*8 channels*60 seconds/(1 interrupt per 8 samples)], a semaphore triggers a task to turn the LED off.  As configured, the LED should turn off after 2 minutes (timer only triggers ADC at 50% max speed).  If the ADC were to run constantly then it would turn off after 1 minute.

The problem is that when I run the program in the debugger (even with no breakpoints), the ADCIntClear function only operates properly from the ADC initialization, but never from the interrupt handler.  Because the interrupt flag stays on, the ADC fires immediately after exiting the ISR every time, and the LED turns off after 1 minute.

On the contrary, if after downloading the code to the device, I just reset the board and let it run the code itself, then the program works fine--the ADC only triggers at the rate of the hardware timer and the LED turns off after 2 minutes as the code dictates.

I have observed the same problem without TI-RTOS, so I don't think that it is the source of the problem.  Also, I have observed the same problem on a Windows 7 machine, so I don't think Win8 is the problem.

Thanks!

  • 0
    TI__Guru**** 171449 points

    Hi,

    I was not able to reproduce this - i.e., with my CCSv5.5.0.00077 connected to my Launchpad (not sure which Rev), I was able to get the LED to turn off after 2 minutes.

    However, when I imported your project I had a few problems with undefined symbols - namely ADCSSFIFO0 at line 188 of the file <empty_min.c>. In order to be able to build the project, I changed the symbol above to ADC0_SSFIFO0_R, added #include "inc/tm4c123gh6pm.h"  and removed #include "inc/hw_ints.h" due to macro redefinitions.

    I am not 100% sure what could be causing either the runtime behavior or the invalid symbol specification, but it is possible that some component versions could be the root cause. In my setup I am using Tivaware 2.0.1.11577 and TI-RTOS 1.21.00.09 with XDC 3.25.04.88 and Compiler version 5.1.1.

    I send attached the project I modified.

    Hope this helps,

    Rafael

     

    HFS219.zip
  • 0 in reply to desouza
    Intellectual 715 points

    Hi Rafael,

    I apologize for the missing #define for ADCSSFIFO0.  It should be the lower half of ADCSSFIFO0_R.  Regardless, it's just for data processing.

    I just ran your project.  When I simply hit the "debug" button and then the green arrow to start the code execution, it takes 1 minute for the LED to go off.  Then I reset the board (reset button) and the LED took 2 minutes to go off.

    Can you confirm if the same steps give you the same results?

    Thanks.

  • 0 in reply to snellr
    TI__Guru**** 171449 points

    Hi,

    I also got 1 minute when I did exactly what you did, and 2 minutes when I terminated the debug session and power cycled the board. However, I played a bit with the sequence of debugging and type of code loaded. Here's what I found:

    1) Clicked on the "debug" button using your code. Got 1 minute until the LED went off.

    2) Terminated the Debug session (red button). Clicked on the "debug" button using your code. Got 1 minute until the LED went off again.

    3) Terminated the Debug session (red button). Power cycled the board. Clicked on the "debug" button using your code. Got 1 minute until the LED went off again.

    4) Terminated the Debug session (red button). Clicked on the "debug" button using the FreeRTOS demo. LED was happily blinking. 

    5) Terminated the Debug session (red button). Power cycled the board. LED was happily blinking with the FreeRTOS demo. Clicked on the "debug" button using your code. Got 2 minutes until the LED went off again.

    6) Terminated the Debug session (red button). Clicked on the "debug" button using your code. Got 1 minute until the LED went off again.

    7) Repeated steps 4 to 6 with the exact same results

    This seems to indicate there is an initialization step in your code that may be getting in the way of the normal processing of the ADC when the code is successively launched. Loading a different code (which does not perform the same initialization steps) and power cycling the board to guarantee a complete device reset makes the code run successfully.

    With that in mind and to save you from having to repeat steps 4 through 6 at every step on the way, I verified that System Reset (menu Run --> Reset --> System Reset) also clears enough of the previous initialization in order to allow a reloaded code to run in the expected way (2 minutes until the LED goes off).

    Therefore, this may be the workaround for this behavior. Unfortunately I am not an expert in the device to precisely know what may be wrong with the initialization routine, but this thread is already in the forum where the device experts are located.

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Expert 1775 points

    This issue of the debugger may be related to this issue.