LM3S9B96需要从JLINK启动才正常，正常的上电启动程序会出错

ngyg12

          如题，程序要通过JLINK 启动才正常运行，使用的编译环境是 IAR for ARM 6.0.  通过IAR debug 程序，然后使用 run 命令，程序能正常运行。
当拔掉jlink后，断电，重新上电，通过串口能知道程序运行了一段时间，但是会一直死循环在查询FPGA的状态中（使用LM3S和FPGA通信），然后就死在FaultISR中了。如果用JLINK debug的话，直接就查询通过
，程序能达到预期效果。百思不得其解........想问问大家有没有遇到过这样额问题，特来咨询一下子....

zxq6

估计延时不够。

dragonbbc

是不是电源的问题？

ngyg12

zxq6 发表于 2012-8-18 16:51
估计延时不够。

通信是直接用的SPI的DMA 没有额外加延时.....应该不是这个问题

ngyg12

dragonbbc 发表于 2012-8-18 16:53
是不是电源的问题？

请问你说的电源问题是什么啊？是指两种运行模式的电源电压不相等吗？  我粗略的测量了一下，是一样的3.36V左右。

ngyg12

自己顶一下，问题还未解决

dragonbbc

我是说会不会是电源驱动能力不够，或者不够稳定什么的，我也不太懂，之前我也遇到过同样的问题，也是接上Jlink就正常，不接Jlink就不能用，是调什么程序想不起来了，后来好象也没解决，因为我用LM3S9B96主要是学习用的，因此也就放一边了，楼主解决了记得说一声哈

dragonbbc

想起来了，是用PWM驱动一个无源蜂鸣器，接上Jlink就能响，不接就不会响，不过当时好象用的不是LM3S9B96，是LM3S1138

laoshuhunya

此现象一般是看门狗引起
在调试状态下，调试器会禁用看门狗，但当系统重新复位或上电时看门狗就开始起作用了
可以测下RESET管脚，是不是一直有复位脉冲输出
老衲在调试MK60时遇到同样的情况，最后把关闭看门狗的语句移到启动代码中得以解决：

;===============================================复位处理
Reset_Handler   PROC
                EXPORT  Reset_Handler    [WEAK]
;--------------------------------------------------------------若系统不初始化可注释掉本节代码
                CPSID   F    ; 禁止中断
               
                LDR     R0, = 0x4005200E    ; 关闭看门狗
                LDR     R4, = 0x0000C520
                STRH    R4,[R0]
                LDR     R0, = 0x4005200E
                LDR     R4, = 0x0000D928
                STRH    R4,[R0]
                LDR     R0, = 0x40052000
                LDR     R4, = 0x000001D2
                STRH    R4,[R0]
               
                ;IMPORT  SystemInit    ; 系统初始化
                ;LDR     R0, = SystemInit
                ;BLX     R0
;--------------------------------------------------------------初始化C运行时库，执行main()函数
                IMPORT  __main
                LDR     R0, = __main
                BX      R0
                ENDP
;==============================================================

ngyg12

laoshuhunya 发表于 2012-9-7 00:41
此现象一般是看门狗引起
在调试状态下，调试器会禁用看门狗，但当系统重新复位或上电时看门狗就开始起作用 ...

谢谢关注，不是看门狗的问题，是后面引用了一个 printf 函数输出一个文件流，当不用这个函数的时候就不会死机。现在把rintf函数去掉了，使用正常了。

robin45853258

ngyg12 发表于 2012-9-7 14:00
谢谢关注，不是看门狗的问题，是后面引用了一个 printf 函数输出一个文件流，当不用这个函数的时候就不会 ...

我刚开始用9b96，感觉问题比较多，今天突然锁死了，不知道为啥，JLINK擦不掉，也写不进去，悲剧。。。。而且，我还听说9b96是缺陷机，擦写次数有限，不知道是不是真的。

ngyg12

robin45853258 发表于 2012-9-11 16:45
我刚开始用9b96，感觉问题比较多，今天突然锁死了，不知道为啥，JLINK擦不掉，也写不进去，悲剧。。。。 ...

嗯，传说是这样，它出了好几个版本了，用最新的好一些吧，以前的版本肯定问题比较多。

robin45853258

ngyg12 发表于 2012-9-13 12:01
嗯，传说是这样，它出了好几个版本了，用最新的好一些吧，以前的版本肯定问题比较多。 ...

