Program Flashing Error

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

Program Flashing Error

670 Views
mithunp_s
Contributor III

Hi All,

I'm again back with one peoblem. One of my customer has built a bare board project in CW 10.3 for Kwikstick board. Customer program runs very fine in debug mode, but after coming out of codewarrior and power on reset the board is not functioning as expected. I tried with Kwikstick LCD sample program, this program runs fine both in debug mode aswell after power on reset (Independent of codewarrior).

Please find the debug configuration settings screenshot, i"m sure we running the program in flash.

Please some one guide how this can be solved.

Rgds

Mithun

0 Kudos
4 Replies

361 Views
mithunp_s
Contributor III

Hi Christopher,

Yes customer is using GCC complier, please find attached startup code.

I have one more doubt, please chech below clock setting is correct

core_clk_mhz = 21;

core_clk_khz = core_clk_mhz * 1000;

periph_clk_khz = core_clk_khz / (((SIM_CLKDIV1 & SIM_CLKDIV1_OUTDIV2_MASK) >> 24)+ 1);

Regards

Mithun

0 Kudos

361 Views
chris_brown
NXP Employee
NXP Employee

Hi Mithun,

What I was really looking for was a pure assembly file.  In the Kinetis sample code, there is usually a crt0.s file with an __startup function where the program actually begins.  This function is written in assembly and there are some differences between the FSL compiler and GCC compiler that can trip you up.  In short, assembly code that needs to be interpreted as thumb instructions need to be declared as a .thumb_func like the example below:

    .global __startup

    .text

        .thumb_func

    .type __startup, %function

Is your project using the Kinetis crt0.s file?

As for your second question, this looks to be correct iff the __init_hardware function is the only hardware initialization function you are using.  The Kinetis K40 default clock configurations bring the core clock up at 21 MHz (actually it is 20.971520 MHz).  The peripheral clock will be this frequency divided by the OUTDIV2 value in the SIM_CLKDIV1 register.  The one change I would suggest making is instead of shifting right by 24, shift by SIM_CLKDIV1_OUTDIV2_SHIFT.  This way, the code is a little more readable and as long as you are using the Freescale provided header files you shouldn't have a problem with this part of the code.

Hope this helps,

Chris


0 Kudos

361 Views
chris_brown
NXP Employee
NXP Employee

Hi Mithun,

I have seen something like this before.  What was happening in my system was that the downloaded program was not compiled completely in thumb mode (specifically my initial startup code).  Is your customer using the GCC compiler in CodeWarrior 10.3?  (To verify this, pull up the project properties, select C/C++ Build -> Tool Chain Editor.  Both drop down selection boxes will list ARM Ltd Windows... if the GCC compiler is being used).

If the GCC compiler is being used, there are some differences that can easily trip up customers, specifically with the assembly startup that is contained in most of the Kinetis example code.    It would also be helpful if you could post any assembly code files in the project. 

Thanks,

Chris

0 Kudos

361 Views
UK_CF_FAE
NXP Employee
NXP Employee

Same as Chris, I have seen this problem before.

I think that you are successfully programming the flash on your board - JLink is good for this. 3 possible sources for the error that you described:

1) Code for the CM4 must be aligned to 2-byte boundaries. This means that all instructions must be aligned to an even address. The compiler will make certain of this for you. However, the reset vector at address 0x0000_0004 must be ODD. This is because the address is used to signify to the core that the THUMB instructionset is being used. Check with a debug setting that the value in address 0x0000_0004 is ODD. In my example code, the program starts at address 0x0000_04d8 but the rest vector is '04d9. The debugger normally overrides the reset vector and so it masks the problem.

2) Could be a clock configuration issue - debugger may set up the clock for you, but when you run stand-alone, the code hangs up in a while() loop waiting for the PLL to lock or something similar.

3) The debugger is doing something that your code does not do. Normally the JLINK runs a script when it connects to the target - my CW10.3 JLINK project here runs a script:


${ProjDirPath}/Project_Settings/Debugger/init_kinetis.tcl

Check to see if the script is doing something that your code should be doing.

Good luck!

Mark

0 Kudos