LM3S系列的ROM RUN和RAM RUN

mybays

LM3S系列的ROM RUN和RAM RUN [复制链接]

试了两款LM3S8962和LM3S9B96，问题都一样。
LM3S系列能够将程序下载到内存，然后修改PC指针，在内存中运行，这样调试程序下载速度比较快，也减少了flash的读写次数，这是背景。

除了一些大的程序，我都是在内存中调试，简称RAM RUN，大家可以翻翻我以前的一个DS18B20的帖子，当时调试DS18B20时，是下载到flash中调试的，后来学会了RAM RUN，调试程序一直在RAM，但是这个DS18B20的程序，下载到ROM里运行，一切正常，但是下载到flash里，就无法搜索到器件，所以可以确定肯定是RAM的问题。今天用数字逻辑分析仪看了DS18B20数据管脚上的波形，发现波形的延时不对。刚刚特地写了一个延时程序，产生一个100Hz的方波，来看看到底怎么回事：
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC);
    GPIOPinTypeGPIOOutput(GPIO_PORTC_BASE,0x80);
    while(1)
    {
        GPIOPinWrite(GPIO_PORTC_BASE,0x80,0x00);
        _delay_ms(5);
        GPIOPinWrite(GPIO_PORTC_BASE,0x80,0x80);
        _delay_ms(5);
    }
先是下载到ROM里，看波形：

正常，然后下载到RAM里，再看波形：

发现延时很大，不知道怎么回事。
不知道有没有人能给个解释？

academic

下载到ROM里运行，一切正常，但是下载到flash里，就无法搜索到器件，

在这里，我有点晕，你所说的 ROM RUN 应该就是下载到 Flash 吧？

mybays

ROM RUN就是下载到flash

00750

这个问题不是很了解。
不过，很想知道如何实现RAM RUN，楼主能否分享一下

ddllxxrr

luster

LZ能介绍一下怎么RAM RUN啊？我也想试试

这里提出一个问题，RAM RUN的话速度是比ROM RUN要慢的，所以你写的_delay_ms()如果是用递增递减做的话延迟出来的时间肯定会比ROM RUN的长。

mybays

我用的是linux下的gcc交叉编译链，这里是通过链接脚本实现的。如果在windows下，参考以前同学的配置。
/*

Link script for LM3S8962 in ram.
Modified in Jul.17.2011
256K Flash,based on 0x00000000 to 0x00040000
64K Ram,based on 0x200000000 to 0x00010000
其中32K ram当flash使用,32K ram当ram使用

*/
MEMORY

{

    FLASH (rx) : ORIGIN = 0x20000000, LENGTH = 0x00008000

    SRAM (rwx) : ORIGIN = 0x20008000, LENGTH = 0x00008000

}




SECTIONS

{

    __STACKSIZE__ = 2048;

    __HEAPSIZE__  =  128;

    __SRAM_TOP__  = 0x20000000 + 0x00010000;



    .text 0x20000000 : AT(0x20000000)

    {

        _text = .;

        KEEP(*(.vectors))

        KEEP(*(.init))

        *(.text*)

        *(.rodata*)

    } > FLASH



    .ARM.extab :

    {

        *(.ARM.extab* .gnu.linkonce.armextab.*)

    } > FLASH



    .ARM.exidx :

    {

        *(.ARM.exidx* .gnu.linkonce.armexidx.*)

    } > FLASH

    _etext = _text + SIZEOF(.text) + SIZEOF(.ARM.extab) + SIZEOF(.ARM.exidx);





    .data : AT(ALIGN(_etext , 4))

    {

        _data = .;

        *(.vectors_ram)

        *(.data*)

    } > SRAM

    _edata = _data + SIZEOF(.data);



    .bss : AT(ALIGN(_edata , 4))

    {

        _bss = .;

        *(.bss*)

        *(COMMON)

    } > SRAM

    _ebss = _bss + SIZEOF(.bss);





    .heap : AT(ALIGN(_ebss , 4))

    {

      _heap = .;

      *(.heap*)

      . = ALIGN(MAX(_heap + __HEAPSIZE__ , .), 4);

    }

    _eheap = _heap + SIZEOF(.heap);



    .stack ALIGN(__SRAM_TOP__ - __STACKSIZE__, 4) : AT(ALIGN(__SRAM_TOP__ - __STACKSIZE__, 4))

    {

      _stack = .;

      *(.stack*)

      . = ALIGN(MAX(_stack + __STACKSIZE__ , .), 4);

    }

    _estack = _stack + SIZEOF(.stack);



    PROVIDE(__HEAP_START  = _heap);

}

beloved

能贴出_delay_ms（）的具体实现吗？问题应该出在这个函数。看看具体实现，就可以进一步分析了

mybays

希望能尽快找到原因，这样以后开发起来就不用那么麻烦了。
void _delay_ms(unsigned long count)
{
        unsigned long ulClockMS;
        ulClockMS=SysCtlClockGet()/(3*1000);
        SysCtlDelay(count*ulClockMS);
}
void _delay_us(unsigned long count)
{
        unsigned long ulClockMS;
        ulClockMS=SysCtlClockGet()/(3*1000000);
        SysCtlDelay(count*ulClockMS);
}

[ 本帖最后由 mybays 于 2011-7-23 03:46 编辑 ]

鑫海宝贝

楼主的图形软件是什么啊

mybays

saleae logic.

alfred

哈佛结构是ROM与RAM同时提取数据的，如果只用到RAM上面，那运行就直接影响了吧，还有TI的ROM是单周期指令，那不存在运行速度跟不上的问题。以上是个人理解

[ 本帖最后由 alfred 于 2011-7-25 10:40 编辑 ]

鑫海宝贝

奥谢谢了嘿嘿