有一个问题请教一下：我现在调试UART0，设置都没问题（因为之前的代码是汇编，程序能够顺利跑通，这次改成C代码，我初始化之后对比了寄存器的值，是一样的，而且C代码我反复对比过，肯定和汇编代码一模一样），但是现在UART发送不能够顺利执行。
代码如下：
void uart_send_frame(const UB* buf)
{

        /* Wait for the transmitter to be ready while  */
        while(((in_w(UART0_BASE+UART_O_FR)) & UART_FR_TXFE) == NULL){
                ;
        }

         /*Send character just get a character,not a word */
        out_b((UART0_BASE+UART_O_DR),*buf);

        /* Wait for the transmitter to be finished  */
        while(((in_w(UART0_BASE+UART_O_FR)) & UART_FR_TXFE) == NULL){
                ;
        }
}

照理说，当有数据存入UARTDR寄存器之后就应该启动UART的发送，但是程序死在了后一个while语句里，UARTFR的值一直都是0x38，所以我现在也不知道该怎么办了。
有什么办法可以让UART主动发送吗？或者这个时候产生的原因可能是什么呢？
Inline UW in_w( UW port )
{
        return *(_UW*)port;
}

Inline void out_b( UW port, UB data )
{
        *(_UB*)port = data;
}

typedef unsigned long             UW;
typedef volatile UW           _UW;

ngyg12

robin45853258 发表于 2012-9-13 17:51
有一个问题请教一下：我现在调试UART0，设置都没问题（因为之前的代码是汇编，程序能够顺利跑通，这次改 ...

贴一下初始化代码吧，粗略看发送代码，是没有什么太大的问题.....

robin45853258

ngyg12 发表于 2012-9-14 22:40
贴一下初始化代码吧，粗略看发送代码，是没有什么太大的问题.....

我将汇编和C一条一条替换时发现，有一段代码换成C语言之后就会产生这个问题。但是，两端代码实际上是没有区别的，我现在怀疑是编译器的问题。
代码如下：
现在产生问题的代码：
        /*Bypass PLL,Don't use SYSDIV         */
        data =        in_w(SYSCTL_BASE + SYSCTL_O_RCC);
        data = data | SYSCTL_RCC_BYPASS;
        data = data & (~SYSCTL_RCC_USESYSDIV);
        address = SYSCTL_BASE + SYSCTL_O_RCC;
        out_w(address , data);
原代码：
    ldr.w   r0,=SYSCTL_BASE

    ldr.w   r2,[r0, #SYSCTL_O_RCC]
    mov.w   r1,#SYSCTL_RCC_BYPASS
    orr.w   r2,r1                       /*Bypass PLL          */
    ldr.w   r1,=(~SYSCTL_RCC_USESYSDIV)
    and.w   r2,r1
    str.w   r2,[r0,#SYSCTL_O_RCC]       /*Don't use SYSDIV    */

robin45853258

我也发现了类似的问题，后来我们公司的老板反复对比代码后发现一个问题，就是我们用的编译器在编译的时候一上电PC地址是偶数，但是PC最后一位应该给个标志位才对，程序运行的时候还是会按照偶数运行，但是T标志位是要给置位的，后来人为的将十六进制文件的PC改为奇数，烧写进去就可以顺利运行了。用JLINK仿真的时候，JLINK会帮助添加T标志位，所以不会产生问题，你可以试试。

robin45853258

robin45853258 发表于 2012-9-17 08:52
我将汇编和C一条一条替换时发现，有一段代码换成C语言之后就会产生这个问题。但是，两端代码实际上是没有 ...

代码修改成下面的形式后，问题解决，可能是编译器的问题，也可能是芯片硬件的问题。还不知道具体缘由。

        _UW                temp;
        UW                n;

        /*Bypass PLL,Don't use SYSDIV         */
        temp =        in_w(SYSCTL_BASE + SYSCTL_O_RCC) | SYSCTL_RCC_BYPASS;
        temp &= (~SYSCTL_RCC_USESYSDIV);
        out_w((SYSCTL_BASE + SYSCTL_O_RCC) , temp);

robin45853258

robin45853258 发表于 2012-9-18 08:58
代码修改成下面的形式后，问题解决，可能是编译器的问题，也可能是芯片硬件的问题。还不知道具体缘由。

...

有点儿小悲剧，升级了编译器之后又不好用了，不知道UART到底哪个时钟不对，嗨，一个一个查吧~~~~~

laoshuhunya

ngyg12 发表于 2012-9-7 14:00
谢谢关注，不是看门狗的问题，是后面引用了一个 printf 函数输出一个文件流，当不用这个函数的时候就不会 ...

哦，没看清楚你的问题，原来“通过串口能知道程序运行了一段时间”