关于STM32使用RTC时复位后程序死在 RTC_WaitForSynchro() 函数中的问题
解决STM32 I2C接口死锁在BUSY状态的问题
解决STM32 I2C接口死锁在BUSY状态的方法讨论关于STM32的I2C接口死锁在BUSY状态无法恢复的现象，网上已有很多讨论，看早几年比较老的贴子，有人提到复位MCU也无法恢复、只有断电才行的状况，那可是相当严重的问题。
类似复位也无法恢复的情况是存在的，技术支持矢口否认问题存在，并不是正确面对问题的态度。
比如我用这款F439芯片的SDRAM控制器，在错误操作后进入HardFault状态，复位无法恢复，JTAG也无法联机，只能断电重来，官方的Erratasheet里也提到了。
如果I2C接口无法可靠工作，那么所做的设计将存在严重隐患，不可能要求用户用断电的方法恢复系统。
如果像某些网友提到弃用硬件I2C，转为GPIO模拟I2C时序，那么首先I2C时钟频率不易确定，因为STM32的时钟频率可以动态调节；此外不用硬件I2C，无法用中断、DMA等高级模式，会严重降低ARM内核效率。
所以务须确认和解决这个问题。
一．问题存在我用STM32F439IGT，为了确定问题存在，让I2C控制器作Master，先人为产生I2C总线故障。
产生I2C总线故障的方法简单而粗暴：在I2C总线工作过程中，用镊子把SCL和SDA两个信号短路一下，很容易进入BUSY死锁状态。
长时间短路也可能产生超时。
HAL_I2C_Init()、HAL_I2C_Master_Transmit()、HAL_I2C_Master_Receive()等函数返回值分别为HAL_BUSY（0x02）、HAL_TIMEOUT（0x03）。
试着用MCU复位，是可以恢复的，说明硬件没死穴。
又测试不用MCU复位，而是在程序中依次调用STM32Cube_FW_F4_V1.5.0固件库提供的如下两个初始化函数：HAL_I2C_DeInit(&hi2c1)、HAL_I2C_Init(&hi2c1)，并不能保证一定恢复正常。
BUSY死锁时，用万用表测试I2C信号电压，SCL、SDA均为低电平。
stm32固件库函数使用keil时的常见错误分析
stm32固件库函数使用keil时的常见错误分析error: A1355U: A Label was found which was in no AREA 终级解决办法分类：深入C语言2009-12-30 11:26208人阅读评论(0)收藏举报error: A1355U: A Label was found which was in no AREA 在KEIL工程中，我使用另一个工程中正确的分散加载文件到一个新工程中，竟然就出现这样的提示。
到网上搜索，有很多内容是关于这个问题的，但是却没有几个很好解决问题的。
其实出现这个问题有两种情况，一种是出现在.s的汇编文件中，另一种是出现在.scf (或者.scat)等的分散加载文件中。
原来很多人在汇编文件（多数为.s的启动代码）中出现这个问题的，基本上是因为使用汇编的格式不对，关于这个错误，ARM官网有相关的说明：A1355U: A Label was found which was in no AREAExample:This can occur where no white-space precedes an assembler directive.Assembler directives must be indented with white-space, for example:use:IF :DEF: FOO; codeENDIFnot:IF :DEF: FOO; codeENDIFSymbols in the left hand column 1 are assumed to be labels,hence the error message.意思是在编写汇编文件时，标号要顶格写，而其他的代码都要用空格或者TAB键来使代码进行缩进，这样，就不会出现编译的问题了。
如果问题是出现在分散加载文件中，那么很可能你是把分散加载文件一起加入到了KEIL的工程中，类似这样：这时候，就可能会出现error: A1355U: A Label was found which was in no AREA这样的报错，不管你用多么正确的SCATTER文件格式，它始终都会报错。
STM32单片机常见的工作异常现象分析及解决方案
STM32 单片机常见的工作异常现象分析及解决方案贴了两块样板，烧写同样的固件。
其中一块工作正常，但是另外一块出现了很奇怪的现象：在线调试正常；每次烧写完后工作正常；重新上电有时候工作正常，有时候工作不正常；工作不正常时，按下复位按键，恢复正常。
工作异常现象：main 函数中的系统运行指示灯不闪烁，但是初始化过程中点的一个灯是亮的！说明程序运行一段时间后，不工作了。
由于在线调试模式，板子工作正常，无法通过在线调试的方式判断程序运行的异常状态。
分析可能的原因：1、初始化过程中，程序陷入死循环。
但程序初始化过程中，没有while （1）死循环的代码。
2、板子上电后不断复位，导致无法进入main 函数中的while（1）循环。
问题查找：硬件：1、确认BOOT0 管脚接10kΩ欧电阻下拉到地；2、RC 上电延时复位电路中，R 为10kΩ，C 由0.1uF 改为10uF，现象依旧；3、MCU 3.3V 电源纹波很小，排除电源问题。
好像从硬件上查不出什幺问题。
只能从板子上唯一点亮的灯下手了。
软件：1、好像跟硬件复位没什幺关系，为了确认板子是不是在不停复位，在点亮的那个灯前加了100ms 延时，如果是在复位，那灯就应该不停闪烁。
但那个灯还一直是亮的，说明是程序运行出错，不运行了。
2.不断修改led 灯在初始化代码中的位置，最终定位到导致运行出错的代码：配置一个GPIO 为外部中断，跳变沿触发，上拉。
把上拉改为NOPULL，工作一切正常。
问题定位：配置为外部中断的GPIO 悬空导致。
之前工作正常的样板是一直有连接到那个IO 脚的外接模块，这个工作不正常的没有接，导致IO 管脚电平不确定。
由于电平的不确定，在初始化的瞬间有一个跳变沿，导致程序进入外部中断服务函数。
在中断服务函数中，要读取一个定时器的寄存器的值，但是要读取的定时器可能还没有完成初始化，导致读取失败，程序运行异常。
解决办法：1、PULL 模式有PULLRISING 改为NOPULL；2、timer 在这个外部中断之前进行初始化。
STM32_RTC简介及程序
stm32——RTC实时时钟一、关于时间2038年问题在计算机应用上，2038年问题可能会导致某些软件在2038年无法正常工作。
所有使用UNIX时间表示时间的程序都将将受其影响，因为它们以自1970年1月1日经过的秒数（忽略闰秒）来表示时间。
这种时间表示法在类Unix（Unix-like）操作系统上是一个标准，并会影响以其C编程语言开发给其他大部份操作系统使用的软件。
在大部份的32位操作系统上，此“time_t”数据模式使用一个有正负号的32位元整数（signedint32)存储计算的秒数。
也就是说最大可以计数的秒数为 2^31次方可以算得：2^31/3600/24/365 ≈ 68年所以依照此“time_t”标准，在此格式能被表示的最后时间是2038年1月19日03:14:07，星期二（UTC）。
超过此一瞬间，时间将会被掩盖（wrap around）且在内部被表示为一个负数，并造成程序无法工作，因为它们无法将此时间识别为2038年，而可能会依个别实作而跳回1970年或1901年。
对于PC机来说，时间开始于1980年1月1日，并以无正负符号的32位整数的形式按秒递增，这与UNIX时间非常类似。
可以算得：2^32/3600/24/365 ≈ 136年到2116年，这个整数将溢出。
Windows NT使用64位整数来计时。
但是，它使用100纳秒作为增量单位，且时间开始于1601年1月1日，所以NT将遇到2184年问题。
苹果公司声明，Mac在29,940年之前不会出现时间问题！二、RTC使用说明"RTC"是Real Time Clock 的简称，意为实时时钟。
stm32提供了一个秒中断源和一个闹钟中断源，修改计数器的值可以重新设置系统当前的时间和日期。
RTC模块之所以具有实时时钟功能，是因为它内部维持了一个独立的定时器，通过配置，可以让它准确地每秒钟中断一次。
但实际上，RTC就只是一个定时器而已，掉电之后所有信息都会丢失，因此我们需要找一个地方来存储这些信息，于是就找到了备份寄存器。
STM32在keil下使用jlink时产生错误的解决方法
最近一段时间一直在学习STM32和ucos的移植，使用的开发环境是keil u4版本。
仿真器是80元买的jlink。
在学习了STM32固件库和ucos内核与移植相关的程序之后，写了一个流水灯程序，准备下载到板子上看看情况。
哪知程序还没有下进去，在debug时，keil的错误提示到：Error: Flash download failed-"Cortex-M3"感觉这么错误很普遍，也是初学者常常遇到的错误，下面我就将这个错误产生的原因和解决方法赘述一下：错误产生的原因和分析，解决。
首先，我们看到提示信息是有关flash的，那么我们来查看一下STM32F103XB的数据手册关于这部分的描述（我使用的芯片是STM32F103RB，有128kflash。
）知道了原来flash在此芯片中的地址是从0x0800 0000到0x0801 FFFF 这段，也就是说这段存储空间是用来存储程序。
而在STM32芯片方面，它又有一个规则，那就是芯片启动的方式，如果你把程序下载到了flash中，那么在复位芯片之前或者通电之前，要将boot0，boot1两个引脚拉到高电平，这样在启动时，芯片初始化之后，运行程序代码才是从flash地址开始执行的。
于是，我们来查看一下keil中仿真器的设置，是不是正确，设置的选项在keil软件的project-options for target中的Utilities中，先来查看下仿真器是否选对，然后点settings，弹出如下菜单：查看一下programming Algorism 下的flash地址是否正确，如果不正确则会引起开始那个错误的提示信息，如果正确还是出现那个错误，那么按照官方给的解决方法是，删除现有的flash地址，重新配置一下，记得要选对芯片型号和地址空间。
配置好之后点击OK退出。
然后再查看一下Target中的地址，是否跟你重新添加的一致，如果一致，那么点OK退出。
STM32芯片异常复位的原因有哪些
STM32 芯片异常复位的原因有哪些
问题描述
某STM32 用户反馈，当使用STM32L4 芯片的时候，程序运行一段时间后，会忽然复位。
复位后程序继续运行，但是还会继续复位，原因不详。
问题解析
初步确定复位的原因，是硬件复位，如外部NRST 被拉低，还是软件复位，包括软件直接调用复位，或者看门狗复位，还是低功耗模式如standby 模式被唤醒时产生中断。
查看复位状态寄存器了解复位大方向，然后做进一步得拆解分析。
目前客户项目的复位原因是因为看门狗复位，即客户使用了IWDG，但由于某种原因没有及时喂狗，导致IWDG 超时复位。
初步怀疑由于客户软件的问题，程序跑飞，进入异常处理。
STM32的电源复位和引脚复位
STM32的电源复位和引脚复位
在调试程序的时候，发现仿真的时候程序⼀切运⾏正常，当重新上电后，程序运⾏不正常
具体现象如下：
1、确定是进⼊while(1)了，因为有程序运⾏的秒闪灯在闪烁
2、应该是MCU⽆法正常收到的24L01的命令（⽆法驱动4094⽚⼦的继电器动作）
3、当⼿动把复位引脚的电平拉低后，程序便运⾏正常了
调试⽅法如下：
1、怀疑是硬件复位电路的问题，但是确实是普通的阻容复位，没看出来多⼤的问题
2、⽤软件复位，上电运⾏第⼀次先进⾏软件复位，第⼆次正常运⾏，不知道怎么设置标志位
系统复位将复位除时钟控制寄存器CSR中的复位标志和备份区域中的寄存器以外的所有寄存器
@1、备份区域中的寄存器
1if(BKP->DR1!=0X5050)
2 {
3 SCB->AIRCR = (u32)0x05FA0000 | (u32)0x04;
4 BKP->DR1 = 0X5050;
5 }
备份区域中的寄存器在没有电池供电的情况下，软件复位后，寄存器的值仍然会丢
@2、复位除时钟控制寄存器CSR中的复位标志
1if( (RCC->CSR >> 28) == 0 )
2 {
3 SCB->AIRCR = (u32)0x05FA0000 | (u32)0x04;
4 }
确实能软件复位了，但是没起到应有的效果
3、有没有可能是⽆线模块的设置问题
4、由STM32内部复位电路可知，电源复位和软件复位
这个问题确实很困惑，望⾼⼿指点啊。
是不是很有可能是24L01模块⼉的问题啊，在开发板上测试也不⾏，要不就是程序的问题，初始化设置有问题。
stm32_RTC时钟校准
AN2604应用笔记STM32F101xx and STM32F103xx RTC校准总体介绍实时时钟在很多嵌入式应用中是必不可少的，但是由于外部环境温度的改变，驱动RTC的晶体频率会发生变化，因此RTC就没有预想的那么准确了！STM32F101xx and STM32F103xx附带有数字时钟校准电路，因此可以适应与变化的环境，它主要是来补偿晶体由于环境的变化，这篇应用笔记主要讨论了RTC校准的基本原理以及解释了如何利用RTC校准来提高计时精度。
1RTC校准基本原理1.1晶体的准确性在很多计时领域，通常都是用“石英精确度”这么一个术语来描述的，石英晶体振荡器提供了一个远远优于其他类型振荡器的精确度，但是它并不是完美的，石英晶体振荡器对温度十分敏感，Figure1展示了一个32.768HZ晶体的频率精确度（acc）和温度（T）以及曲率（K）的关系，这个曲线可以用下面的公式给出：注：曲率K由于不同的晶体而不同，这里是针对STM3210B-EVAL开发板来说的，关于这部分可以参考相关晶体制造商提供的详细信息。
在很多应用领域需要一个高准确度的时钟，但是在实际中有好多综合因素限制着精度的提高，通常，典型的方法是通过调节晶体的负载电容来调节精度，这一方法，虽然十分有效，但是也存在这一些缺点：1它需要多加一个外部器件（可调电容）。
2其增大了电流消耗（这在电池供电的场合尤为突出）。
取代这种传统的模拟的方法，STM32F10xxx系列提供了一个数字校准器，允许用户用软件控制的方法进行校准，非常的好用！1.2具体方法STM32F10xxx的RTC模块是用一个32768HZ的通常石英晶体驱动的，其实石英晶体是一种能够提供非常固定频率的，但是有以下两种情况导致了其频率的不稳定：1温度变化；2晶体本身的变化。
前面讲述了一般通常的方法都是用一个麻烦的可调电容来补偿误差，这里STM32F10xxx使用的是一个周期计数器来进行校正，这个数字校正器通过从220个时钟周期中减去0到127个周期的方法来校正的，如图所示：究竟有多少个时钟节拍是空白的取决于最近一次向备份寄存区域RTC校准寄存器最后七位加载的值，之所以这个校准寄存器放在备份区域是因为这个寄存器即使在系统掉电情况下仍然可以通过后备电池进行供电（译者注：如果后背电池也掉电，当然这个寄存器的值也会丢失的），注意：从上图中可以看出时钟输出引脚是在校准之前的频率，所以这个值是不会被校准所改变的，尽管已经进行了校准，但是这个输出是在校准之前的频率。
STM32入门系列-STM32时钟系统，时钟使能配置函数
STM32⼊门系列-STM32时钟系统，时钟使能配置函数 之前的推⽂中说到，当使⽤⼀个外设时，必须先使能它的。
怎么通过库函数使能时钟呢？如需了解寄存器配置时钟，可以参考《STM32F10x中⽂参考⼿册》“复位和时钟控制（RCC）”章节，其中有详细的寄存器介绍。
固件库已经把时钟相关寄存器的使能配置都封装好，放在stm32f10x_rcc.c和stm32f10x_rcc.h中。
只需要打开stm32f10x_rcc.h⽂件，会发现有很多的宏定义和时钟使能函数的声明。
这些时钟函数可⼤致分为三类。
⼀类是外设时钟使能函数，⼀类是时钟源和倍频因⼦配置函数，还有⼀类是外设复位函数。
当然还有⼏个获取时钟源配置的函数。
下⾯就来简单介绍下这些函数的使⽤。
⾸先看⼀下时钟使能函数，时钟使能函数包括外设时钟使能和时钟源使能。
外设时钟使能相关函数如下：void RCC_AHBPeriphClockCmd(uint32_t RCC_AHBPeriph, FunctionalState NewState);void RCC_APB2PeriphClockCmd(uint32_t RCC_APB2Periph, FunctionalState NewState);void RCC_APB1PeriphClockCmd(uint32_t RCC_APB1Periph, FunctionalState NewState);上⾯3个时钟使能函数也正是STM32的3条总线（这个在前⾯介绍存储器与寄存器章节讲过）。
由于STM32的外设都是挂接在AHB和APB 总线上的，所以要使能外设时钟，也就是使能对应外设所挂接的总线时钟。
⽐如GPIO外设它是挂接在APB2总线上的，如果使⽤GPIO外设，就需要先使能APB2总线时钟，使能时钟代码如下。
void RCC_APB2PeriphClockCmd(uint32_t RCC_APB2Periph,FunctionalState NewState);要想哪个外设挂接在哪个总线上呢，可以通过STM32中⽂参考⼿册查找，还可以在固件库stm32f10x_rcc.h⽂件中查找。
【免费下载】写第一个STM32程序常见错误及解决方法
中的
然后点击 OK。
再 ，然后会出第二个错误： C:\Keil\ARM\Inc\ST\STM32F10x\stm32f10x.h(8297): error: "stm32f10x_conf.h": No such file or directory 这说明文件包含的路径没有设置好。
解决办法：
按上面所述选到
解决办法：请点击
打开的界面中选到
选项,然后 Define 里面输入 STM32F10X_MD（因为这个实验板
上用的 STM32F103C8T6 对应这个“中等容量的 FLASH”，换做其他芯片不一定是这个字 符串），如图：
对全部高中资料试卷电气设备，在安装过程中以及安装结束后进行高中资料试卷调整试验；通电检查所有设备高中资料电试力卷保相护互装作置用调与试相技互术关，系电，力根通保据过护生管高产线中工敷资艺设料高技试中术卷资，配料不置试仅技卷可术要以是求解指，决机对吊组电顶在气层进设配行备置继进不电行规保空范护载高与中带资负料荷试下卷高问总中题体资，配料而置试且时卷可，调保需控障要试各在验类最；管大对路限设习度备题内进到来行位确调。保整在机使管组其路高在敷中正设资常过料工程试况中卷下，安与要全过加，度强并工看且作护尽下关可都于能可管地以路缩正高小常中故工资障作料高；试中对卷资于连料继接试电管卷保口破护处坏进理范行高围整中，核资或对料者定试对值卷某，弯些审扁异核度常与固高校定中对盒资图位料纸置试，.卷保编工护写况层复进防杂行腐设自跨备动接与处地装理线置，弯高尤曲中其半资要径料避标试免高卷错等调误，试高要方中求案资技，料术编试交写5、卷底重电保。要气护管设设装线备备置敷4高、调动设中电试作技资气高，术料课中并3中试、件资且包卷管中料拒含试路调试绝线验敷试卷动槽方设技作、案技术，管以术来架及避等系免多统不项启必方动要式方高，案中为；资解对料决整试高套卷中启突语动然文过停电程机气中。课高因件中此中资，管料电壁试力薄卷高、电中接气资口设料不备试严进卷等行保问调护题试装，工置合作调理并试利且技用进术管行，线过要敷关求设运电技行力术高保。中护线资装缆料置敷试做设卷到原技准则术确：指灵在导活分。。线对对盒于于处调差，试动当过保不程护同中装电高置压中高回资中路料资交试料叉卷试时技卷，术调应问试采题技用，术金作是属为指隔调发板试电进人机行员一隔，变开需压处要器理在组；事在同前发一掌生线握内槽图部内 纸故，资障强料时电、，回设需路备要须制进同造行时厂外切家部断出电习具源题高高电中中源资资，料料线试试缆卷卷敷试切设验除完报从毕告而，与采要相用进关高行技中检术资查资料和料试检，卷测并主处且要理了保。解护现装场置设。备高中资料试卷布置情况与有关高中资料试卷电气系统接线等情况，然后根据规范与规程规定，制定设备调试高中资料试卷方案。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
关于STM32使用RTC时复位后程序死在RTC_WaitForSynchro() 函数中的问题
作者: 奔跑日期: 2012 年05 月14 日9,102 views 发表评论 (0) 查看评论
出现的现象：使用野火的RTC例程，在软件仿真时如果不需要配置，则程序会死在
RTC_WaitForSynchro() 函数中。
而下载到硬件上时，有时候可以跑，有时候也会在该函数中死循环。
可能的原因：
首先，一定要确认是否使能了对后备寄存器和RTC的访问。
系统复位后，对后备寄存器和RTC的访问被禁止，这是为了防止对后备区域(BKP)的意外写操作。
执行以下操作将使能对后备寄存器和RTC的访问：
● 设置寄存器RCC_APB1ENR的PWREN和BKPEN位，使能电源和后备接口时钟
RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR | RCC_APB1Periph_BKP, ENABLE);
● 设置寄存器PWR_CR的DBP位，使能对后备寄存器和RTC的访问
PWR_BackupAccessCmd(ENABLE);
另外还要使能RTC时钟RCC_RTCCLKCmd(ENABLE); 虽然该函数的说明中说只在
RCC_RTCCLKConfig()函数调用之后才能调用，但是实际上如果不调用该函数，仿真时就会在RTC_WaitForSynchro() 函数中死循环，等待RTC时钟同步。
也就是说，不论是否需要配置RTC寄存器，每次系统复位都需要执行如下操作：
RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR | RCC_APB1Periph_BKP, ENABLE);
PWR_BackupAccessCmd(ENABLE);
RCC_RTCCLKCmd(ENABLE);
其次，STM32的RTC对外部LSE要求比较高，最好使用负载电容为6pF的晶振。
在芯片的DataSheet中有明确的说明，不能使用12.5pF的晶振。
“ To avoid exceeding the maximum value of CL1 and CL2 (15 pF) it is strongly recommended to use a resonator with a load capacitance CL≤ 7 p F. Never use a resonator with a load
capacitance of 12.5 pF.”。