Reply by Olivier Gautherot●February 24, 20142014-02-24
Richard, LOL!!!
@Wouter, seriously, the CRP scheme is not for a single chip so I guess they
tried to make it a generic solution. My guess is that it should support
different cores so it would not be advisable to reuse one of the exceptions
vectors - this leaves out vectors 0 to 15. In addition, the NVIC can
support up to 240 interrupts, what would give us a maximum table size of
256 (or address 0x400 for the CRP). By using 0x2FC as address for the CRP,
they are deliberately limiting the number of interrupts to 174, which
sounds reasonable for a general purpose chip (most chips should be in the
order of 30 to 50). I suppose Marketing decided that address 0x1FC would
leave 110 available interrupts and would be a bit tight on the edges.
I'm not sure I have any more intelligent answer to give you :-)
Cheers
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 8:03 PM, wrote:
> It seems to me that there is a perfectly reasonable
explanation.
> A bunch of engineers were sitting around a bar table eating pizza and
> drinking beer when they came up with the idea that by placing the constant
> up away from the vectors, they could separate system designers into two
> classes: Those that could figure it out, would probably complain about it,
> but wouldn't completely mess up the chip. Or, those who couldn't
figure it
> out and shouldn't be playing with CRP anyway because they'll brick
the chip
> right out of the gate.
> I never overlook the pizza and beer explanation for design issues!
> Richard
>
>
>
Reply by rsto...@pacbell.net●February 24, 20142014-02-24
It seems to me that there is a perfectly reasonable explanation.
A bunch of engineers were sitting around a bar table eating pizza and drinking
beer when they came up with the idea that by placing the constant up away from
the vectors, they could separate system designers into two classes: Those that
could figure it out, would probably complain about it, but wouldn't
completely mess up the chip. Or, those who couldn't figure it out and
shouldn't be playing with CRP anyway because they'll brick the chip
right out of the gate.
I never overlook the pizza and beer explanation for design issues!
Richard
Reply by Wouter van Ooijen●February 24, 20142014-02-24
Olivier Gautherot schreef op 24-Feb-14 10:06 PM: > Wouter,
>
> the location you suggest is occupied by an existing peripheral
> interrupt vector. They could have used an undefined exception
> (specific to the core, before the interrupt vectors), with the risk
> that another core would use it (risk is extremely low and it would be
> another chip alltogether... but still).
>
My idea would be to use the first location that is not claimed for any
special purpose.
...
No, don't tell me 0x02FC is the first such location?!?!
Wouter
Reply by Olivier Gautherot●February 24, 20142014-02-24
Wouter,
the location you suggest is occupied by an existing peripheral interrupt
vector. They could have used an undefined exception (specific to the core,
before the interrupt vectors), with the risk that another core would use it
(risk is extremely low and it would be another chip alltogether... but
still).
But the question is valid.
Cheers
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 5:59 PM, Wouter van Ooijen wrote:
> Mario Ivancic schreef op 24-Feb-14 8:35 PM:
>
> 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.
> I understand that by going to the trouble of project-specific tweaking
> you can find a use for that fragment of FLASH. What I don't understand
is
> why they didn't select a word immediately after the (more or less
> mandatory) vector table to save us from such trouble!
>
> Wouter
>
>
>
Reply by Wouter van Ooijen●February 24, 20142014-02-24
Mario Ivancic schreef op 24-Feb-14 8:35 PM: >
> 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.
> I understand that by going to the trouble of project-specific tweaking
you can find a use for that fragment of FLASH. What I don't understand
is why they didn't select a word immediately after the (more or less
mandatory) vector table to save us from such trouble!
Wouter
Reply by Mario Ivancic●February 24, 20142014-02-24
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
>
Reply by Olivier Gautherot●February 24, 20142014-02-24
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
>
>
>
Reply by Wouter van Ooijen●February 24, 20142014-02-24
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
Reply by rsto...@pacbell.net●February 24, 20142014-02-24
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.pdfhttp://www.nxp.com/documents/application_note/AN10968.pdf
It doesn't solve the problem either.
Richard
Reply by Wouter van Ooijen●February 24, 20142014-02-24
> 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).
