I have built and installed gcc toolchain on my debian machine and tried to compile the lpc2148_freertos project downloaded from this group. I got the following error.
hash@anagham:~/Downloads/Academic/RnD/lpc2148_freertos$ make
arm-elf-gcc -Wall -Wextra -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wunused -D RUN_FROM_ROM -D GCC_ARM7 -I. -I ./FreeRTOS_CORE -I ./LPC2148_PORT -I ./LPC2148_Serial -I ./LPC2148_RTC -mcpu=arm7tdmi -Tlpc2148-rom.ld -O3 ./LPC2148_PORT/portISR.o LPC2148_Serial/serialISR.o LPC2148_RTC/rtcISR.o main.o LPC2148_Serial/serial.o LPC2148_RTC/rtc.o ./FreeRTOS_CORE/tasks.o ./FreeRTOS_CORE/queue.o ./FreeRTOS_CORE/list.o ./LPC2148_PORT/heap_2.o ./LPC2148_PORT/port.o -nostartfiles boot.s -Xlinker -olpc4148_freertos.elf -Xlinker -M -Xlinker -Map=lpc4148_freertos.map
/home/hash/Downloads/Academic/RnD/GNUARM/install/lib/gcc/arm-elf/4.3.2/../../../../arm-elf/bin/ld: cannot find -lgcc
collect2: ld returned 1 exit status
make: *** [lpc4148_freertos.elf] Error 1

Could anyone tell me the right way to make this project compile. Which version of gcc, nelwlib and binutils should I use? Start a New Thread

gcc (specifically 'ld') can't find the libgcc.a library file. I usually have to tell gcc where to find everything:
I first define 4 macros in the Makefile to specifiy the path to various libraries based on where I installed the package:
LOCATION = c:/yagarto/
PREFIX = arm-none-eabi
ARCHIVE1 = ${LOCATION}/${PREFIX}/lib
ARCHIVE2 = ${LOCATION}/lib/gcc/${PREFIX}/4.5.2
and another macro to gather up all the libraries:
LIBRARIES = -L${ARCHIVE1} -lc -lg -lm -L$(ARCHIVE2) -lgcc
Note that the location ARCHIVE1 has the c.o, g.o and m.o libraries and ARCHIVE2 has libgcc.a - the one you are missing.
The link statement looks like this:
${TARGET}.elf : ${LDSCRIPT} crt.o ${OBJS}
${LD} ${LDFLAGS} -o ${TARGET}.elf crt.o ${OBJS} ${LIBRARIES}
You may not need to take this approach. You may find a simple way to modify the Makefile from FreeRTOS to lead 'ld' to libgcc.a. I haven't played with FreeRTOS lately but, when I did, it built just fine.
Also, look at http://www.jcwren.com/arm/ http://www.jcwren.com/arm/, JC has demo code for every possible peripheral in the LPC2148 all wrapped around FreeRTOS. This is a fantastic resource!
Richard Start a New Thread

I messed up the reply above. ARCHIVE1 has the libc.a, libg.a and libm.a libraries and ARCHIVE2 has libgcc.a - the one you are missing. Start a New Thread

I need code protection for a product, so I read up about code protection
on the LPC812 chips (all LPC 8xxx and LPC1xxx seem to be identical in
this respect). The mechanism is to put a special magic value at address
0x02FC. This is done by having using the linker with a custom linker
script put a const variable with the desired magical value at that
adress, and the rest of the code comes after that. This leads me to two
questions:

1- The normal linker scripts load all code immediately after the
vectors. Hence there is a non-zero chance that one of the magic values
by accident ends up at the magic address, which could brick the chip!

2- A loader script that reserves the magic address (either for a
code-read-protecting value, or to prevent any magic value being
indavertantly put at that adress) must waste almost 3/4 of a kilobyte
FLASH. That might seem small peanuts, but an LPC810 has only 4Kb FLASH,
so this is almost 20%!

Am I missing something or was the designer of this scheme smoking mushrooms?

Wouter van Ooijn


Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/lpc2000/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/lpc2000/join
(Yahoo! ID required)

