Когда я начал работать с CH32V203G6U6 и обнаружил, что там есть 64-битный аппаратный таймер, то подумал: ух, это же отлично, раз таймер аппаратный, то и о чтении/записи заботится сам микроконтроллер. И какое-то время это не вызывало вопросов. А потом…

А потом испытатели изделия, которое содержит устройство с этим МК, «мягко» заявили, что устройство не работает. Из логов конечного изделия было видно, что uptime устройства, который должен был монотонно возрастать, превратился в кривую.

Ну окей, подумал я, давайте разбираться. Видим сброс времени по логам, видим нештатное снаружи. Первая мысль: гуляем по памяти. Тем более что операций с памятью в коде с помощью указателей предостаточно. Анализ кода позволил найти некоторые потенциальные ошибки в работе с указателями, но их фикс ситуацию не изменил. Какие ещё варианты: watchdog или hard fault. Ни то ни другое не подтвердилось — устройство не перезагружалось. Описали проблему коллегам, которые уже работали с этим микроконтроллером, но получили примерно следующий ответ: не используйте SysTick, возьмите какой-нибудь TIM. Да, совет оказался рабочим, но что за фокусы?!

Понаставили брейкпойнтов и в конце концов поймали момент скачка. Стабильности и повторяемости не было, мы могли увидеть скачок то в первую минуту, то через час. В дебаге увидели, что uptime содержит значение, которого в этот момент там быть не должно. Было приятно — поймали всё-таки, но ясности не прибавилось. Тем не менее при очередной остановке, ковыряясь в цепочке вычислений, мы обнаружили, что в регистрах SysTick лежит не то же самое значение, что в uptime. Посчитали, покрутили биты, появилось предложение по воспроизведению ошибки: заполнить младшие 32 бита счётчика. И снова ждать, на этот раз случилось быстрее. Потом ещё и ещё.

Лучшее, что можно сделать с ошибкой, не считая её исправления, — научиться воспроизводить.

Проблема возникает в момент чтения 64-битного счётчика SysTick->CNT. Было очевидно, что нужно всего-то запретить прерывания на время чтения. Окружаем чтение классическим набором __disable_irq() / __enable_irq(), и… ничего, ничего не меняется в конечном поведении…

Тогда, год назад, мы оставили дальнейшие попытки разобраться, время поджимало, TIM4 работал исправно (и до сих пор работает).

Но вот, у меня появились время и ChatGPT, и я решил разворошить старое.

Почему обычное чтение не работает

Тогда всю критичность мышления подавила вера в то, что МК сам заботится о чтении этого регистра, но 64-битное значение нельзя прочитать одной обычной операцией: ядро всё равно отдельно читает младшие и старшие 32 бита, STK_CNTL и STK_CNTH соответственно.

В стандартном заголовочном файле WCH поле CNT структуры SysTick_Type объявлено как volatile uint64_t. Поэтому строка

uint64_t ticks = SysTick->CNT;

выглядит как одно чтение. Ключевое слово volatile гарантирует, что компилятор действительно обратится к аппаратным регистрам и не удалит эти операции. Но оно не объединяет два обращения в одну атомарную операцию. И для 32-битного ядра это всё равно две отдельные инструкции: одна читает младшие 32 бита из STK_CNTL, а другая — старшие из STK_CNTH. Между этими чтениями проходит пусть небольшое, но не нулевое время. Вот тут-то и порылась собака.

Проблема возникает, если STK_CNTL переполняется между двумя чтениями. Например, счётчик переходит из состояния

CNTH = 0x00000015
CNTL = 0xFFFFFFFF

в состояние

CNTH = 0x00000016
CNTL = 0x00000000

Предположим, ядро сначала прочитало CNTL и получило 0xFFFFFFFF. Сразу после этого произошёл перенос, и при чтении CNTH ядро получило уже 0x00000016. В результате программа соберёт:

ticks = 0x00000016FFFFFFFF

