LPC MicrocontrollersのトピックRe: RAM sections

RAM sections

lpcware — Wed, 15 Jun 2016 17:11:53 GMT

Content originally posted in LPCWare by IanB on Fri Aug 14 09:00:19 MST 2015
Could someone please tell me the correct assembler directive for allocating RAM into sections? I'm using the automatically generated linker file. _debug.ld

The linker file appears to call the sections .bss, .bss_RAM2 and .bss_RAM3

but if I use the assembler directives:

.section .bss
(memory definitions)
.section .bss_RAM2
(more memory definitions)

etc.

The assembler appears to want to put them all in RAM0_4 and then tells me there isn't enough room.

It wants to put the stack at the top of RAM0_4 (understandable, as thats the section that can't be switched off) so I need to leave plenty of room in RAM0_4 and then start on RAM1_4, which I would have expected the directive .section .bss_RAM2 to do.

If I call the section .section .RAM2 the it doesn't know where the address is.

I'm using .bss not .data because all the memory needs to be zeroed and not pre-loaded with any values.

Re: RAM sections

lpcware — Wed, 15 Jun 2016 17:11:54 GMT

Content originally posted in LPCWare by lpcxpresso-support on Fri Aug 14 10:14:35 MST 2015

Quote: IanB
Could someone please tell me the correct assembler directive for allocating RAM into sections? I'm using the automatically generated linker file. _debug.ld

The linker file appears to call the sections .bss, .bss_RAM2 and .bss_RAM3

but if I use the assembler directives:

.section .bss
(memory definitions)
.section .bss_RAM2
(more memory definitions)

etc.

The assembler appears to want to put them all in RAM0_4 and then tells me there isn't enough room.

It wants to put the stack at the top of RAM0_4 (understandable, as thats the section that can't be switched off) so I need to leave plenty of room in RAM0_4 and then start on RAM1_4, which I would have expected the directive .section .bss_RAM2 to do.

If I call the section .section .RAM2 the it doesn't know where the address is.

I'm using .bss not .data because all the memory needs to be zeroed and not pre-loaded with any values.

Don't confuse the section name with where you want to locate the section. The answer is found in your main linker script. You may need to create a custom script. This is now much easier using the Freemarker linker script templates. See

Freemarker Linker Script Templates

Thanks and regards,
LPCXpresso-Support

Re: RAM sections

lpcware — Wed, 15 Jun 2016 17:11:54 GMT

Content originally posted in LPCWare by IanB on Fri Aug 14 10:55:12 MST 2015
I'm no expert on Linker scripts, but doesn't this one define sections called .bss, .bss_RAM2 and .bss_RAM3 and state that they are in RAM0_4, RAM1_4 and RAM2_4 respectively?

Re: RAM sections

lpcware — Wed, 15 Jun 2016 17:11:55 GMT

Content originally posted in LPCWare by lpcxpresso-support on Fri Aug 14 12:09:05 MST 2015
Let's back up a minute. Exactly what are you trying to do, and which release of LPCXpresso are you using?

The linker has a concept of both input and output sections. Using the section directive in your assembler code, you are actually creating a named input section. The linker script combines input sections into named output sections. And, the names may be similar enough to confuse. So, for example, note the section name .bss_RAM2 is actually an output section in the managed linker script. If you had placed your data in an input section named .bss.$RAM2 (see crt_section_macros.h), it would have located in .bss_RAM2. If you care not to follow the naming conventions established by the managed linker scripts, you can always create your own scripts.

Thanks and regards,
LPCXpresso-Support

Re: RAM sections

lpcware — Wed, 15 Jun 2016 17:11:56 GMT

Content originally posted in LPCWare by IanB on Sat Aug 15 08:42:09 MST 2015
it's version 7.8.0

I was confused between input and output sections, now that I've put .bss.$RAM2 instead of .bss_RAM2, that fault has gone away. As I said, I don't like linker script and prefer to write my code to fit the automatically generated files.

Having said that, is this correct?

MEMORY
{
  /* Define each memory region */
  MFlash64 (rx) : ORIGIN = 0x0, LENGTH = 0x10000 /* 64K bytes */
  Ram0_4 (rwx) : ORIGIN = 0x2000000, LENGTH = 0x1000 /* 4K bytes */
  Ram1_4 (rwx) : ORIGIN = 0x2001000, LENGTH = 0x1000 /* 4K bytes */
  Ram2_4 (rwx) : ORIGIN = 0x2004000, LENGTH = 0x1000 /* 4K bytes */


}
  /* Define a symbol for the top of each memory region */
  __top_MFlash64 = 0x0 + 0x10000;
  __top_Ram0_4 = 0x2000000 + 0x1000;
  __top_Ram1_4 = 0x2001000 + 0x1000;
  __top_Ram2_4 = 0x2004000 + 0x1000;

Doesn't Ram2_4 start at 0x02002000 on an LPC1517?

That, and not my misunderstanding of sections, would explain why the stack gets overwritten.
The stack starts at 0x02001000 (first entry is 0x02000FFC), but when RAM2_4 is misallocated, a write to 0x02004FFC overwrites the stack at 0x02000FFC.

Re: RAM sections

lpcware — Wed, 15 Jun 2016 17:11:56 GMT

Content originally posted in LPCWare by lpcxpresso-support on Mon Aug 17 00:12:08 MST 2015

Quote: IanB

Doesn't Ram2_4 start at 0x02002000 on an LPC1517?

Yes it does. We'll fix for the next LPCXpresso IDE release. In the meantime, you can correct this for your project using the Memory Configuration Editor (see chapter 6 of the LPCXpresso 7.9.0 User Guide for more information).

Regards,
LPCXpresso Support

Re: RAM sections

lpcware — Wed, 15 Jun 2016 17:11:57 GMT

Content originally posted in LPCWare by IanB on Mon Aug 17 01:19:47 MST 2015
OK Thanks. I'll look up the memory configuration editor. In the mean time I implemented a temporary fix by editing the _debug_mem.ld file, and telling it that the linker files were no longer automatically generated.

Having decoded Z80 and 6502 address lines with 74LS138 ICs, I know why it overwrote the stack, but I would have expected a "HardFault" to be generated when writing to memory that wasn't there.