Kinetis K60, RCM_SRS0 and default handler

[lukaszbittner]

Hi,

I'm using K60N512 microcontroller. I'm trying to read SRS0 register, but every time, when the program calls RCM_BASE_PTR->SRS0, the program goes into default handler. Is necessary to enable any clock to read this register or there are other conditions to use this register?

Best regards

[kerryzhou · Accepted solution]

Hi Lukasz,

    From your problem description, I think your problem may be caused by the mismatching of chip and program .

  Please check you chip name carefully, check the mask set number:

    K60 100M have two silicon versions: 1.x and 2.x, there have a lot of register difference.

In 1.x reversion, it doesn't have RCM register, it just have MC register, RCM register is for 2.X reversion. You can find more details from this application note:

http://cache.nxp.com/files/32bit/doc/app_note/AN4445.pdf?fsrch=1&sr=1&pageNum=1

Chapter  3.3 Reset Controller Module (RCM)

So, if you check RCM register in K60 1.x version, because 1.x doesn't have this register, it will enter default hander.

Wish it helps you!

If you still have question, please let me know.

Have a great day,
Jingjing

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[lukaszbittner]

Hi,

I have checked and it is correct. My chip is marked as 0M33Z and it does not have RCM register at address 0x4007F000, it has only MC register at address 0x4007E000. When I used memory map according to this document http://cache.freescale.com/files/32bit/doc/app_note/AN4445.pdf  the program runs correctly.

Thanks all for their replies :smileyhappy:

[kerryzhou]

Hi Lukasz,

    It's clear now!

    Actually, this problem not only in K60 100Mhz, other kinetis K series 100Mhz also have two silicon reversions.

  Just pay attention to it.

Have a great day,
Jingjing

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[lukaszbittner]

Hi,

I use TWR-K60N512 board, it has PK60N512VMD100 microcontroller on board, so I think, you can have right. I will check it when I come back from work.

[egoodii]

I see.  I assumed your picture of 8/21 3:21P was of a debug session using this chip, showing SRS0 contents of 0x82 for a power-up indication of 'low voltage reset' and 'power on reset'.

Yes, we all should have looked down this thread:

https://community.nxp.com/message/529457#comment-529457

Your chip doesn't HAVE that SRS0 register, hence the fault.

It can be difficult to pair the right reference-manual with the right silicon rev....

[kerryzhou]

Hi Lukasz,

    Thank you for your more details, yes, TWR-K60N512 board is using 1.x k60 chip, so please use the according code from the attachment, don't use 2.x sample code, eg, TWR-K60D100 is using 2.x chip.

Have a great day,
Jingjing

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[egoodii]

As a 'core register' I don't believe it is subject to a control bit in the SIM_SCGC group, although there are a number of 'reserved 1' bits therein -- you might look at each of those.  Have you looked at BFAR after the fault?  Does it contain the 'expected' 0x4007_F000 address?  There are many 'fault types' in ARM, you might also look at the fault-type information -- could be an improper misaligned access, for instance.

I just access RCM_SRS0 directly, as in:

     if( RCM_SRS0 & RCM_SRS0_WDOG_MASK )

          printf("Watchdog ");

[lukaszbittner]

Hi Earl,

I could not find BFAR in EmbSys, so I have looked directly into memory, 0xE000ED38 address contains 0x00F00740.

I have tried to use following example:

RCM_SRS0; /*alone*/

and

uint8_t temp = RCM_SRS0;

and in both cases the program goes into default habdler. I do not have an idea why.

[egoodii]

So the fault is 'real enough', in that BFAR contains an address 'not likely to be occupied'.

It looks like 'somewhere' is an endianness problem -- BFAR clearly contains the right address, but byte-reversed!  I don't know where that 'comes up' in your tools or header, but look for something in those regards!

[lukaszbittner]

I use Kinetis Design Studio 3.0 and default configuration, so I have no any idea why it does not work. I'll try with older version of KDS.

[egoodii]

I don't use those tools, I use IAR and the 'project options' processor-tab has a checkbox for 'little' or 'big'.  I have never messed with such things myself -- I take the projects and default tool-settings (little)  'as they are' and it has always worked.  I don't even KNOW if you CAN alter the endianness-operation of these ARM implementations, as thru AIRCR.

[lukaszbittner]

I have checked with KDS 2.0 and I got the same issue. I did not change anything in the configuration panel. I checked out that address 0x4007f000 is rewritten into R3 and it has correct order.

[egoodii]

Maybe you should try forcing 'little' for endianness.

So are you saying you have stepped thru the individual assembly instructions, and R3 gets the proper value of 0x4007F000, AND you can 'see' that addressed contents correctly in a memory window, BUT when you step the code to let a load via R3 'happen' you get this fault???

Of course the tool may be 'fixing' endianness for you in a register display....

[lukaszbittner]

Yes, after ldr instruction,

the program gets into:

and R3 looks like:

and I have no idea what is going on.

[egoodii]

So the 'ldr r3' fetches the 32bit constant with a PC-relative 'load'.  ARM can't load a 32bit constant directly, so this is the way compilers make a 'small instruction' get such a 32bit constant, by allocating space for it after the code in a module.  Since R3 gets this value, I think we can assume THAT goes OK -- but you say it is at THIS instruction step that a fault occurs, not the very next assembly instruction (which I can't see)?  I assume your tool lets you single-step the assembly sequence...

[lukaszbittner]

This is the rest of a code:

I made a break point at line f8c, so I can confirm that default handler occurs when ldrb command is loaded.

And yes, KDS allows debugging step by step.

[egoodii]

What does a memory window including the range 4007_F000 show?

I'm still trying to understand that previous memory window showing the BFAR Dword with the 'wrong' endianness.  What do you get if you load BFAR as the first instruction in the default-handler?

[lukaszbittner]

Here you are:

I do not exactly understand what you mean say "if you load BFAR as the first instruction in the default-handler?" Do you mean altering value in BFAR register when he program gets into default handler after ldrb instruction?

When I look at CortexM4_TRM_r0p1.pdf document I see that all values have changed order, because for the ID_PFR0 (0xE000ED40) default value is 0x00000030, I have 30000000, for ID_PFR1 (0xE000ED44) default is 0x00000200, I have 00020000.

[egoodii]

It certainly looks like the debugger can ''find' these registers!

As part of my 'complete hard fault handler' that gives a 'large dump' of registers, I have this:

printf("BFAR = %x\n", (*((volatile unsigned long *)(0xE000ED38))));

So maybe there is a 'memory window' property to tell IT to display 'big' or 'little' endian, and THAT is all we are running into there.

So, applying endian-swap to a few other registers, we find CFSR is 0000_8200, so 'bus fault' part of that (third byte) 82 means BFAR is valid, and the stacked PC points to the faulting instruction (not much help there).  DFSR shows 1, which seems to be an Alignment Fault.  I know it is shown as an 8-bit register, but what happens if you go ahead and pull a whole 32?

I DO WISH that ALL 'sample projects' would include a comprehensive hard-fault dump handler, as these kinds of faults trip up many users...

[egoodii]

So if you are interested, attached is my crt0.s vector-table, which ends with the 'first part' of the default handler, contained in vectors.c.