Kinetis bare metal projects not running out of Flash.

[matthews]

I am using CodeWarrior 10.4 with a K60 and a K25 project.

I have created basic bare-metal projects that toggle LEDs for each of the K25 and K60. Both applications run correctly out of Debug (i.e. right clicking project and selecting "Debug as"). Both projects fail to run out of flash. I've tried flashing multiple ways... selecting "Run as" and selecting the flash utility via the lightning bolt on the toolbar. The flash downloads appears to work correctly but the application never runs. This same application runs via the debugger. What am I missing to make it run out of flash?

I am able to flash a simple MQX based application that toggles LEDs on the K60. I'm not sure what the difference is between the MQX project and the bare metal project.

[matthews]

I created a second/new K25 bare metal project that duplicates the first project. I am able to flash the K25 processor from this second project.  Not sure what went wrong with the first project.

Flashing the program via the "Run as" option successfully flashes and starts the newly loaded application.

Flashing the program via the lightning bolt/stand-alone programmer also successfully flashes. When flashing via the lightning bolt a manual reset of the board is required to start execution of the newly downloaded application.

An equivalent K60 project runs fine out of the debugger but fails to run at all via the flash options.

[Jorge_Gonzalez]

Hello Matthews:

I am guessing that you are using printfs maybe?. The default output/input for the console functions is the debugger console. If you run the project standalone, then the MCU tries to communicate with the debugger and gets stuck. If this is the case, try commenting out all your printfs, getchars and the like.

Regards!

Jorge Gonzalez

[mjbcswitzerland]

Hi

Check the way that the watchdog is being handled (reset) - see page 33 of the following for discussion about it: http://www.utasker.com/docs/KINETIS/uTaskerV1.4_Kinetis_demo.pdf

Also verify that the linker script is correct - when you have loaded to flash, do a memory view of the FLASH from 0x00000000. Check that the first lomg word location has the expected initial stack pointer value and the second the address of where code's entry point - set the PC to this address and verify that the disassembled code there looks reasonable.

When debugging, the debugger may be initialising some registers (like watchdog), or setting the start address (to the start up code but not via the reset vector). Both may enable operation in one configuration but then fail on a 'real' reset or a different target configuration.

Regards

Mark