RAM too big with LPC11U24.ld linker file

[FrankBuss]

I've modified targets.py so that I can compile the mbed libraries with ARM GCC for my LPC11U24 microcontroller. There was a problem in the LPC11U24.ld linker script, which caused interesting problems. I have the LPC11U24FBD48/301 microcontroller. Note the "/301" and see the datasheet (UM10462, Rev. 4.1 — 19 July 2013, page 15). It has 6 kB SRAM, starting at 0x1000 0000. The datasheet says the /401 version has 8 kB SRAM, starting at 0x1000 1800. Maybe would be good if I could specify this for the "-m" parameter for the make.py and build.py scripts. The new line in LPC11U24.ld, which seems to work (at least no funny 0-bytes anymore when trying a printf("%i", 123)) : RAM (rwx) : ORIGIN = 0x100000C0, LENGTH = 0x1740

[emilmont]

Hi Frank, the way we handle these differences among microcontrollers of the same family is (specifically to your case):

1. Add a new target: LPC11U24_301
2. Move the TARGET_LPC11UXX/TOOLCHAIN_* directories under: TARGET_LPC11UXX/TARGET_LPC11U24
3. Create a new directory TARGET_LPC11UXX/TARGET_LPC11U24_301 containing the correct linker script for this new target.

We are happy to accept a pull request with the above changes, but we will not implement them ourself, because we do not have a board with such chip in the office.

Cheers, Emilio

[FrankBuss]

Hi Emilio,

that's no problem, I can send you a board for free, if you like. It is a prototype of my http://www.crazycartridge.org project. You don't need the FPGA and external SRAM, so I would just solder the microcontroller, USB connector, crystal oscillator and the LEDs. But I can create a pull request, too.

Do you have a board with the /401 chip? According to the datasheet, this should not work with the current linker script, because the SRAM starts at 0x1000 1800, but maybe it is mirrored to 0x1000 0000, or a bug in the datasheet? I could order a /401 version with my next parts order to verify it with one of my prototype PCBs. Maybe better if I use this larger version anyway, the price difference for the chip is just 0.21 EUR.

Cheers,

Frank

[emilmont]

According to the datasheet, this should not work with the current linker script, because the SRAM starts at 0x1000 1800

No, I think you are misreading the datasheet at page 15:

• The LPC11U24/301 memory goes from 0x1000 0000 to 0x1000 1800 for a total of 6 Kbytes as expected.
• The LPC11U24/401 memory goes from 0x1000 0000 to 0x1000 2000 for a total of 8 Kbytes as expected.

that's no problem, I can send you a board for free, if you like.

Yes, that would save us time. This is the ARM address. (just add my name: Emilio Monti).

Actually, giving another look at the code, the startup file is independent of the memory map, because the start of the stack is passed as a symbol, therefore, I would apply just this change:

1. Add a new target: LPC11U24_301
2. Move the TARGET_LPC11UXX/TOOLCHAIN_GCC_ARM/LPC11U24.ld to TARGET_LPC11UXX/TOOLCHAIN_GCC_ARM/TARGET_LPC11U24/LPC11U24.ld
3. Create a new file TARGET_LPC11UXX/TOOLCHAIN_GCC_ARM/TARGET_LPC11U24_301/LPC11U24.ld containing the correct linker script for this new target.

Cheers, Emilio

[FrankBuss]

You are right, I was confused by the memory map drawing and didn't calculate the numbers, your explanation makes sense.

I'll ship the board tomorrow. To the "Primary Address" or "Captial Park Address"?

Cheers,

Frank

[emilmont]

I'll ship the board tomorrow. To the "Primary Address" or "Captial Park Address"?

Thanks. To the "Primary Address".

Cheers, Emilio

[emilmont]

Hi Frank, I received the board, thank you.

I added an LPC11U24_301 target: https://github.com/mbedmicro/mbed/commit/0843613136dc30cba6f731e9b6f273e4942256c2

This was also interesting for us because it is the first example of two target microcontrollers that are identical apart for the memory size. As you can see, we had just to add a new linker script with the correct RAM memory region length.

Happy hacking, Emilio

[FrankBuss]

Thanks, looks good (but the comment "Linker script for mbed LPC1768" in the linker script is wrong). BTW: you can keep the board, in case you need it for regression testing someday.

[speachy]

For what it's worth, this "identical except for RAM/Flash sizes" situation is pretty common -- The microcontrollers I'm most familiar with are the STM32F1 series, and there are five sub-families. Within those sub-families, the only difference from a software perspective is the amount of RAM, flash, and the max clock speed. (Indeed, from a linker perspective, that's the only difference between the entire STM32 line, but obviously packaging makes a difference as to which I/Os are exposed..)

So for my (non-mbed) code, I used a single linker family for the entire STM32F1 family (we had three different targets) instead, running it through CPP with something like -DMCU_FLASH_SIZE=131072.

[emilmont]

Hi Solomon, Yes, starting to use a template for the generation of the "linker script"/"scatter file" is an option we are considering. I think it will be a natural evolution after we will pass a certain number of targets.

Cheers, Emilio