<*> To change settings via email:
l...
l...

<*> To unsubscribe from this group, send an email to:
l...

<*> Your use of Yahoo Groups is subject to:
http://info.yahoo.com/legal/us/yahoo/utos/terms/ Start a New Thread

No mushrooms. Most chip vendors have similar features.
What I've seen usually done is you reserve
this address in your linker configuration (depends on your toolchain of
course) so no code is put there. The address will be erased when programmed
but nothing will be put there so it will contain 0xFF, which is probably
not the magic value for locking it.
Depending on what you use to program it, it may be programmed with filler
data, which should be 0xFF.
If you want something else, you would use pragma och linker configuration
script etc to place some constant data there that you decide. This is what
you do if you want to lock it as well.

The flash will usually only be lock after you reset it after programming,
so you have the change to program the whole flash first, then it's locked
forever or locked where you can only remove the lock by a mass erase. Check
your trm for what you device supports.

If you want to lock it after programming everything else, you must read out
the flash block, swap the magic byte to the magic value, erase the block,
and then program it back.
No flash space is lost.

If your current linker script places data at the option byte address, you
should probably re-write it.

/Oscar Molin
2014-02-23 21:33 GMT+01:00 Wouter van Ooijen :

> I need code protection for a product, so I read up about code protection
> on the LPC812 chips (all LPC 8xxx and LPC1xxx seem to be identical in
> this respect). The mechanism is to put a special magic value at address
> 0x02FC. This is done by having using the linker with a custom linker
> script put a const variable with the desired magical value at that
> adress, and the rest of the code comes after that. This leads me to two
> questions:
>
> 1- The normal linker scripts load all code immediately after the
> vectors. Hence there is a non-zero chance that one of the magic values
> by accident ends up at the magic address, which could brick the chip!
>
> 2- A loader script that reserves the magic address (either for a
> code-read-protecting value, or to prevent any magic value being
> indavertantly put at that adress) must waste almost 3/4 of a kilobyte
> FLASH. That might seem small peanuts, but an LPC810 has only 4Kb FLASH,
> so this is almost 20%!
>
> Am I missing something or was the designer of this scheme smoking
> mushrooms?
>
> Wouter van Ooijn
>
> Start a New Thread

> What I've seen usually done is you reserve this address in your
linker configuration (depends on your toolchain of course) so no code is
put there. The address will be erased when programmed but nothing will
be put there so it will contain 0xFF, which is probably not the magic
value for locking it.

I haqve no problem with the mechanism, but why is this address
'half-way' the FLASH (of a small chip)??

And why does the mbed default linkerscript NOT reseve this location??

> No flash space is lost.

As far as I can see all FLASH locations before the magic address are
lost (at least, with a safe linkerscript).

Wouter


Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/lpc2000/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/lpc2000/join
(Yahoo! ID required)

<*> To change settings via email:
l...
l...

<*> To unsubscribe from this group, send an email to:
l...

<*> Your use of Yahoo Groups is subject to:
http://info.yahoo.com/legal/us/yahoo/utos/terms/ Start a New Thread

I agree with Wouter because I don't know how to create an 'island' in the middle of the .text section. I know very well how to create the linker script to declare the address as off limits but it's not clear to me that 'ld' will flow the .text section around it.
If I had to do it, I would declare a section ahead of the address (after .vectors) and force certain small chunks of code to be loaded in that segment. I tend to have a few of the string routines from K&R that might fit or perhaps some interrupt handlers. It would be an ugly arrangement to maintain. I wonder if 'ld' will warn that my section ahead of the CRP address overflowed during linking?
I have never tried to write the linker script for this operation.
Here is NXPs app note:
http://www.nxp.com/documents/application_note/AN10968.pdf http://www.nxp.com/documents/application_note/AN10968.pdf
It doesn't solve the problem either.
Richard Start a New Thread

> Here is NXPs app note:
>
> http://www.nxp.com/documents/application_note/AN10968.pdf
>
> It doesn't solve the problem either.

