Периодическая, но повторяющаяся ошибка HAL_RTC_SetDate на STM32F4 с Mbed-OS 5 - PullRequest
Новая
       87

Периодическая, но повторяющаяся ошибка HAL_RTC_SetDate на STM32F4 с Mbed-OS 5

1 голос
/ 25 апреля 2020

Я пытался выяснить, что пошло не так с моей печатной платой / встроенным кодом. Печатная плата разработана вокруг STM32F407VE. set_time () вызывается каждые 5/10/20/60/120 секунд. 

time_t et = time(NULL);
debug("%d: NTP sync started\r\n", et);
set_time(et);

600 секунд после первого вызова кода, я увижу что-то вроде следующего: 

1587754882: NTP sync started
1587754902: NTP sync started
1587754922: NTP sync started
1587754942: NTP sync started
1587754962: NTP sync started
1587754982: NTP sync started
1587755002: NTP sync started
1587755022: NTP sync started
1587755042: NTP sync started
1587755062: NTP sync started
1587755082: NTP sync started
1587755102: NTP sync started
1587755122: NTP sync started
1587755142: NTP sync started
1587755162: NTP sync started
1587755182: NTP sync started
1587755202: NTP sync started
1587755222: NTP sync started
1587755242: NTP sync started
1587755262: NTP sync started
1587755282: NTP sync started
1587755302: NTP sync started
1587755322: NTP sync started
1587755342: NTP sync started
1587755362: NTP sync started
1587755382: NTP sync started
1587755402: NTP sync started
1587755422: NTP sync started
1587755442: NTP sync started
1587755462: NTP sync started
1587755482: NTP sync started


++ MbedOS Error Info ++
Error Status: 0x80FF0100 Code: 256 Module: 255
Error Message: Fatal Run-time error
Location: 0x8022591
Error Value: 0x0
Current Thread: main  Id: 0x20005B8C Entry: 0x801A273 StackSize: 0x2000 StackMem: 0x2000B4C0 SP: 0x2000D270 
For more info, visit: https://mbed.com/s/error?error=0x80FF0100&tgt=ARCH_MAX
-- MbedOS Error Info --
HAL_RTC_SetDate error

Если интервал составляет 5 секунд, то 121-й вызов вызовет систему cra sh. Если интервал составляет 2 минуты, то 6-й вызов вызовет cra sh.

Несколько других наблюдений: 1) Это происходит независимо от использования LSI или LSE в качестве источника часов RT C. 2) Если я закомментирую set_time (), то система не обработает sh. 3) Следующий простой тестовый код не обрабатывает sh на одной плате. Но если закомментированный код включен, это воспроизведет проблему. 

    time_t et;
    printf("%d: system started\r\n", time(NULL));
    uint8_t toResetRTC = 0, toSaveFooIntoBackupRegister = 0;
    uint32_t foo = 12345;
    while (1)
    {
        toResetRTC++;
        if(toResetRTC > 4)
        {
            et = time(NULL);
            printf("%d: RTC reset started\r\n", et);
            set_time(et);
            toResetRTC = 0;
        }
        toSaveFooIntoBackupRegister++;
        if(toSaveFooIntoBackupRegister > 59)
        {
            RTC_HandleTypeDef RtcHandle;
            RtcHandle.Instance = RTC;
            HAL_PWR_EnableBkUpAccess();
            HAL_RTCEx_BKUPWrite(&RtcHandle, 0, foo);
            // This following line messes up HAL_RTC_SetDate() and HAL_RTC_SetTime() when called by set_time();
            // If the following line is enabled, system crashes every 1 minute
            //HAL_PWR_DisableBkUpAccess();
            toSaveFooIntoBackupRegister = 0;
        }
        ThisThread::sleep_for(1000);
    }

Мое мнение - другая часть (и) базы кода периодически вмешивается в RT C. Кто-нибудь может предложить несколько советов по устранению неполадок?

Спасибо.

Обновление: первый блок кода, содержащий set_time (), был вызван через тикер, который получает часы от HSE. Когда я просматривал вывод консоли, когда RT C был получен из LSI (см. Ниже), я понял, что интервал изменился до 570 при первом запуске 31, который приводит к сбою системы. Мне стало очевидно, что cra sh не происходит из-за какого-то таинственного ритма, присущего c RT C, а скорее чего-то вне RT C. И есть блок кода, который выполняется 600 секунд от загрузки системы. Этот код блока в конечном итоге приводит к поиску в ответе.

cra sh log, когда RT C поступает из LSI. 

1587760500: NTP sync started
1587760519: NTP sync started
1587760538: NTP sync started
1587760557: NTP sync started
1587760576: NTP sync started
1587760595: NTP sync started
1587760614: NTP sync started
1587760633: NTP sync started
1587760652: NTP sync started
1587760671: NTP sync started
1587760690: NTP sync started
1587760709: NTP sync started
1587760728: NTP sync started
1587760747: NTP sync started
1587760766: NTP sync started
1587760785: NTP sync started
1587760804: NTP sync started
1587760823: NTP sync started
1587760842: NTP sync started
1587760861: NTP sync started
1587760880: NTP sync started
1587760899: NTP sync started
1587760918: NTP sync started
1587760937: NTP sync started
1587760956: NTP sync started
1587760975: NTP sync started
1587760994: NTP sync started
1587761013: NTP sync started
1587761032: NTP sync started
1587761051: NTP sync started
1587761070: NTP sync started


++ MbedOS Error Info ++
Error Status: 0x80FF0100 Code: 256 Module: 255
Error Message: Fatal Run-time error
Location: 0x8022591
Error Value: 0x0
Current Thread: main  Id: 0x20005B8C Entry: 0x801A273 StackSize: 0x2000 StackMem: 0x2000B4C0 SP: 0x2000D270 
For more info, visit: https://mbed.com/s/error?error=0x80FF0100&tgt=ARCH_MAX
-- MbedOS Error Info --
HAL_RTC_SetDate error

1 Ответ

2 голосов
/ 25 апреля 2020

Проблема была в конечном счете отслежена в другой части базы кода, которая в конечном итоге после 3 прыжков вызывает выполнение: 

HAL_PWR_DisableBkUpAccess();

У меня сложилось впечатление, что эта строка отключает только доступ к RT C резервные регистры данных (которые используются в базе кода) и резервная копия SRAM. Но согласно руководству пользователя, несмотря на название, оно также отключает доступ к регистрам RT C, и его аналог вызывается при инициализации RT C на mbed. 

HAL_PWR_EnableBkUpAccess();
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Похожие темы

...