RT1176 SDK 2.9.2 systick_utils.c Bug

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RT1176 SDK 2.9.2 systick_utils.c Bug

Jump to solution
1,512 Views
D_TTSA
Contributor V

Good day

I am using Embedded Artists' RT1176 uCOM and their adaptation of NXP's RT1176 v2.9.2 SDK.

After many days of testing, we discovered that there is a bug in BOARD_SystickElapsedTicks(). This bug causes the function to occasionally return a very large (and incorrect) 'elapsed' value. A screenshot of the SDK's function is shown below:

D_Tram23_0-1663769376324.png

When an overflow of the Systick counter occurs, Systick_Handler() executes, and increases g_ovf_counter. Typically, if this occurred before BOARD_SystickElapsedTicks() was called, then the first 'elapsed' var calculation would have a large negative number as a result. The second 'elapsed' var calculation would then add a larger number to 'elapsed', resulting in a positive number.

However, if this overflow occurred between these two calculations, then the first line would give 'elapsed' a positive number, and the second line would add a large positive offset. This would cause 'elapsed' to have a much larger value than it should, for only one call to BOARD_SystickElapsedTicks(). 

To fix this, we added a do-while() to check if an overflow has occurred during the ‘elapsed’ calculations. If so, we redo the calculations to ensure that the ‘elapsed’ value is correct.

The fixed BOARD_SystickElapsedTicks() can be seen below:

D_Tram23_1-1663769388913.png

I am posting this in the hope that NXP will fix their SDK as soon as possible.

In the mean time, I hope that this helps someone, because NXP could be a while...

0 Kudos
Reply
1 Solution
1,450 Views
D_TTSA
Contributor V

Good day @jeremyzhou 

I agree that the elapsed time period will be slightly longer than initially expected, since the ticks will keep running if we have to re-calculate the values.

However, I believe this will be a small (negligible) error margin.

I disagree with your code - you have just rewritten the original driver code with added "curr_val" and "rounded_over" variables. This will not address the problem at all.

The solution in my original post works.

View solution in original post

0 Kudos
Reply
4 Replies
1,493 Views
jeremyzhou
NXP Employee
NXP Employee

Hi @D_TTSA ,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
Firstly, I agree with you that the code is not good enough, however, I don't think your code fixes the bug.
Next, the key point is the systick always keeps running during the above two calculations, so to fix this, it should suspend the systick or disable the global interrupt when doing calculations.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply
1,489 Views
D_TTSA
Contributor V

Hi @jeremyzhou 

I disagree, this code does solve the problem.

If the tick occurs between the calculations here, we automatically redo the calculations (which will then have the correct result).

I have tested it and it works.

Suspending systicks could cause us to miss servicing an interrupt that occurs. Disabling global interrupts means we could miss other interrupts that are important to our system.

0 Kudos
Reply
1,469 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,

Assume the elapsed time period: time_1 is from the time point of calling BOARD_SystickStart to the BOARD_SystickElapsedTicks(), according to your modified code, if an overflow occurs between these two calculations, the elapsed time period will extend just as the below figure shows, because the systick is always working.

 

// ARM-core specific function to compute the elapsed systick timer ticks.
int32_t BOARD_SystickElapsedTicks(int32_t *pStart)
{
    int32_t elapsed;
    int32_t curr_val = SYST_CVR & 0x00FFFFFF;
    int32_t rounded_over = g_ovf_counter - g_ovf_stamp;

    elapsed= SYST_RVR * rounded_over+*pStart-curr_val;
    return elapsed;
}

 

jeremyzhou_0-1664161470587.png

So I'd like to suggest you can use the below code to optimize the function.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------))

0 Kudos
Reply
1,451 Views
D_TTSA
Contributor V

Good day @jeremyzhou 

I agree that the elapsed time period will be slightly longer than initially expected, since the ticks will keep running if we have to re-calculate the values.

However, I believe this will be a small (negligible) error margin.

I disagree with your code - you have just rewritten the original driver code with added "curr_val" and "rounded_over" variables. This will not address the problem at all.

The solution in my original post works.

0 Kudos
Reply