Port application from KL25Z128 to KL25Z64

[alex323qp]

Hi, I've been working on a project using the FRDM-KL25Z as development board, but the end goal was always to use the KL25Z64 as target MCU. I thought that migrating from the big brother version would be just a matter of using the "common" pins to both packages and make a few amendments to the linker file, but there seems to be more to it, isn't it?

The project started using mbed's libraries and migrating it to KDS at this stage is not an option unfortunately. I know my custom hardware works because:

* I replaced the device with the KL25Z128, and flashing the version of the code for this target (the code used in the dev boards) works fine.

* I also created a simple blinking LED app using KDS with PE for the KL25Z64, and it works ok as well.

I'm attaching my original linker and startup files (for the KL25Z128).  I just changed the MEMORY section FLASH and RAM values to match those of the KL25Z64:

MEMORY {   VECTORS (rx) : ORIGIN = 0x00000000, LENGTH = 0x00000400   FLASH_PROTECTION (rx) : ORIGIN = 0x00000400, LENGTH = 0x00000010   FLASH (rx) : ORIGIN = 0x00000410, LENGTH = 64K - 0x00000410   RAM (rwx) : ORIGIN = 0x1FFFF800, LENGTH = 8K - 0xC0 }

Note: the RAM ORIGIN was changed to the value used by linker file produced by PE for this target (MKL25Z64xxx4_flash.ld).

Any advice would be greatly appreciated!

Regards,

Alex.

Original Attachment has been moved to: mbed_MKL25Z4.ld.zip

[scottm]

I've run into a similar problem - I assumed the FRDM-K22F would be the board to use to try out the MK22FN1M0VLH12.  What I've discovered is that the MK22FN512VLH12 on the FRDM board apparently belongs to a newer generation and the part I'm using actually might be closer to the MK21FN1M0.  I think I can make it work on the FRDM board, but the part lacks the HSRUN mode and the crystal-less option with USB clock recovery so the example code needs modification.

The point is, don't assume the two devices are the same aside from the memory size.  And if anyone knows of a definitive matrix of all of the part numbers, their feature sets, and the families they belong to, I would very much like to see it.  I've been designing with Freescale and Motorola MCUs for over 20 years but moving to Kinetis has been a huge source of frustration.  I'm not sure if Freescale's ability to write, maintain, and organize documentation has really gone downhill so much in recent years, or if maybe their marketing department has won out and making their product line look good has taken priority over clear and accurate presentation of information.

Scott

[santiago_gonzal]

Hello Scott,

If you search a partnumber you can see the recommended evaluation platform, which will use the same silicon in almost every case you try.

Unfortunately you've come across the only sub-family that has huge differences between devices. Kinetis K22. Inside K22 family there are 2 "sub families".

- K22 between 128 Kb of Flash and 512 Kb without flex memory (Cost effective family).

- and K22 with 512 Kb + FlexMemory and K22 1Mb (Feature rich family).

In the case of Alexander Agudelo, I can confirm that inside KL25 he won't find any differences apart from Flash size.

In case you want to be sure about it, you can always check the silicon mask number printed in the chip.

Regards,

Santiago

[matthewkemp]

From this post, is it safe to assume that moving from MK22FN256VLH12 to MK22FN512VLH12 should be straight forward and the register set should be the same?  My main concern is that different datasheets exist for the parts.

[Hui_Ma]

Hi,

MK22FN256VLH12 is pin to pin compatible with MK22FN256VLH12 .

Beside of the Flash/SRAM size difference, there with some modules difference:

Module                        MK22FN256VLH12       MK22FN256VLH12 

Flexbus                        N/A                                 Yes

16bit PWM channels   12                                    20

PWM module               1                                     2

16bit timer channels      13                                 21

Wish it helps.

Have a great day,
Mike

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[scottm]

That would have been nice to know at the start.  Where should I have been looking for that information?

My problem now is that I selected the MK22FN1M0VLH12 some time back and now that I've finally got it running it's no longer recommended for new designs.  The MK22FN1M0AVLH12 is, however, still shown as active.  The parametrics are identical but I can't find anything that calls out the differences and after this experience I'm not about to assume they're equivalent.

Thanks,

Scott

[santiago_gonzal]

Hello Scott,

I'm not 100% sure so I don't want to confuse you again, but as far as I know, they are totally compatible.

The A in the partnumber means second revision of the silicon. If you check the errata of both devices, you will see that the second revision has a lot less identified erratas, because Freescale has tried to fix as many as possible without modifying the behavior of the device (Same peripherals, same registers, same everything inside).

In your other issue, you were jumping from one silicon to another totally different. This one should be a done deal :smileyhappy:.

Regards,

Santiago

[scottm]

Thanks for the reassurance.  It'd be really nice if there was a chronological change log in one place, but I did find the product brief that says the A indicates a silicon revision.  My concern was mainly that peripheral modules might have been changed to newer versions or something.  Looks like the reference manual shows just documentation fixes, and I've caught up on the mask set errata.

Anyway, I've hijacked Alex's thread enough.  Thanks for the answers.

Scott

[santiago_gonzal]

Hello Alexander,

Do you use the same package in both devices? 80 LQFP? If yes, you should be able to use the exact same code in both devices, as long as the external componets are the same, especially the external oscillator.

Regards,

Santiago

[alex323qp]

Hi Santiago, for development purposes I used the standard 80 LQFP that comes with the freedom board, but my custom board uses the QFN32 package. I however made sure that the pins used were available to both packages. As I mentioned earlier, I also tested the code with the QFN32 variant of the KL25Z128 and it worked fine, proving that the chosen pins/peripherals were correct.

So, do you reckon the linker/startup files are not the problem here?

A.

[alex323qp · Accepted solution]

Ok, I managed to solve the problem. It turns out that one of the CMSIS files (cmsis_nvic.c) used by mbed's framework has a hardcoded value for the RAM vector address of 0x1FFFF000. The fix was just replacing this with the right one: 0x1FFFF800.

I didn't test it but I'm assuming the changes I introduced to the MEMORY section of the linker file to point to the right FLASH and RAM length/origin values are also required.

I was so convinced the issue were in the linker file that I didn't even look around for other possible culprits. Thanks Santiago, your comment made me wonder if I was looking at the right place ;-).

A.

[santiago_gonzal]

Good catch Alexander!

I'm glad to see that people is using mbed for real projects :smileyhappy:

Regards,

Santiago