• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 39 subscribers
  • Views 2050 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.

CC3220SF-LAUNCHXL: Call to Timer_open() leads to an ISR fault

Benjamin Alix
Prodigy 250 points
Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: CC3220SF, UNIFLASH

Hi,

I'm using hardware timers on the TICC3220 but every time I try to call the Timer_open() function it leads to an ISR fault, here is the initialization of my timer : 

void time_hardware_timer_initialize(void)
{
  Timer_Params_init(&params);
  params.periodUnits = Timer_PERIOD_HZ;
  params.period = TC_CLOCK;
  params.timerMode  = Timer_CONTINUOUS_CALLBACK;
  params.timerCallback = timerCallback;
  
  timer0 = Timer_open(Board_TIMER0, &params);
  
  if (timer0 == NULL) {
    /* Failed to initialized timer */
    while (1);
  }
  
  if (Timer_start(timer0) == Timer_STATUS_ERROR) {
    /* Failed to start timer */
    while (1);
  }
}

As stated in the documentation, before making any call to the timer API, I do a Timer_init() (which is in my main).

I also got this problem when running the example application "timerled".

Is there something missing in my initialization code ?

Regards

  • 0
    TI__Expert 8255 points
    Hi Benjamin,

    If I understand correctly, when you run the "timerled" example on the CC3220SF you are seeing an ISR fault? Which SDK version is being used?
  • 0 in reply to Austin Tanner
    Prodigy 250 points
    Hi Austin,

    Yes that's it, I'm using the SimplLink CC3220 SDK 1.50.00.06.
  • 0 in reply to Austin Tanner
    Prodigy 250 points
    Correction : when I say that I was the running the timerled example, in fact I replaced my main function with the one provided in the example. So this might not be a good use case.

    So I opened the workspace in the SDK and I was able to compile and run it on my board (there are still some issues with the examples provided by the SDK, like wrong include paths). The example ran without provoking ISR fault, so there is something wrong only with my project.

    Sorry if there were any misunderstanding.
  • 0 in reply to Benjamin Alix
    TI__Expert 8255 points
    Hi Benjamin,

    Did you download SDK version 1.60, yet? My guess is the errors from the wrong include paths may be caused by automatically importing include paths used in the 1.60 SDK, which are not compatible with the 1.50 SDK.

    I also just ran the timerled example using version 1.50 and did not see any issues. My guess is there is an issue with your project, so please review the timerled example closely comparing the differences with your project.
  • 0 in reply to Austin Tanner
    Prodigy 250 points

    Hi Austin,

    I will download and try the 1.60 SDK.

    I think that I found out how the ISR fault appears. When I work I plug the board to the host PC, I build my project and launch a debug session. Whenever I need to correct my code, I simply stop the debugging session, compile/build my code and relaunch the session (by the way I use IAR 8.11.1). This worked great until now because it seems that with the timers I can't relaunch a debugging session : this is how the ISR fault appears.

    So the only workaround I have is to plug the board, compile/debug my project and if I have to modify the code and relaunch a debug session, I'm forced to unplug and replug the board. And now I don't have any ISR fault.

    Do you know why I have to unplug and replug the board ? Why stopping the debug session could cause this ?

    If you want I will try to identify which instructions seems to raise this fault.

  • 0 in reply to Austin Tanner
    Prodigy 250 points

    Hi Austin,

    Just a little update, in a debug session I managed to get the call stack in which case it seems to lead to a ISR fault :

    For now I don't know what does IntEnable() do because the source code is not compiled in my IAR project.

    Apart from that, nothing changed, the fault appears only after a first successful debug session. Like before, if I unplug and then replug the board, it will run as expected.

  • 0 in reply to Austin Tanner
    Prodigy 250 points

    Hi Austin,

    In order to debug this I would like to implement a fault handler, I have a colleague that gave me some code from another project (with an STM32 I think) that print the content of the CPU registers, I tried to adapt this to the TI API but the implementation of the printf prevent me from being able to print anything because there is some dynamic memory allocation.

    Do you know any other way to print or at least retrieve the content of the CPU registers ?

  • 0 in reply to Austin Tanner
    Prodigy 250 points
    One of my colleague is suspecting that the issue comes from the IAR debugger, we found out the following :

    "When the project is placed in FLASH memory using UNIFLASH, it runs properly every time. With a power-on reset, or pressing the RESET switch.

    When the project is downloaded into RAM using the debugger after a power-on RESET, the project runs fine.
    If the debugger is halted, and the project is downloaded into RAM a second time and started, we see a hard fault.

    The INVSTATE bit is set and the stacked link register points to the first element of a const array for the timer configuration.

    We suspect that const variables may not be being initialized properly by the debugger, but get initialized properly when the application is copied from FLASH to RAM when the power-on reset happens."

    The const variable appears to be a Timer_config data structure.
  • 0 in reply to Benjamin Alix
    Prodigy 250 points
    Marking thread as resolved.

    We found out that one of our functions in our application was in fact trying to access the timer before calling Timer_init() and initializing the timer.