Codewarrior MQX example not running as a stand alone mode (without Debugging)

[yonggonlee]

I have asked the same issue but I am trying to rephrase it as it seems that no one really gets what I am trying to ask.

I am using Codewarrior 10.4 (Eval), Freescale MQX 4.0, with Tower K60N512. There are several example MQX project in MQX folder. For example, I can test 'GPIO' which lights up blue LED, blinks green LED, and turns on Yellow and Orange LEDs when SW1 or SW2 is pressed. It works just fine in debugging mode. But when I flash it and reset or power recycle, nothing happens.

When I try a non-MQX project, it works properly after flashing and reset.

Does anyone resolved this issue? I am switching from Keil uVision to Codewarrior, so I may be missing something really basic. It used to be just a click of load] button to flash my K60 tower with uVision and it works after reset or power recycling. I have been agonizing for more than a week just to figure out this.

Somebody! please shed some light on my ignorance!

[yonggonlee · Accepted solution]

Everyone thank you so much for your help. After a lot of frustration I just wiped out CW and Freescale MQX, downloaded latest versions of them (even though I knew I had latest version) and reinstalled them. And Wa-Lah! It is working without any issue. So I did not fix anything.

However, based on each comment I had a chance to learn a lot about Cortex M4 and CW. So I want to thank  you all!

By the way, it is my first time working with RTOS which is a whole new experience for a old timer like me. And I am so excited.

[VictorLorenzo]

Hi Yonggon,

I found myself a while ago with something similiar to that in one very small K20 test project.

Firstly I did not notice that (by default) the RAM configuration was selected, so no CPU flashing was done. When I selected the FLASH configuration the problem still persisted so I checked the target linking locations in the PE and linker configurations. Program code and constants sections were configured to be placed in RAM. I think it was some mistake I made when configuring the CPU for the first time.

Working with another microcontroller (not from freescale, but also Cortex+Eclipse based IDE) we also found something similar, it was caused by compiling the application against the hosted runtime library. I've not played with it in CW, but perhaps it works very similar.

Victor

[anthony_huereca]

Hi Yonggon,

  A couple of things could be happening. If using the GPIO example for a TWR-K60N512:

1) Make sure you select the "Int Flash Debug" target on the project before doing the compile. By default the projects use the RAM target.

2) After compiling, look at \mqx\examples\gpio\cw10\gpio_twrk60n512\Int Flash Debug and you should see .afx and .S19 files. As a sanity check, try flashing that file.

3) Make sure you select the gpio_twrk60n512_Int_Flash_Debug_PEOSJTAG debug target.

4) In that target, go to the "Debugger" tab, and under the "Debug" sub-tab, there is a "Program Execution" selection box. Make sure "Stop on startup at:" is selected, but change the radio dial to "Program Entry Point". This will let you step through the code from the very beginning, just in case you actually are flashing the part, but it's crashing at some point before it gets to the main task.

5) After flashing but while the debugger is still connected, make sure there actually is code in flash. Look at 0x4 and see if it looks like a valid starting address (as Norm mentioned).

Hopefully one of those suggestions help!

-Anthony

[Ben]

Lee, I have the same problem with another chip (using 10.4 too). I'll update you if I'll find solution to my case.

[ndavies]

Verify that your interrupt vector table is being inserted in the correct location in flash. The vector table should start at address 0. Make sure address 0x0 contains the top of stack address and address 0x4 has the pointer to your C initialization routines.

The Arm core loads the stack pointer from address 0 and then jumps to the address pointed to by memory location 0x04 on reset.