The RAM is actually half the size as well (8k), I guess I do need to make changes?

Yes, RAM is the main issue. First of all, it of course needs to fit in the reduced RAM. (KL25 by default compiles with ARM lib, uARM lib is smaller and might help you if it is a bit too large. Don't ask me how to set that, also depends on which compiler you use. Because I don't know if currently you can do the required changes in the online compiler. For sure the only way which used to work was deleting the .sct file and importing a new one from your PC).

Anyway, I could post what you need to do here, but that was done before, have a look at: https://developer.mbed.org/questions/4669/KL25Z-production-with-less-flash-memory/

This would be great to make as Cookbook page, but the mbed staff has decreed that cookbook is going to be removed for whatever reason makes sense to them.

I actually compile my project offline with GCC. So my startup_MKL25Z4.s is a bit different from the one you indicated in your post. Mine has Stack_Size, 0x80 and Heap_Size, 0x80 sections. I'm guessing I just need to change those two to 0x40?

I didn't really see anything in that file to modify the RAM. I found in my MKL25Z4.ld however, the following structure:

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

I'm hoping changing some values there would do the trick?

Not familiar with how GCC handles it, but 0x80 would seem more like an initial size than the actual size. The most important part would be setting the stack pointer which by default is set to the top of the RAM, to the new top of the RAM. It could be that 16k - 0xC0 which needs to be modifief to 8k-0xC0, but i am not sure about it.

Not sure, but can you use the FRDM board to program it if you use it as CMSIS DAP debugger? It won't work as drag and drop programmer, but I am not sure if it also does not work when it operates as debugger.

We have a custom boot-loader so uploading new programs is not an issue. My only (other) problem is that all programs I compile start at 0x00000000, but the boot-loader requires the application to execute from a specific location: 0x00008000.

Any advice on this?

Ahh so this is not actually a Mbed related question, pity you did not mention the whole storey form the outset.

Try using KDS or Keil, you can easily set the flash/RAM and change the program start position. I know you can modify Mbed exported project in Keil, not sure about KDS though. Perhaps others may have more info on this. You could also ask questions and search their forums.

Using uTasker bootloader? that has the same flash load offset. If so he has quite a few tutorial videos that are good.

@Erik I have never tried using CMSIS DAP debugger, I have only used the MSD drag and drop programming function. Time vs Money, decide to get the Segger Flasher Portable. Programs every ARM chip, any start position, .BIN or .HEX and can select Flash erase sectors and works fast. You get what you pay for.

Thanks @Paul,

I’m not sure why you say this is not mbed related? The full project is based on mbed. The only non-mbed bit is the bootloader for which I’m not really asking anything.

I think the questions are quite valid:

• How to port an mbed application to another MCU, and,
• How to change the startup location

KDS is not an option, importing an mbed project is not that straightforward and ProcessorExpert generates a huge binary. So I’d prefer to stick to mbed for now.

The bootloader is based on Freescale’s KBOOT.

I'll continue experimenting and report back if any findings.

Yes please, that would be good if you would report back how you get on Alexander. I have been trying to find a way to do this with the K22F chip. This does have a very usable flash resident MSD type boot capability. But I came unstuck using the existing libraries and compiling on Mbed with that start offset. Its set in the compiler and only the Mbed guys can set this.

I want to utilise the larger 1Mb flash K22F version so I can store static graphics to use on a larger LCD display, programming this using the Segger flasher. But found since the last Mbed update one of the important files that is 'greyed' out could not longer be edited and imported back.

The other problem of course is the programming part. For Mbed to accept a 'new' target platform even if it shares much of the same library functions, it must have a 'drag and drop' programming facility and ideally a CMSIS-DAP debug capability. That clearly requires a secondary interface chip with suitable firmware so others can use the platform without an independent programmer.

I'm hoping that V3.0 may extend the compiler functions making it possible to edit the start up parameters for users to do what we are trying using our own programming facility, but not holding my breath here.