Initial PC address for KL25 does not match?

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

Initial PC address for KL25 does not match?

Jump to solution
1,006 Views
quevedo
Contributor V

I am using the FRDM-KL25 board as a tool for teaching basic software in an engineering course. As I am creating experiments, and executing them myself, I found something strange.

At Reset, Kinetis L processors first fetch the initial SP address at 0x00000000 position. Then, it fetchse initial PC address at 0x00000004 position. When I created a project in CodeWarrior 10.4, I used Debugger Shell to read memory contents, and found the following values (corrected for endianess):

SP: 0x20003000; PC: 0x0000085D

Strange, PC address does not seem to be aligned in a 4-byte boundary. And when I look in the assembly code, at the Disassembly window, I see startup code (label __thumb_startup) at 0x0000085C address.

Can someone explain why CodeWarrior generates a code that commands CPU to fetch one memory position after the one it should? And why the program runs OK even with this supposed error? I expect to comment that on my course.

Thanks in advance,

Antonio Quevedo

0 Kudos
1 Solution
683 Views
BlackNight
NXP Employee
NXP Employee

Hi Antonio,

the FRDM-KL25Z is using an ARM Cortex-M0+. This core only supports the 'thumb' instructions. Other cores can support the 'thumb' or normal ARM instructions. In order for the core to distinguish between thumb and non-thumb instructions, the least significant bit is used for addresses. This is the so called 'thumb bit'. So if an address is odd (with that bit set), the core knows that it jumps to a thumb address.

It is just for the Cortex M0+ that it only supports thumb, so all function pointer values have that thumb bit set.

I recommend that you have a look at the ARM documenation, or maybe at (http://paulkilloran.com/arm/Lecture_7.pdf) as this provides a nice lecture :-)

I hope this helps.

Erich

View solution in original post

0 Kudos
3 Replies
683 Views
quevedo
Contributor V

Thank you both. I am aware that M0+ is a "thumb-exclusive" machine, but I thought that for this reason, it would not be necessary to use the "thumb bit", so I forgot about it. Anyway I suppose that CW keeps using odd-address calls so code can be ported to ARM machines with the full ARM set.

Erich, the lecture you provided is really nice :smileyhappy:

Once more, thank you.

0 Kudos
684 Views
BlackNight
NXP Employee
NXP Employee

Hi Antonio,

the FRDM-KL25Z is using an ARM Cortex-M0+. This core only supports the 'thumb' instructions. Other cores can support the 'thumb' or normal ARM instructions. In order for the core to distinguish between thumb and non-thumb instructions, the least significant bit is used for addresses. This is the so called 'thumb bit'. So if an address is odd (with that bit set), the core knows that it jumps to a thumb address.

It is just for the Cortex M0+ that it only supports thumb, so all function pointer values have that thumb bit set.

I recommend that you have a look at the ARM documenation, or maybe at (http://paulkilloran.com/arm/Lecture_7.pdf) as this provides a nice lecture :-)

I hope this helps.

Erich

0 Kudos
683 Views
dieterteuchert
Contributor IV

Somewhere i read: "PC bit 0 is set in order to enforce Thumb mode". You can find the details somewhere else.

I first encountered this "odd" behaviour when i wrote a procedure to copy other procedures into SRAM for benchmark purposes, because it applies to all function pointers. As long as you use function pointers for calling and for nothing else, the linker automatically does the right thing .