CW v10.4 / CF V1 core stack frame structure

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

CW v10.4 / CF V1 core stack frame structure

Jump to solution
498 Views
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

Labels (1)
0 Kudos
1 Solution
344 Views
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.

View solution in original post

0 Kudos
3 Replies
344 Views
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

345 Views
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 Kudos
344 Views
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 Kudos