轉讓期間意外施放

stm32庫中有一段代碼行爲異常。這是由分配結構初始化到定時器自動重載寄存器製作：TIM_Period = 1999999轉讓期間意外施放

/* Set the Autoreload value */ 
TIMx->ARR = TIM_TimeBaseInitStruct->TIM_Period ;

我有，分配TIMx->ARR = 33919後然而。較小的數字通常指向溢出，所以我檢查了：(1999999-33919)/65536 = 30。這意味着數字在16位數據類型上溢出了30次，但這兩個變量都是32位無符號整數。

對於TIMX：

__IO uint32_t ARR;   /*!< TIM auto-reload register,   Address offset: 0x2C */

對於TIM_TimeBaseInitStruct：從結構聲明提取

uint32_t TIM_Period;   /*!< Specifies the period value to be loaded into the active 
            Auto-Reload Register at the next update event. 
            This parameter must be a number between 0x0000 and 0xFFFF. */

凡__IO被定義爲volatile。

這是任務的分解：

296  TIMx->ARR = TIM_TimeBaseInitStruct->TIM_Period ; 
0800c37c: ldr r3, [r7, #0] 
0800c37e: ldr r2, [r3, #4] 
0800c380: ldr r3, [r7, #4] 
0800c382: str r2, [r3, #44]  ; 0x2c

這到底是怎麼發生的事情..難道是外在的東西造成的價值溢出？請注意，我正在通過ST-Link在實際硬件上進行調試，無需優化代碼。

來源

2013-07-31 Raven

我猜你的芯片有16位定時器寄存器。也就是說，它可能仍然是一個32位寄存器，但只有16個有用位。

喜歡的東西：

31    16 15    0 
+--------------------+------------------+ 
|  RESERVED  | Auto-reload value| 
+--------------------+------------------+

事實覈查即將到來的（如果你有一個特定的編號，這將有助於我出去）。

編輯：通過看一些文檔[PDF link]，我的猜測似乎也印證：

enter image description here

編輯2：既然你提到你使用它的芯片，我發現，文檔太[PDF link ]，其中包含這個方便的圖表：

enter image description here

正如你可以看到，一些定時器具有32位自動重載，而有些則沒有。您選擇的計時器會影響您看到的行爲。

來源

2013-07-31 17:14:31

我要檢查數據表，以防萬一它是帶有Cortex-M4 MCU的STM32F3-Discovery板。 – Raven

'此參數必須是0x0000到0xFFFF之間的數字'似乎表明，是的。也正在尋找文檔:) –

找到一個參考。現在更新。 –

轉讓期間意外施放

回答

相關問題