2 msq19895070 msq19895070 于 2013.09.12 19:03 提问

C语言函数运行死机的问题(PC上验证通过,移植DSP上会死机)

这几天遇到一个很奇怪的问题,一个算法程序,在PC机上验证通过,运行良好。我把它移植到DSP里面,程序运行会死机。我已开始以为是指针什么的跑飞了,我开始验证,函数正确性。最后确定没错了,指针均正常,而且PC机上绝对无错。一下为代码
void ResizeHaarPattern( const signed int* src, SURF_HARRI_FILTER* dst, unsigned int n, unsigned int oldSize, unsigned int newSize, unsigned int widthStep )
{
float ratio = (float)newSize/oldSize;
unsigned int k=0;
for( k = 0; k < n; k++ )
{
int dx1 =(int) ( ratio*(src+k*5)[0]+0.5);/*+0.5主要是为了四舍五入*/
int dy1 = (int)( ratio*(src+k*5)[1]+0.5);
int dx2 =(int) ( ratio*(src+k*5)[2]+0.5 );
int dy2 = (int)( ratio*(src+k*5)[3]+0.5);
dst[k].p0 = dy1*widthStep + dx1;
dst[k].p1 = dy2*widthStep + dx1;
dst[k].p2 = dy1*widthStep + dx2;
dst[k].p3 = dy2*widthStep + dx2;
dst[k].w = (src+k*5)[4]/((float)(dx2-dx1)*(dy2-dy1))
}
这是子函数

}

这是主函数的片段

for.....
for......//两个for循环
ResizeHaarPattern(&dx_s[0][0], Dx, NX, 9, size, width );
ResizeHaarPattern( &dy_s[0][0], Dy, NY, 9, size, width );
ResizeHaarPattern( &dxy_s[0][0], Dxy, NXY, 9, size, width);

问题就在这里 这三个函数 我任意屏蔽 其一,程序均可以正常运行。但是三个同时运行,程序死机。我怀疑会不会是DSP的栈不够用,导致函数切换的时候,不能正确的保存现场,程序跑飞了。还是其他原因,在这里先谢过 个位大神了 平台是DM6446 ARM+DSP处理器

Csdn user default icon
上传中...
上传图片
插入图片
准确详细的回答,更有利于被提问者采纳,从而获得C币。复制、灌水、广告等回答会被删除,是时候展现真正的技术了!
其他相关推荐
DSP程序死机(跑飞)的一些情况-硬件原因
 DSP和FPGA不一样,在DSP上运行的程序可能会会出现死机,也就是跑飞的情况,查死机基本是每个DSP或嵌入式工程师debug时都会经历过的。DSP死机可能是硬件造成的也可能是软件造成。 先说一下硬件造成的可能原因,遇到过的就一下4类, 1、复位电路不稳定;2.电源不稳定;3、时钟不稳;4、总线不稳定。下面分别讲解一下。 1、复位电路不稳定 很好理解,就是运行中突然有复位信号过来,
DSP程序死机(跑飞)的一些情况-软件原因
 前面对DSP程序死机的硬件原因进行列举,并给出相应的解决办法,今天将DSP程序死机(跑飞)的软件原因列举一下。 软件死机主要原因是1、堆栈溢出;2、数组溢出;3、访问指向空地址的指针;4、未声明的函数调用跑飞。 1、堆栈溢出 以TI CCS3.3为例,程序运行的堆与栈的空间大小都是由软件设计师自己定义分配大小的。一般出现问题就是为DSP软件运行设置的堆或栈的空间太小,而导致程序不能正
C语言小程序死机
# include int main() {     while(malloc(1));     return 0; }
关于malloc函数死机的问题
撸主自打开了博客,还没动过笔,最近一直在琢磨着写点啥,
STM32F429之六:IAP+UCOSIII死机问题
几个关键点:    1.IAP程序开启FPU(修改.s文件等)    2.跳至APP的跳转函数前关所有中断    3.APP中设置中断向量表偏移,开启中断     
关于STM32莫名死机的一些问题记录
问题描述 ZET6跑了ucosII系统,在运行过程中有时会出现死机的情况,经过硬件调试发现,是进入延时的时候导致的这个问题,延时函数是没有问题的,而且这个问题是偶尔出现 问题排查 死机之后指针指向了硬件错误中断,初步猜测是因为栈溢出,因为跑了系统,并且函数的嵌套层数比较多,导致栈内存不够,进入了硬件错误中断 解决方法 将函数分离出来,减少函数嵌套,因为每一个函数都会分配单独的内存空间,所以多层的函数
FreeRTOS中断调用api卡死
stm32+freertos。 这里我要说的是发生这种情况的另一种解决办法。 先说背景。 本来是要实现一个简单的功能,就是从串口接收数据通过队列发送给其中一个任务进行处理。 最先的问题是由于stm32的串口没有fifo,按照网上的资料实现了dma加空闲中断,这个问题就出现在空闲中断上。 反映出来的现象就是出现中断后程序没反映了,但是打断点调试又能正
关于STM32 使用sprintf 死机问题!
在使用 sprintf 函数时遇到的造成死机的两种原因:1、 指针未声明内存char *p; sprintf(p,&quot;%d,%d,%f&quot;,1,1,2.1);解决方法:对指针申请内存,或定义成数组类型。2、打印float/double 类型数据。解决方法:修改为int类型打印。有网友说栈空间不足造成的死机,本人测试后以上两种死机原因均为改善。启动文件中 Heap_Size 为 0x00000200修改...
关于C语言的memset容易出现的问题
今晚一个关于metset的问题一直调试不出来。部分代码如下:const unsigned int unmarked = 10000; int* diag_map = (int*)malloc(sizeof(int)*(num_rows+num_cols)); memset(diag_map,unmarked,sizeof(int)*(num_rows+num_cols)); for(i=0;i<n
【脑洞系列】c语言对死机系统的简单实现
c语言对死机系统的实现并不困难。代码写于初二,对c理解不是透彻,因此代码非常简单。 当时的实现思路是利用一个永远也关不掉的窗口对屏幕前方进行遮挡并且始终在最前。但是始终在最前这一思路始终没有实现。 以下是死机系统第一个版本的代码。 #include int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LP