MCore + GCC

Hello All,

I am working on a project based on the MCore MCU, and am having a rough
time getting a basic test program working correctly. The actual device that
I am working with is the O-Navi Phoenix AX which has an embedded MMC2114. I
am using a gcc 4.3.0 cross compiler under cygwin to build, and the PE Micro
CableMC and ProgMCZ to flash the chip. I compiled newlib along with gcc,
but am excluding it for now with the -nostdlib and -nostartfiles gcc flags.
The code I am working with is hosted at
http://code.google.com/p/cpuav/source/browse under trunk/AP_Test.

Included in the kit with this device is some example code which was
clearly written for CodeWarrior, so I had to adapt it to build under gcc. I
have gotten the example program to build and run correctly on the hardware,
however there are still problems as I cannot get a simpler program to work
correctly. Starting from the example program, if I modify main to simply
print a "hello world" to uart without modifying any of the other code, this
works as expected. However, when I remove the other functions so there is
just the main (and the device/serial setup code) which prints to uart - a
seemingly more simple program - it does not work!

I cannot think of what could cause this problem or how to approach
debugging it. If anyone has any pointers or suggestions, I would greatly
appreciate it. Please let me know if I can provide any more information.

Thanks,
Nick Hebner

hebnern wrote:
> Hello All,
> 
> I am working on a project based on the MCore MCU, and am having a rough
> time getting a basic test program working correctly. The actual device that
> I am working with is the O-Navi Phoenix AX which has an embedded MMC2114. I
> am using a gcc 4.3.0 cross compiler under cygwin to build, and the PE Micro
> CableMC and ProgMCZ to flash the chip. I compiled newlib along with gcc,
> but am excluding it for now with the -nostdlib and -nostartfiles gcc flags.
> The code I am working with is hosted at
> http://code.google.com/p/cpuav/source/browse under trunk/AP_Test.
> 
> Included in the kit with this device is some example code which was
> clearly written for CodeWarrior, so I had to adapt it to build under gcc. I
> have gotten the example program to build and run correctly on the hardware,
> however there are still problems as I cannot get a simpler program to work
> correctly. Starting from the example program, if I modify main to simply
> print a "hello world" to uart without modifying any of the other code, this
> works as expected. However, when I remove the other functions so there is
> just the main (and the device/serial setup code) which prints to uart - a
> seemingly more simple program - it does not work!
> 
> I cannot think of what could cause this problem or how to approach
> debugging it. If anyone has any pointers or suggestions, I would greatly
> appreciate it. Please let me know if I can provide any more information.
> 

The most obvious thing to try is to start with a working program, then 
remove small parts incrementally until it stops working - that could 
give you a clue as to where the problem lies.

I'm curious as to why you are using the MCore in the first place.  It's 
not really a mainstream core - my distributors and Freescale 
representatives advised against it when we looked at the MCore several 
years ago.

>hebnern wrote:
>> Hello All,
>> 
>> I am working on a project based on the MCore MCU, and am having a
rough
>> time getting a basic test program working correctly. The actual device
that
>> I am working with is the O-Navi Phoenix AX which has an embedded
MMC2114. I
>> am using a gcc 4.3.0 cross compiler under cygwin to build, and the PE
Micro
>> CableMC and ProgMCZ to flash the chip. I compiled newlib along with
gcc,
>> but am excluding it for now with the -nostdlib and -nostartfiles gcc
flags.
>> The code I am working with is hosted at
>> http://code.google.com/p/cpuav/source/browse under trunk/AP_Test.
>> 
>> Included in the kit with this device is some example code which was
>> clearly written for CodeWarrior, so I had to adapt it to build under
gcc. I
>> have gotten the example program to build and run correctly on the
hardware,
>> however there are still problems as I cannot get a simpler program to
work
>> correctly. Starting from the example program, if I modify main to
simply
>> print a "hello world" to uart without modifying any of the other code,
this
>> works as expected. However, when I remove the other functions so there
is
>> just the main (and the device/serial setup code) which prints to uart -
a
>> seemingly more simple program - it does not work!
>> 
>> I cannot think of what could cause this problem or how to approach
>> debugging it. If anyone has any pointers or suggestions, I would
greatly
>> appreciate it. Please let me know if I can provide any more
information.
>> 
>
>The most obvious thing to try is to start with a working program, then 
>remove small parts incrementally until it stops working - that could 
>give you a clue as to where the problem lies.
>
>I'm curious as to why you are using the MCore in the first place.  It's 
>not really a mainstream core - my distributors and Freescale 
>representatives advised against it when we looked at the MCore several 
>years ago.
>

I have tried incrementally removing pieces, but there does not seem to be
any pattern. It seems that if there is a bunch of extra code, it works, if
there is none, it does not. I cannot even imagine why this might be.

I was leery about using the MCore from the start of this project when I
was doing research and realizing that this chip was basically defunct.
Unfortunately, the PhoenixAX device was our only option in terms of price,
and now I know why. It is turning out to be a nightmare especially because
we cannot afford any sort of ONCE hardware which would really help.
Basically the only debugging tool that we have at this point is printing to
uart, which is much less than ideal.

The only other thing that I can think is maybe the chip is hitting an
exception, so I will try adding identifying handlers. Any other ideas would
be much appreciated.

Thanks,
Nick Hebner
The only other thing that I can think to do is