When using a low-frequency system clock (such as 1M), CNT may exceed CMP in LPTIM_IRQHandler, so that the lptimer interrupt cannot be generated normally.

[likko-liu]

I use a Cortex-M4 processor with a 1Mhz main frequency, and lptimer uses an external 32.768khz crystal oscillator.

Assume that when the lptimer interrupt request occurs, the interrupt in the program is disabled or there is a higher priority interrupt to be processed. So when the LPTIM_IRQHandler function is called back for execution, there is already a delay.

At the beginning of the LPTIM_IRQHandler function, the cnt value of the lptimer at the current moment is obtained to obtain ulCountsLate and compare it with ulTimerCountsForOneTick.

If ulCountsLate <ulTimerCountsForOneTick at this moment (but ulCountsLate still has 4 or 5 counts that will satisfy ulCountsLate >=ulTimerCountsForOneTick), the code will execute the statement block that satisfies ulCountsLate <ulTimerCountsForOneTick, that is, the value of the CMP register will be changed, but this modification will not take effect immediately (it is implied to take effect when the LPTIM_ISR_CMPOK interrupt is generated).

When obtaining the cnt value and cmp modification successfully, due to the low system main frequency, this delay will be very long (in my example it takes a total of 198us), so that when the modification is successful, the CNT value may have exceeded the CMP value, so that the lptimer interrupt cannot be generated normally, so that the tickless processing code related to cnt and cmp is entered again, and an error occurs.

[likko-liu]

This fault troubled me for two weeks before I found it, so have you considered adding Numerical margin in