Такого состояния у счётчика в течение этих двух чтений не было: первое значение находилось около 0x00000015FFFFFFFF, а второе — около 0x0000001600000000. Склеенный результат опережает реальное время почти на 2^32 тактов. Следующее чтение снова даст нормальное значение, и uptime резко вернётся назад.

Если SysTick тактируется от HCLK с частотой 96 МГц, младшие 32 бита переполняются через 2^32 / 96 000 000 ≈ 44,739 с. Это не означает, что ошибка будет возникать при каждом переполнении. Опасное окно занимает всего несколько машинных инструкций, поэтому дефект может проявляться редко и выглядеть случайным.

Так как же читать SysTick правильно?

Нужно дважды прочитать старшую часть и убедиться, что между чтениями она не изменилась.

Если CNTH не изменился, прочитанное значение CNTL соответствует той же старшей части счётчика. Если изменился, значит, CNTL успел переполниться и его нужно прочитать ещё раз — уже для нового значения CNTH.

#include "ch32v20x.h"

#define SYSTICK_CNTL                                                   \
    (*(volatile uint32_t *)((uintptr_t)&SysTick->CNT))

#define SYSTICK_CNTH                                                   \
    (*(volatile uint32_t *)((uintptr_t)&SysTick->CNT + sizeof(uint32_t)))

uint64_t systick_get_ticks(void)
{
    const uint32_t hi_before = SYSTICK_CNTH;
    uint32_t lo              = SYSTICK_CNTL;
    const uint32_t hi_after  = SYSTICK_CNTH;

    if (hi_before != hi_after)
    {
        lo = SYSTICK_CNTL;
    }

    return ((uint64_t)hi_after << 32) | lo;
}

Выполняются три обязательных чтения и, при попадании в узкое окно переполнения, одно дополнительное. Алгоритм предполагает, что CNTL не переполнится дважды за время выполнения функции. Проверка CNTH → CNTL → CNTH обеспечивает согласованность самого значения, а запрет прерываний нужен, чтобы ограничить время выполнения этой последовательности.

Доверяй, но прерывай

Если чуть развить мысль про прерывания, то становится понятно, что между чтениями может вклиниться обработчик прерывания и задержать выполнение функции systick_get_ticks(). А на этот раз хочется доверять счётчику.

Чтобы исключить такую задержку, на время чтения можно запретить прерывания. На первый взгляд достаточно окружить чтение привычной парой вызовов __disable_irq() / __enable_irq(). Загвоздка в том, что __enable_irq() безусловно разрешает прерывания, а не восстанавливает состояние, существовавшее до вызова __disable_irq(). Например, systick_get_ticks() может быть вызвана из более крупной критической секции:

__disable_irq();

update_shared_data();
const uint64_t ticks = systick_get_ticks();
finish_update();

__enable_irq();

То есть если внутри systick_get_ticks() безусловно вызвать __enable_irq(), прерывания включатся раньше, чем ожидает вызывающий код, — ещё до finish_update(). Такая же проблема возникает при вложенных вызовах и при вызове функции из обработчика прерывания.

Поэтому функция должна не просто выключить прерывания, а выполнить три действия:

1. Сохранить их текущее состояние.

2. Запретить их на время чтения SysTick.

3. Восстановить сохранённое состояние перед выходом.

Такой подход не является чем-то новым или специфичным для SysTick. Сохранение состояния прерываний при входе в критическую секцию и его восстановление при выходе применяется и в других SDK. Например, в компонентах STM32Cube при входе в критическую секцию сохраняется значение PRIMASK, после чего вызывается __disable_irq(), а при выходе прежнее состояние восстанавливается через __set_PRIMASK(). Здесь используется тот же принцип, но реализованный через gintenr ядра QingKe V4.

В используемом стандартном startup WCH прикладной код не имеет прямого доступа к регистру mstatus, поэтому сохранить и затем восстановить его из обычной функции нельзя. Для управления глобальным разрешением прерываний WCH предоставляет доступный приложению CSR gintenr, который отображает только биты MIE и MPIE регистра mstatus. Это позволяет работать с состоянием прерываний, не затрагивая остальные поля mstatus.

