micros() is non-monotonic

[Khalinda]

I was benchmarking some floating point operations on a CH32V307 chip and I was getting crazy results. The following sketch illustrates the problem:

uint32_t au32Time[1000];

void setup()
{
	int i;

	Serial.begin(115200);
	delay(1000);
	for(i=0;i<1000;i++)
		au32Time[i]=micros();
	for(i=0;i<1000;i++)
		Serial.println(au32Time[i]);
}

void loop(){}

The output starts out with:

1000998
1000996
1000994
1000992
1000990

And about half way down, this happens:

1000005
1000003
1000001
1001998
1001996
1001994

The counts should be strictly increasing. I haven't looked at the CH32 core, but in the Arduino core, micros() is essentially calculated from millis(). There seems to be an arithmetic error in the CH32 version. I tested this sketch on versions 1.0.3 and 1.0.4 and I obtained the same results.

[Khalinda]

I tracked down the CH32 source code for micros(). It just calls getCurrentMicros, which is found in clock.c. The code appears to have been written assuming that SysTick counts down. However, in hw_config.c, the SysTick CTRL register is set to 0xF, which configures SysTick to count up. I modified getCurrentMicros, replacing two lines of code as follows:

uint32_t getCurrentMicros(void)
{
  
  uint64_t m0 = GetTick();
  __IO uint64_t u0 = SysTick->CNT;
  uint64_t m1 = GetTick();
  __IO uint32_t u1 = SysTick->CNT;   //may be a interruption
   uint64_t tms = SysTick->CMP + 1;

  if (m1 != m0) {
//    return (m1 * 1000 + ((tms - u1) * 1000) / tms);
    return m1 * 1000 + u1 * 1000 / tms;
  } else {
//    return (m0 * 1000 + ((tms - u0) * 1000) / tms);
    return m0 * 1000 + u0 * 1000 / tms;
  }
}

That appears to work correctly, at least on the CH32V307 chip.

The SysTick timer on the CH32V10x processors is different, and it is configured differently. Unfortunately, I do not have a CH32V103 chip to test with, and the RISC-V SysTick registers are not documented in the CH32V10x Reference Manual, so exercise caution if you decide to apply this change.

[Khalinda]

I purchased a CH32V103C8T6 board, and I am experiencing the same problem with non-monotonic micros() output. The CH32V103 Systick device has 32-bit high and low count registers, so it is not code compatible with the other CH32V chips. There is separate code for the CH32V103 chips further down in clock.c. I made a similar change to that code and it seems to correct the problem.

uint32_t getCurrentMicros(void)
{
  
  uint64_t m0 = GetTick();
  uint64_t u0 = *((__IO uint32_t *)SYSTICK_CNTH);  
           u0 = (u0 << 32) + *((__IO uint32_t *)SYSTICK_CNTL);
  
  uint64_t m1 = GetTick();
  uint64_t u1 = *((__IO uint32_t *)SYSTICK_CNTH); //may be a interruption
           u1 = (u1 << 32) + *((__IO uint32_t *)SYSTICK_CNTL);

  uint64_t tms = *((__IO uint32_t *)SYSTICK_CMPH);
           tms = (tms << 32) + *((__IO uint32_t *)SYSTICK_CMPL) + 1;     

  if (m1 != m0) {
//    return (m1 * 1000 + ((tms - u1) * 1000) / tms);
    return m1 * 1000 + u1 * 1000 / tms;

  } else {
//    return (m0 * 1000 + ((tms - u0) * 1000) / tms);
    return m0 * 1000 + u0 * 1000 / tms;
  }
}

In my previous post, I noted that the Systick device was not documented in the WCH reference manuals. The Systick device is part of the RISC-V core, so it is documented in the (V2, V3, etc.) QingKe RISC-V microprocessor manuals instead.

[yangliangquan]

There is indeed such a problem. This formula should be the calculation method for the SysTick counter in the decrement mode. However, our SysTick counting method is set to increment by default, which is why the value of microseconds within the same millisecond cycle decreases. We will correct this issue. Thank you very much.

[maxint-rd]

Excellent fix. Thanks @Khalinda!

It took me a while to get at it, but just now I tested it for the V003 and the V002, where it was also the problem. After fixing the code in clock.c it performs as it should. Great!

---

In addition to this fix, I think the same piece of code has room for improvement in both flash size and in execution speed!

Gaining flash size
I encountered this issue while testing manual optimizations to reduce flash usage of the V002. The getCurrentMicros() function in clock.c that is used by micros() uses 64-bit variables in a division. This causes the compiler to include a call to the relatively large __udivdi3 function. delayMicroseconds() in wiring.time.h uses it as well.
Avoiding that call by using 32-bit variables saves over 1KB of valuable flash memory. This makes the V002, V003 and similar size processors much more usable whenever micros() is used. Since all registers involved are 32-bit in size, I see no real need to use 64-bit variables, except for perhaps the length of the roll-over (the implementation includes multiplication by 1000 to make micros out of millis).

Test results: smaller and faster
A CH32V003 test based on the example at top with added print of differences and test of delayMicroseconds() using optimization -Os gave a binary of 7424 bytes, with -Os and LTO it was 6384 bytes. (See #204 for a guide on getting LTO to work). The time differences between recorded micros in the for-loop were 19-27us, mostly 24-27us (17-27us with LTO).

After changing getCurrentMicros() and delayMicroseconds() to use 32-bit variables, the binaries shrank to 5624 bytes with just -Os and 4624 bytes with LTO. Execution time seemed much faster too: 5-8us (with LTO: 3-7us),

For the CH32V002 (with manual core optimizations) the same sketch resulted in 5988 bytes with just -Os and 5012 bytes with LTO. Execution seems a bit slower: 7-12us loop-differences (5-10us with LTO).

Largest flash-size wins
According the .map file these were the object-sizes of functions causing the large difference in flash usage when using 32-bit variables:

• __udivdi3- 1266 byte [0x4f2]
• __muldi3 - 106 bytes [0x6a]
• __clz_tab - 256 bytes [0x100]
  Total size (with -Os on the V003 ): 1628 bytes. 7424-5624=1800 bytes (extra savings perhaps due to intermediate function calls and alignment).