PK60DN512Z hardfault during __call_static_initializers (MK60DN512 fine)

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

PK60DN512Z hardfault during __call_static_initializers (MK60DN512 fine)

1,432 Views
PhilV
Contributor III

I have a codebase that works fine on the MK60DN512, and I am trying to port it to run on the prequalification early part, PK60DN512Z.

I have configured codewarrior Processor Expert to target the "MK60DN512ZVMD10" as there is no "PK..." part, but as I understand it they should be identical for this purpose?

The code has been regenerated, and I have adjusted register names in my code where necessary, however I am hitting a fault early in the bring-up sequence.

startup.c gets to the following branch instruction:

		//	call C++ static initializers
		bl	__call_static_initializers

At some point during this the fault occurs - I've stepped through at the instruction level but didn't see anything revealing. It seems that the error occurs on a "MOVS" instruction (location 00000042 in the listing below):

00000034: ldrh r5,[r4,r5]
00000036: movs r0,r0
00000038: ldrh r5,[r4,r5]
0000003a: movs r0,r0
0000003c: ldrh r5,[r4,r5]
0000003e: movs r0,r0
00000040: strh r1,[r2,#62]
00000042: movs r0,r0
00000044: strh r1,[r2,#60]

At that time (at 00000040):

  • r1 = 0x0000A7D6
  • r2 = 0x00000000
  • r0 = 0x00000001

Once the fault occurs the System Control Registers look at follows:

System Control Registers 
SCB_ACTLR 0x0 0xe000e008
SCB_CPUID 0x410fc240 0xe000ed00
SCB_ICSR 0x803 0xe000ed04
SCB_VTOR 0x0 0xe000ed08
SCB_AIRCR 0xfa050000 0xe000ed0c
SCB_SCR 0x0 0xe000ed10
SCB_CCR 0x200 0xe000ed14
SCB_SHPR1 0x0 0xe000ed18
SCB_SHPR2 0x0 0xe000ed1c
SCB_SHPR3 0x0 0xe000ed20
SCB_SHCSR 0x0 0xe000ed24
SCB_CFSR 0x400 0xe000ed28
SCB_HFSR 0x40000000 0xe000ed2c
SCB_DFSR 0x9 0xe000ed30
SCB_MMFAR 0xe000edf8 0xe000ed34
SCB_BFAR 0xe000edf8 0xe000ed38
SCB_AFSR 0x0 0xe000ed3c

 I'm not sure that this is telling me an awful lot though:

  • ICSR is just showing that we are now in the interrupt handler (which is correct)
  • CFSR.IMPRECISERR bits[ 10:10 ] = 1 a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error.
  • HFSR.FORCED bits[ 30:30 ] = 1 forced HardFault

Where do I go from here to determine why I get the hardfault on this target, but not on the MK60DN512?

The linker file in use is the same for both, and I believe that should be ok as they should be identical.

The (working) MK60DN512 is mask 5N22D, and the (non-working) PK60DN512Z is mask 4N30D; I've looked through the errata and can't see anything that would relate to this, but perhaps I missed something?

Thanks in advance!

Labels (1)
0 Kudos
4 Replies

1,289 Views
PhilV
Contributor III

I addition to the above, it seems the that linker script had been overwritten at some point during the work, and the ".programbuf" section was no longer present. - When I reinstated this (and applied some workarounds based on the above replies) I've made more progress.

I have the project configured in Processor Expert for the MK60DN512VMD10 cpu, and am trying to setup the same project in the same way for the MK60DN512ZVMD10.
For the most part (so far!) this has largely amounted to changing pin names in the GPIO_LDD components (same pins, slightly different name in the cpu definition, quite annoying ), however I've reached a sticking point with Channel19 of ADC1 (component Init_ADC).
For the non-Z version of the CPU I have this:


MK60_ADC1_Channel19.png

However on the 'Z' version of the CPU I have the following error if I try to do the same:

MK60Z_ADC1_Channel19.png

The detailed tooltip popup for each is as follows:

MK60DN512:
MK60DN512 ADC1 Ch11MK60DN512 ADC1 Ch11

MK60DN512Z:
MK60DN512Z ADC1 Ch11MK60DN512Z ADC1 Ch11

I've search the above provided documents, but couldn't see anything that related to ADC (in a way that might affect this).
Is this an actual device difference, or an issue with the ProcessorExpert logic? - Either way is there any more information available and as to how I might be able to work around it?

Thanks again!

0 Kudos

1,415 Views
EdwinHz
NXP TechSupport
NXP TechSupport

Hello @PhilV 

Both the MK60DN512 and the PK60DN512Z are part numbers for the same controller, however they represent different silicon revisions. With different silicon revisions, there are also many differences overall which means that the code used for one will most definitely not fit the other. This is all described in the following Application Note: https://www.nxp.com/docs/en/application-note/AN4445.pdf

 

BR,

Edwin.

1,371 Views
PhilV
Contributor III

Many thanks for this information, I shall take a look through the AN - I had to this point only had the errata sheets.

have reconfigured CodeWarrior Processor Expert to target the "MK60DN512ZVMD10" as there is no "PK..." part, but I think they should be identical for this purpose since they are both "Z" silicon?

The table at the start of the AN shows this:

PhilV_0-1641285861773.png

My "4N30D" part is therefore obviously a "1.4", however can you tell me where the 5N22D fits in? Originally I thought perhaps a higher "number" was a newer version, but from the table above "2N22D" is newer than "4N30D", so that logic does not follow.
I also have a MK60DN512Z part that has silicon mask 8N30D ... are you able to advice which 'version' that would be as well please?

0 Kudos

1,361 Views
EdwinHz
NXP TechSupport
NXP TechSupport

Of course!

You can find this information on Table 1 of the following document: https://www.nxp.com/docs/en/engineering-bulletin/EB782.pdf

 

BR,

Edwin.