CW v10.4 / CF V1 core stack frame structure

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

CW v10.4 / CF V1 core stack frame structure

跳至解决方案
1,234 次查看
chicagomike
Contributor III

Hi All,

 

Can anyone point me to documentation on function stack frame structure for the MCF51JF128 in CW 10.4?

 

I'm throwing an "Error on operand read" exception and I'm trying to debug it. I suspect it has to do with deep call nesting and/or large stack frames, but I can't be sure because I don't understand the stack frame structure well enough.

 

I looked through all of the PDF files in Freescale\CW MCU v10.4\MCU\Help\PDF, but I can't find any documentation that deals with this subject.

 

Can anyone help?

 

Thanks,

 

Mike

标签 (1)
0 项奖励
回复
1 解答
1,080 次查看
chicagomike
Contributor III

Hi David,

Thanks so much for your response! It was very helpful.

I may have identified a problem with the FS USB stack v4.1.1:

In the file Freescale USB Stack v4.1.1\Source\Device\source\common\usb_framework.c, function USB_Strd_Req_Get_Status(), the function USB_Desc_Get_Descriptor() is called with the size parameter equal to (USB_PACKET_SIZE *)&u16DescSize. The problem is that u16DescSize is a local variable declared as a uint_16, and (USB_PACKET_SIZE *) is a uint_32 pointer. When USB_Desc_Get_Descriptor() is called from USB_Strd_Req_Get_Status() and the line *size = g_std_desc_size[type] is executed, the descriptor parameter ends up getting corrupted because it's using a uint_32 pointer to write to a uint_16 object.

This led to my problem because the descriptor parameter ended up pointing into unimplemented memory space and when the calling function tried to dereference the descriptor pointer, the processor threw an 'operand read' exception.

I tried declaring u16DescSize as a uint_32 instead of a uint_16. This indeed fixed my problem, and I'm no longer throwing the exception.

Have you heard of this before? Does this make sense to you, or am I deluded?

Thanks again for your kind assistance.

Mike

P.S. I'm telling you all of this because I think that you're a Freescale employee. If you're not, my apologies.

在原帖中查看解决方案

0 项奖励
回复
3 回复数
1,080 次查看
DavidS
NXP Employee
NXP Employee

Hi Mike,

Head to the product page for the MCF51JF128, click Documentation tab and filter on Reference Manuals.

Click on the CFPRM.pdf and it has exception stack frame information.

Chapter 11

Exception Processing

The MCF51JF128RM.pdf has information as well.

11.3.2.1 Exception Stack Frame Definition

Regards,

David

1,081 次查看
chicagomike
Contributor III

Hi David,

Thanks so much for your response! It was very helpful.

I may have identified a problem with the FS USB stack v4.1.1:

In the file Freescale USB Stack v4.1.1\Source\Device\source\common\usb_framework.c, function USB_Strd_Req_Get_Status(), the function USB_Desc_Get_Descriptor() is called with the size parameter equal to (USB_PACKET_SIZE *)&u16DescSize. The problem is that u16DescSize is a local variable declared as a uint_16, and (USB_PACKET_SIZE *) is a uint_32 pointer. When USB_Desc_Get_Descriptor() is called from USB_Strd_Req_Get_Status() and the line *size = g_std_desc_size[type] is executed, the descriptor parameter ends up getting corrupted because it's using a uint_32 pointer to write to a uint_16 object.

This led to my problem because the descriptor parameter ended up pointing into unimplemented memory space and when the calling function tried to dereference the descriptor pointer, the processor threw an 'operand read' exception.

I tried declaring u16DescSize as a uint_32 instead of a uint_16. This indeed fixed my problem, and I'm no longer throwing the exception.

Have you heard of this before? Does this make sense to you, or am I deluded?

Thanks again for your kind assistance.

Mike

P.S. I'm telling you all of this because I think that you're a Freescale employee. If you're not, my apologies.

0 项奖励
回复
1,080 次查看
DavidS
NXP Employee
NXP Employee

Hi Mike,

yes I'm with Freescale.

I will find correct USB people to pass this along too.

Very good debugging.  Thank you for posting.

Regards,

David

0 项奖励
回复