void LPTIM_IRQHandler( void )
{
...
if (ulCountsLate >= ulTimerCountsForOneTick &&
ulCountsLate < 65536UL - 1 - ulTimerCountsForOneTick &&
!isTickNowSuppressed)
...
if (ulCountsLate < ulTimerCountsForOneTick)
...

And suggest users to test: the time required from obtaining the cnt value to the cmp register being successfully modified

[likko-liu]

At the same time, the Application Requirements need to be modified to: You must ensure that the combination of your application's interrupt handler and the code in configPOST_SLEEP_PROCESSING() does not delay the tick ISR by more than [one tick minus the numerical margin] period. To help your application meet this requirement, consider setting configTICK_INTERRUPT_PRIORITY to configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY and ensure that configPOST_SLEEP_PROCESSING() is implemented so that it executes quickly. For an example, see vUlpPostSleepProcessing() .

[jefftenney]

@likko-liu I really appreciate you taking the time to research and report this issue, but I don't think you've identified the problem correctly.

Let me first re-state the issue you are reporting, just in case I misunderstood you. When LPTIM_IRQHandler() writes to CMP, it's possible that the corresponding update of the internal CMP register occurs after CNT reaches the new CMP value. In this case, the timer does not generate the CMPM interrupt. When the CMPM interrupt is missed in this way, "the tickless processing code related to cnt and cmp is entered again, and an error occurs."

Do I understand you correctly? If so, can you clarify the part in quotes? What tickless processing code do you mean? Does the tickless code go back to sleep when it shouldn't? Does it iterate in a loop when it shouldn't? What error occurs? Do you hit a configASSERT()?

Please note that the code in lptimTick.c is written to allow the late update of CMP that you describe. In that case, when the CMPOK interrupt occurs, LPTIM_IRQHandler() runs again and identifies and executes the tick. Remember that there are two interrupts, CMPM and CMPOK, both handled by the same interrupt handler.

[likko-liu]

yeah,i hit a configASSERT().
i save some variables when hit configASSERT().

xExpectedIdleTime: 00e0 -> 224
xFullTicksLeft: 03cd -> 973
ulCurrCount: 801e -> 32798
usIdealCmp: adfc -> 64685

i also saved the last ten times the program was executed "LPTIM->CMP = usIdealCmp == 0xFFFF ? 0 : usIdealCmp;" the value of usIdealCmp:
57115 -> 57148 -> 57181 -> 57214 -> 57246 -> 57279 -> 57312 -> 57345 -> 57377 -> 64685

can you spot some clues?

[likko-liu]

and there is no interrupt processing in my program that exceeds 1ms, even when i use a low frequency of 1Mhz.

[jefftenney]

Based on your evidence, I assume you are hitting this configASSERT():

    //      Verify that we calculated a sensible number of full ticks remaining in the expected idle
    // time.  If this assertion fails, then the tick ISR was delayed too long by other ISR(s).  You
    // must either reduce the execution times of your ISRs, decrease their priorities, or increase the
    // priority of the tick ISR.  See the description of configTICK_INTERRUPT_PRIORITY for details.
    //
    configASSERT( xFullTicksLeft < xExpectedIdleTime );

Does the comment above help you to resolve the issue? The comment offers three different options for you. A fourth option is to reduce the execution time of configPOST_SLEEP_PROCESSING(), since that macro also delays execution of the tick ISR. Can you share your implementation of configPOST_SLEEP_PROCESSING()?

[likko-liu]

In the previous fault reproduction, it can be found that when configASSERT() is triggered, LPTIM->CNT is already ahead of LPTIM->CMP by about several hundred milliseconds (you can see my last comment to get the values ​​of these variables when the fault is reproduced).

So, I guess there are two possible problems:

1. After entering vPortSuppressTicksAndSleep(): This is the problem that the four solutions in the code comments mentioned in your comment are targeting;

2. Before entering vPortSuppressTicksAndSleep(): You must know that before vPortSuppressTicksAndSleep(), lptimer will always generate a CMPM interrupt request every 1ms (not strictly 1ms), so if there is an error, resulting in no CMPM interrupt request for several hundred milliseconds, when the program enters vPortSuppressTicksAndSleep() and is awakened for the first time by other interrupts that cause task scheduling, configASSERT() will be triggered.

So, yesterday I added a process to get the LPTIM->CNT value at the beginning of vPortSuppressTicksAndSleep()

void vPortSuppressTicksAndSleep( TickType_t xExpectedIdleTime )
{
if (xExpectedIdleTime > xMaximumSuppressedTicks)
{
xExpectedIdleTime = xMaximumSuppressedTicks;
}

uint32_t ulCountStart;
do ulCountStart = LPTIM->CNT; while (ulCountStart != LPTIM->CNT);

Today, I reproduced the failure and got the variables saved when the failure occurred:
xExpectedIdleTime: 0037 -> 55
xFullTicksLeft: 0724 -> 1828
ulCurrCount: 91d1 -> 37329
usIdealCmp: 7bd4 -> 31700

START (LPTIM->CNT value obtained when vPortSuppressTicksAndSleep() starts executing): 81ee -> 33262

ausIdealCmp:
29668 -> 29701 -> 29734 -> 29767 -> 29800 -> 29832 -> 29865 -> 29898 -> 29931 -> 31700

33 ..33 .. 33 .. 33 .. 32 .. 33 .. 33 .. 33 .. 1769(53)

You can find "33262" (START), that is, the LPTIM->CNT value obtained when entering vPortSuppressTicksAndSleep() before the failure occurs, is ahead of "29931" (the value of LPTIM->CMP when entering vPortSuppressTicksAndSleep() before the failure occurs).

Therefore, the second guess I mentioned earlier is confirmed.

[likko-liu]

There is another key information. When executing LPTIM_IRQHandler( void ) at 1Mhz,

...
usIdealCmp += ulNumCounts; // usIdealCmp is a uint16_t
usIndex = (usIndex + 1) % 10;
ausIdealCmpRecord[usIndex] = 0xFFFF;
if (!isCmpWriteInProgress)
{
LPTIM->CMP = usIdealCmp == 0xFFFF ? 0 : usIdealCmp; // never write 0xFFFF to CMP (HW rule)
isCmpWriteInProgress = pdTRUE;
ausIdealCmpRecord[usIndex] = usIdealCmp == 0xFFFF ? 0 : usIdealCmp;
}

// Tell the OS about the tick. We don't need to bother saving and restoring the current BASEPRI 
// setting because (1) we cannot possibly already be in a critical section and (2) the NVIC won't take 
// interrupts of lower priority than LPTIM even when we set BASEPRI to zero until our ISR ends. 
// 
portDISABLE_INTERRUPTS(); 
BaseType_t xWasHigherPriorityTaskWoken = xTaskIncrementTick(); 
portENABLE_INTERRUPTS(); 

portYIELD_FROM_ISR(xWasHigherPriorityTaskWoken); 
}
...

After executing LPTIM->CMP = usIdealCmp == 0xFFFF ? 0 : usIdealCmp; in the above code, due to the low frequency of 1Mhz, the execution

portDISABLE_INTERRUPTS(); 
BaseType_t xWasHigherPriorityTaskWoken = xTaskIncrementTick();
portENABLE_INTERRUPTS();

portYIELD_FROM_ISR(xWasHigherPriorityTaskWoken);

The time will be as long as about 80us. After the execution is completed, the interrupt request of LPTIM_ISR_CMPOK has arrived, so after executing the above code, the interrupt callback processing will not be exited (and at 16Mhz, the above code is executed faster, so that the interrupt request of LPTIM_ISR_CMPOK has not arrived, so it will exit the interrupt callback processing) and then execute

if (LPTIM->ISR & LPTIM_ISR_CMPOK)
{
// Acknowledge and clear the CMPOK event.
//
LPTIM->ICR = LPTIM_ICR_CMPOKCF;

// If there is a "pending" write operation to CMP, do it now. Otherwise, make note that the write
// is now complete. Remember to watch for CMP set to 0 when usIdealCmp is 0xFFFF. There's no pending 
// write in that case. 
// 
if ((uint16_t)(LPTIM->CMP - usIdealCmp) > 1UL) 
{ 
LPTIM->CMP = usIdealCmp == 0xFFFF ? 0 : usIdealCmp; // never write 0xFFFF to CMP (HW rule) 
usIndex = (usIndex + 1) % 10; 
ausIdealCmpRecord[usIndex] = usIdealCmp == 0xFFFF ? 0 : usIdealCmp; 
// isCmpWriteInProgress = pdTRUE; // already true here in the handler for write completed 
} 
else 
{ 
isCmpWriteInProgress = pdFALSE; 
} }

However, in the above code, only the CMPOK interrupt request flag of the peripheral lptimer is cleared, and the interrupt pending status flag of the NVIC lptimer is not cleared. As a result, after the above exit from this interrupt callback is executed, the lptimer interrupt callback will be entered again because the interrupt pending status flag of the NVIC lptimer is not cleared (you can find out why this process is like this in the "NVIC can work with pulsed interrupt
requests" section in "The Definitive Guide to ARM® Cortex®-M3 and Cortex®-M4 Processors, Third Edition - 7.6 Interrupt inputs and pending behaviors"). However, when entering the interrupt callback again, LPTIM_ISR_CMPOK and LPTIM_ISR_CMPM are not set (cleared in the previous interrupt callback).

I think this timing seems to have deviated from your design. Should I abandon the 1Mhz main frequency and use a higher main frequency to ensure normal timing? Or add constraints in LPTIM_IRQHandler( void ) to ensure normal timing?

[jefftenney]

The code in LPTIM_IRQHandler() naturally tolerates the interrupt-pending status in the NVIC remaining set after the ISR ends. The ISR simply executes again, which clears the pending status. The ISR does nothing else in this case. No harm done. No issue. Are you seeing something different?

Regarding the previous post, you have a good idea to capture the start value of CNT. I wonder if the debugger is lying to you since ulCountStart is simply a local variable, presumably not used after it is captured at the top of the function. The compiler might be reusing that local field (register / stack location) later in the function. If you change the declaration from uint32_t ulCountStart; to static volatile uint32_t ulCountStart; you can eliminate this concern.

Meanwhile I'll find some time to review this code again, assuming your start value of CNT is correct.

[jefftenney]

@likko-liu Can you share your project? I spent some time considering the code using a slow 1 MHz clore clock. But I couldn't identify any new issues just by code review. All I could see was the same old issue of your code possibly causing the tick ISR to be delayed too long, but you already know about that. I can't see any other way the tick interrupts would just stop. To look deeper, I'm hoping your code can help shrink the search area for me.

Can you also tell me what core clock frequency makes this problem go away (approximately)? Is 2 MHz enough? 4 MHz? 8 MHz?

[likko-liu]

Regarding my scheme to capture the start value of CNT, I did not use the debugger to get the value of ulCountStart when a fault occurs, but recorded its value in Flash when the system fails (it will only be dumped to Falsh when the system fails, otherwise it is just in RAM, and the recorded values ​​also include the previously mentioned xExpectedIdleTime, xFullTicksLeft, ulCurrCount, usIdealCmp), and then the system will be stuck in assertion failure until the watchdog resets.

When I checked the device again, I found the watchdog reset event and got those values ​​in Flash, so the accuracy of those values ​​can be guaranteed.

In addition, this is not my personal project, so unfortunately I don’t have the permission to share the project code with you.

In addition, I also thought of increasing the system frequency to make its timing consistent with the 16Mhz timing to see if it will still trigger assertion failure, but I haven’t had time to modify the code for experiment (because now I am on weekend break).

Although I can't share the project code with you, I will sort out all the interrupt times and timings next Tuesday to give you more information.

[jefftenney]

I have set up a branch for experiments we decide to try. An I have an experiment ready for you to try. See 78f0ff2. I don't think it will make any difference, but I do like the code better with this change. I would appreciate you trying this code in addition to your other experiments.

Two additional thoughts for you. (1) It might save time and help us find answers if you ask permission to let me review the project code. (2) The 1 MHz core clock does make it more difficult to meet system requirements related to delaying the tick ISR for too long. Your first post indicates you've already found cases that are close to the limit. Maybe there are cases you haven't yet found that are over the limit.

[likko-liu]

Sorry, I still don't have permission to show you the project code.

However, I have now upgraded two firmware versions for the two devices:

1. Increase the operating frequency from 1MHz to 2Mhz (I found that the lptimer interrupt timing at 2Mhz can be consistent with the timing at 16Mhz),

2. Apply your changes in 78f0ff2 to the project code.

The code modifications of the above two firmware versions are not included in each other. Next, we have to wait to see if the fault can be reproduced. According to previous experience, this reproduction process may take up to 7~8 days of continuous operation of the device.

[likko-liu]

Previously, I told you that I tested two devices by upgrading two different versions of the firmware package:

1. Increasing the operating frequency from 1MHz to 2Mhz (I found that the lptimer interrupt timing at 2Mhz can be consistent with the timing at 16Mhz),
2. Applying the changes in 78f0ff2 to the project code.

Now, for the first modification mentioned above (increasing the operating frequency from 1MHz to 2Mhz), the tester gave me feedback on the test results. So far, the device has persisted for 11 days and 15 hours without a reset, so now it can be basically considered that the frequency increase has significantly improved this fault (I even think it can be said that it has completely solved this fault).

However, the second modification mentioned above (applying the changes in 78f0ff2 to the project code) found that the device upgraded to this version of the firmware had a power outage a few days ago due to insufficient battery power, so I still need some time to verify the second modification.

[jefftenney]

Thank you. This is useful testing, and I look forward to your additional results. You might also consider adding a "control" DUT running the firmware without either change. We would expect this DUT to encounter the failure, and maybe more than once. Just an idea.