That's the document I read to make sure that I understood the concept.
It shows the likerscript to be used for enabling protection, but doesn't
even mention the waste of FLASH, let alone the possibility that a const
int x = 0x12345678; (or worse: 0x43218765, which would brick the chip)
might end up at the magic address!

Wouter Start a New Thread

Wouter,

Actually, there is no waste of flash per se but it takes some tweaking
around to take profit of it.

First, the CRP feature is activated with specific values - undefined values
mean no code protection. The codes are verified by a bootstrap after reset.

As Richard mentioned, if you want to use the space before the CRP code, you
can assign functions or constants to the isr_vectors section using
"__attribute__ ((section(".isr_vectors")))" or, if you look for a cleaner
solution, create a new section ".post_vectors". If you happen to have an
overflow, the linker will fail and report the section overflow so you do
have a safety net. The idea would be to place code or constants that are
likely not to change over time (or, at least, change the value of the
constants but not their size nor quantities) as this will solve the issue
once and for all.

The way to place the CRP code is described in section 6 of the doc you
referred to. I can confirm that it works.

Hope it helps
Olivier

Olivier Gautherot
o...@gautherot.net
Cel:+56 98 730 9361
www.gautherot.net
http://www.linkedin.com/in/ogautherot
On Mon, Feb 24, 2014 at 12:20 PM, Wouter van Ooijen wrote:

>
> Here is NXPs app note:
>
> http://www.nxp.com/documents/application_note/AN10968.pdf
>
> It doesn't solve the problem either.
> That's the document I read to make sure that I understood the concept. It
> shows the likerscript to be used for enabling protection, but doesn't even
> mention the waste of FLASH, let alone the possibility that a const int x > 0x12345678; (or worse: 0x43218765, which would brick the chip) might end up
> at the magic address!
>
> Wouter
>
>
> Start a New Thread

Hello,

I have custom linker script and custom crt0.S. Everything from crt0.S
goes before code read protection word.
For cortex-m3 crt0.S I have:
vector table (first part)
vector table checksum
vector table (second part)
Reset Handler
abort function
do_nothing_and_return function
Default_Exception_Handler
Default_IRQ_Handler
HardFault_Handler
32 bytes for serial number
code_read_protection_word

With this setup I have few unused bytes but I don't consider it a issue.

Best regards,

Mario
On 24.2.2014 16:44, Olivier Gautherot wrote:
> Wouter,
>
> Actually, there is no waste of flash per se but it takes some tweaking
> around to take profit of it.
>
> First, the CRP feature is activated with specific values - undefined
> values mean no code protection. The codes are verified by a bootstrap
> after reset.
>
> As Richard mentioned, if you want to use the space before the CRP
> code, you can assign functions or constants to the isr_vectors section
> using "__attribute__ ((section(".isr_vectors")))" or, if you look for
> a cleaner solution, create a new section ".post_vectors". If you
> happen to have an overflow, the linker will fail and report the
> section overflow so you do have a safety net. The idea would be to
> place code or constants that are likely not to change over time (or,
> at least, change the value of the constants but not their size nor
> quantities) as this will solve the issue once and for all.
>
> The way to place the CRP code is described in section 6 of the doc you
> referred to. I can confirm that it works.
>
> Hope it helps
> Olivier
>
> Olivier Gautherot
> o...@gautherot.net
> Cel:+56 98 730 9361
> www.gautherot.net
> http://www.linkedin.com/in/ogautherot
> On Mon, Feb 24, 2014 at 12:20 PM, Wouter van Ooijen > > wrote:
>> Here is NXPs app note:
>>
>> http://www.nxp.com/documents/application_note/AN10968.pdf
>>
>> It doesn't solve the problem either.
>>
>> That's the document I read to make sure that I understood the
> concept. It shows the likerscript to be used for enabling
> protection, but doesn't even mention the waste of FLASH, let alone
> the possibility that a const int x = 0x12345678; (or worse:
> 0x43218765, which would brick the chip) might end up at the magic
> address!
>
> Wouter
> Start a New Thread