Coldfire V2: Porting to EWL from MSL crashes application

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

Coldfire V2: Porting to EWL from MSL crashes application

Jump to solution
1,858 Views
cbhavi
Contributor III

Hello,

 

I was working on a V2 Coldfire controller (MCF5216) with Codewarrior v5.9 (Classic IDE) which is a pretty old one.

I am trying to port my application to the new Codewarrior v10.6 due to some license/support issues with win-7 and so far I have been unsuccessful.

The behavior of the code is extremely strange. With the debugger connected to the system, the code runs smoothly sometimes and hangs sometimes. This seems to happen at every alternate attempt to debug!

Also, after flashing the code, once the board is powered down and then powered up again(without the debugger connected), it doesnt do anything it is supposed to (Ex. clicking relays, switching LEDs etc.).

I have checked and re-checked my compiler/linker settings in the new IDE but nothing seems to work. (it works beautifully with the CW v5.9 though).

 

I have tried to see what the cause could be while debugging.

When hanged, on stopping the execution, the debug window shows the current point to be sometimes at the Illegal_Instruction_Exception, sometimes at the Access_Error_Exception and sometimes at an unmapped memory region.

The stack frame gives me information on from where the cpu went haywire, but it is always at a different point each time.

But, on examining the disassembly, the instruction pointed to by the stack-frame is either

MOVE.L (-0010,A6),D0

 

or

MOVE.L D0, (-0010,A6)

 

This seems to indicate that something is going wrong when either retrieving/storing something on the stack. But what?!!

The code compiles without any issues.

The only difference in the settings of the two CW versions is that the older v5.9 uses struct-alignment as '68k' and the new one (v10.6, eclipse) uses 'coldfire(long)' struct-alignment.

I also changed the struct-alignment to 68k in the new CW too, but it dint help.

 

I am clueless as to how to proceed on this; been stuck with this for quite sometime now!!.

I hope someone out there can help me out.

 

Thanks and Regards,

Bhavya

Labels (1)
0 Kudos
1 Solution
1,243 Views
TomE
Specialist II

Read my last post here:

https://community.freescale.com/message/356263#356263

This mentions that the parameter passing changed between CW7.1 and CW7.2:

Re: Updating CW 7.1 to 7.2, using MQX 3.3,  missing librarys

https://community.freescale.com/message/66959#66959

"CW7.2 uses a different way to pass parameters to functions (REG_ABI) compared to CW7.1, which uses STD_ABI by default. These methods are not compatible with each other."

Search (at top right of this page) for "REG_ABI".

Other posts said that prior to 7.2 you could select either option, and all the libraries and example code on Freescale's web site defaulted to STD_ABI. With CW7.2 that option was removed, and it changed to REG_ABI. So all existing Assembly code broke, and none of the sample code (in App Notes and so on) got updated. This traps everybody, but isn't documented anywhere that I can find. It might be in the documentation provided with CW somewhere, I've never had a copy to check.

Tom

View solution in original post

0 Kudos
5 Replies
1,243 Views
cbhavi
Contributor III

Thank you Tom and Paul.

The assembly functions were the issue. I declared the asm functions with the __declspec(compact_abi) and things worked perfectly.

And the assembly code for both the are controllers are ''exactly'' the same (not 'basically'! :smileywink: )

The only difference was that the application with MCF5216 was including a .BIN file of the bootloader. Maybe that's where things were going in different directions.

Thanks a lot, solved a big issue of mine.

Cheers!

-Bhavya

0 Kudos
1,243 Views
cbhavi
Contributor III

Thank you for your replies.

I have also ported another application recently, one involving MCF5213, to CW compiler v7.2 and I have had no problems with that.

It works like a charm.

Its curious, since both my applications, one with MCF5216 and one with MCF5213, have similar assembly code(startup routines basically) but the one with MCF5216 is problematic.

Any thoughts why?

Regards,

Bhavya

0 Kudos
1,243 Views
TomE
Specialist II

> Any thoughts why?

One isn't "basically", but is obviously different. It may be calling a function the other one doesn't. There may be library differences. It may be just a bug.

What is programming?

"To Code, Perchance to Debug".

Anybody can port code. Programmers have to do the OTHER half of their job when it goes wrong.

If you can't find the problem by inspection, then drag out the debug pod and see where it is going (wrong).

Tom

0 Kudos
1,243 Views
Dec
Contributor III

I seem to remember they changed the CW compiler at some point, V7.2 ?, so that parameters are passed in registers instead of on the stack.

Prior to this it was a configuration option.

If you've only C functions it shouldn't be a problem but if you've anything written in assembler expecting parameters on the stack those functions will need to be changed.

I'm on a limited internet connection here so can't check the exact details at the moment.

Paul

1,244 Views
TomE
Specialist II

Read my last post here:

https://community.freescale.com/message/356263#356263

This mentions that the parameter passing changed between CW7.1 and CW7.2:

Re: Updating CW 7.1 to 7.2, using MQX 3.3,  missing librarys

https://community.freescale.com/message/66959#66959

"CW7.2 uses a different way to pass parameters to functions (REG_ABI) compared to CW7.1, which uses STD_ABI by default. These methods are not compatible with each other."

Search (at top right of this page) for "REG_ABI".

Other posts said that prior to 7.2 you could select either option, and all the libraries and example code on Freescale's web site defaulted to STD_ABI. With CW7.2 that option was removed, and it changed to REG_ABI. So all existing Assembly code broke, and none of the sample code (in App Notes and so on) got updated. This traps everybody, but isn't documented anywhere that I can find. It might be in the documentation provided with CW somewhere, I've never had a copy to check.

Tom

0 Kudos