Регистр gintenr

В QingKe V4 для управления глобальным разрешением прерываний предусмотрен специальный регистр gintenr (Global Interrupt Enable Register).

gintenr является вендорным CSR от WCH и привязан к ядрам QingKe V4. Регистр служит отображением относящихся к прерываниям битов mstatus. Преимущество gintenr в том, что можно работать только с состоянием глобального разрешения прерываний, не записывая целиком весь mstatus. Работа с gintenr не изменяет индивидуальные настройки источников в PFIC и не распространяет свое влияние на NMI и исключения.

В регистре отображаются следующие два поля mstatus:

На этой основе можно сделать две вспомогательные функции: одна сохраняет состояние MIE и MPIE и запрещает прерывания, другая восстанавливает сохранённое состояние.

#define GINTENR_MIE_MASK       (1UL << 3)
#define GINTENR_MIE_MPIE_MASK  ((1UL << 3) | (1UL << 7))

static inline uint32_t irq_save_and_disable(void)
{
    uint32_t saved_state;

    __asm volatile (
        "csrrc %0, 0x800, %1\n"
        "fence.i"
        : "=r" (saved_state)
        : "r"  (GINTENR_MIE_MPIE_MASK)
        : "memory"
    );

    return saved_state;
}

static inline void irq_restore(uint32_t saved_state)
{
    const uint32_t state_to_restore =
        saved_state & GINTENR_MIE_MPIE_MASK;

    if ((state_to_restore & GINTENR_MIE_MASK) == 0U)
    {
        __asm volatile (
            "csrw 0x800, %0\n"
            "fence.i"
            :
            : "r" (state_to_restore)
            : "memory"
        );
    }
    else
    {
        __asm volatile (
            "csrw 0x800, %0"
            :
            : "r" (state_to_restore)
            : "memory"
        );
    }
}

Итого

Теперь отключение прерываний не останавливает SysTick, а лишь не позволяет обычному ISR задержать выполнение между чтениями. Благодаря этому CNTL не успеет переполниться дважды из-за задержки в обработчике.

uint64_t systick_get_ticks(void)
{
    const uint32_t irq_state = irq_save_and_disable();

    const uint32_t hi_before = SYSTICK_CNTH;
    uint32_t lo              = SYSTICK_CNTL;
    const uint32_t hi_after  = SYSTICK_CNTH;

    if (hi_before != hi_after)
    {
        lo = SYSTICK_CNTL;
    }

    const uint64_t ticks = ((uint64_t)hi_after << 32) | lo;

    irq_restore(irq_state);

    return ticks;
}

Ну и никакой мистики в поведении uptime не оказалось. Сам SysTick всё это время работал как ему и полагается. Ошибкой было считать, что объявленный как uint64_t аппаратный регистр читается одной атомарной операцией на 32-битном ядре.

UPD: @KivApple сделал ценное замечание, поэтому чуть формализую его посыл. Когда вызов функции завершается быстрее периода переполнения CNTL, для согласованного чтения не нужны ни цикл, ни запрет прерываний:

uint64_t systick_get_ticks(void)
{
    const uint32_t hi_before = SYSTICK_CNTH;
    uint32_t lo              = SYSTICK_CNTL;
    const uint32_t hi_after  = SYSTICK_CNTH;

    if (hi_before != hi_after)
    {
        lo = SYSTICK_CNTL;
    }

    return ((uint64_t)hi_after << 32) | lo;
}

Переполнение CNTL обнаруживается по изменению CNTH и компенсируется повторным чтением младшей части. Ошибка возможна только в том случае, если CNTL успеет переполниться второй раз в рамках того же вызова. При частоте SysTick 96 МГц между двумя переполнениями проходит около 44,7 секунды, поэтому в нормально работающей прошивке это условие выполняется с большим запасом.

При подготовке статьи использовался OpenAI Codex с моделью gpt-5.6-sol в режиме рассуждения high. AI помогал с поиском и сверкой документации, анализом кода и редактированием текста.