Hi all,
Please provide a startup file(ld script)for lpc176x for reference.I am
started to uselpc176x series.This startup file will initialize exception vector
table.First entry will be the top of the stack.
Thanks,
Need startup file for LPC176x with GNUARM,FreeRTOS
Started by ●March 12, 2010
Reply by ●March 12, 20102010-03-12
Hi,
>
> Hi all,
> Please provide a startup file(ld script)for lpc176x for reference.I am started to uselpc176x series.This startup file will initialize exception vector table.First entry will be the top of the stack.
Try:
http://code.google.com/p/32bitmicro/wiki/LPC17xxSampleSoftware
startup is in:
http://code.google.com/p/32bitmicro/source/browse/trunk/src/nxp/lpc17xx/LPC17xxSampleSoftware/common/src/startup_LPC17xx.s
>
> Thanks,
>
Cheers,
Pawel
>
> Hi all,
> Please provide a startup file(ld script)for lpc176x for reference.I am started to uselpc176x series.This startup file will initialize exception vector table.First entry will be the top of the stack.
Try:
http://code.google.com/p/32bitmicro/wiki/LPC17xxSampleSoftware
startup is in:
http://code.google.com/p/32bitmicro/source/browse/trunk/src/nxp/lpc17xx/LPC17xxSampleSoftware/common/src/startup_LPC17xx.s
>
> Thanks,
>
Cheers,
Pawel
Reply by ●March 12, 20102010-03-12
On 12/03/2010 18:11, Pawel wrote:
>
>
> Hi,
>
>>
>> Hi all,
>> Please provide a startup file(ld script)for lpc176x for reference.I am started to uselpc176x series.This startup file will initialize exception vector table.First entry will be the top of the stack.
>
> Try:
>
> http://code.google.com/p/32bitmicro/wiki/LPC17xxSampleSoftware
>
> startup is in:
>
> http://code.google.com/p/32bitmicro/source/browse/trunk/src/nxp/lpc17xx/LPC17xxSampleSoftware/common/src/startup_LPC17xx.s
>
>
Why not start by looking at the GCC LPC1768 demos that already exist in
the FreeRTOS download? You will even then see how to populate the
vector table.
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.
+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.
>
>
> Hi,
>
>>
>> Hi all,
>> Please provide a startup file(ld script)for lpc176x for reference.I am started to uselpc176x series.This startup file will initialize exception vector table.First entry will be the top of the stack.
>
> Try:
>
> http://code.google.com/p/32bitmicro/wiki/LPC17xxSampleSoftware
>
> startup is in:
>
> http://code.google.com/p/32bitmicro/source/browse/trunk/src/nxp/lpc17xx/LPC17xxSampleSoftware/common/src/startup_LPC17xx.s
>
>
Why not start by looking at the GCC LPC1768 demos that already exist in
the FreeRTOS download? You will even then see how to populate the
vector table.
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.
+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.
Reply by ●March 12, 20102010-03-12
--- In l..., prabuisin@... wrote:
>
> Hi all,
> Please provide a startup file(ld script)for lpc176x for reference.I am started to uselpc176x series.This startup file will initialize exception vector table.First entry will be the top of the stack.
>
> Thanks,
>
Interestingly, together with Cortex M3 one of the advertising gags was that assembler (start-up code) was something of the past and not needed for the new chips. In fact it uses the same technique as Motorola 68000s have been using for years, but it is nevertheless strange that none of the available packages (or not the ones that I have seen) make any particular effort to avoid assembler start-up code either.
With GNU (example below) - and others - it is however quite easy:
const VECTOR_TABLE __attribute__((section(".vectors"))) reset_vect= {
{ (void *)(RAM_START_ADDRESS + SIZE_OF_RAM), // stack pointer to top of RAM
(void (*)(void))START_CODE, // start address
},
..followed by a list of interrupt routines which is partly processor specific
..
};
whereby the definition of the struct for the LPC17XX looks something like:
typedef struct stRESET_VECTOR
{
void *ptrResetSP; // initial stack pointer
void (*ptrResetPC)(void); // initial program counter
} RESET_VECTOR;
typedef struct stVECTOR_TABLE
{
RESET_VECTOR reset_vect;
void (*ptrNMI)(void);
void (*ptrHardFault)(void);
void (*ptrMemManagement)(void);
void (*ptrBusFault)(void);
void (*ptrUsageFault)(void);
unsigned long ptrReserved1[4];
void (*ptrSVCall)(void);
void (*ptrDebugMonitor)(void);
unsigned long ptrReserved2;
void (*ptrPendSV)(void);
void (*ptrSysTick)(void);
void (*irq_Watchdog_Timer)(void); // 0
void (*irq_Timer0)(void); // 1
void (*irq_Timer1)(void); // 2
void (*irq_Timer2)(void); // 3
void (*irq_Timer3)(void); // 4
void (*irq_UART0)(void); // 5
void (*irq_UART1)(void); // 6
void (*irq_UART2)(void); // 7
void (*irq_UART3)(void); // 8
void (*irq_PWM1)(void); // 9
void (*irq_I2C0)(void); // 10
void (*irq_I2C1)(void); // 11
void (*irq_I2C2)(void); // 12
void (*irq_SPI)(void); // 13
void (*irq_SSP0)(void); // 14
void (*irq_SSP1)(void); // 15
void (*irq_PLL0)(void); // 16 - main PLL
void (*irq_RTC)(void); // 17
void (*irq_EINT0)(void); // 18
void (*irq_EINT1)(void); // 19
void (*irq_EINT2)(void); // 20
void (*irq_EINT3)(void); // 21
void (*irq_ADC)(void); // 22
void (*irq_BOD)(void); // 23
void (*irq_USB)(void); // 24
void (*irq_CAN)(void); // 25
void (*irq_GPDMA)(void); // 26
void (*irq_I2S)(void); // 27
void (*irq_Ethernet_Controller)(void); // 28
void (*irq_RITINT)(void); // 29
void (*irq_MotorControlPWM)(void); // 30
void (*irq_QuadEncoder)(void); // 31
void (*irq_PLL1)(void); // 32 - USB PLL
void (*irq_USB_Activity)(void); // 33
void (*irq_CAN_Activity)(void); // 34
} VECTOR_TABLE;
Regards
Mark
http://www.uTasker.com
>
> Hi all,
> Please provide a startup file(ld script)for lpc176x for reference.I am started to uselpc176x series.This startup file will initialize exception vector table.First entry will be the top of the stack.
>
> Thanks,
>
Interestingly, together with Cortex M3 one of the advertising gags was that assembler (start-up code) was something of the past and not needed for the new chips. In fact it uses the same technique as Motorola 68000s have been using for years, but it is nevertheless strange that none of the available packages (or not the ones that I have seen) make any particular effort to avoid assembler start-up code either.
With GNU (example below) - and others - it is however quite easy:
const VECTOR_TABLE __attribute__((section(".vectors"))) reset_vect= {
{ (void *)(RAM_START_ADDRESS + SIZE_OF_RAM), // stack pointer to top of RAM
(void (*)(void))START_CODE, // start address
},
..followed by a list of interrupt routines which is partly processor specific
..
};
whereby the definition of the struct for the LPC17XX looks something like:
typedef struct stRESET_VECTOR
{
void *ptrResetSP; // initial stack pointer
void (*ptrResetPC)(void); // initial program counter
} RESET_VECTOR;
typedef struct stVECTOR_TABLE
{
RESET_VECTOR reset_vect;
void (*ptrNMI)(void);
void (*ptrHardFault)(void);
void (*ptrMemManagement)(void);
void (*ptrBusFault)(void);
void (*ptrUsageFault)(void);
unsigned long ptrReserved1[4];
void (*ptrSVCall)(void);
void (*ptrDebugMonitor)(void);
unsigned long ptrReserved2;
void (*ptrPendSV)(void);
void (*ptrSysTick)(void);
void (*irq_Watchdog_Timer)(void); // 0
void (*irq_Timer0)(void); // 1
void (*irq_Timer1)(void); // 2
void (*irq_Timer2)(void); // 3
void (*irq_Timer3)(void); // 4
void (*irq_UART0)(void); // 5
void (*irq_UART1)(void); // 6
void (*irq_UART2)(void); // 7
void (*irq_UART3)(void); // 8
void (*irq_PWM1)(void); // 9
void (*irq_I2C0)(void); // 10
void (*irq_I2C1)(void); // 11
void (*irq_I2C2)(void); // 12
void (*irq_SPI)(void); // 13
void (*irq_SSP0)(void); // 14
void (*irq_SSP1)(void); // 15
void (*irq_PLL0)(void); // 16 - main PLL
void (*irq_RTC)(void); // 17
void (*irq_EINT0)(void); // 18
void (*irq_EINT1)(void); // 19
void (*irq_EINT2)(void); // 20
void (*irq_EINT3)(void); // 21
void (*irq_ADC)(void); // 22
void (*irq_BOD)(void); // 23
void (*irq_USB)(void); // 24
void (*irq_CAN)(void); // 25
void (*irq_GPDMA)(void); // 26
void (*irq_I2S)(void); // 27
void (*irq_Ethernet_Controller)(void); // 28
void (*irq_RITINT)(void); // 29
void (*irq_MotorControlPWM)(void); // 30
void (*irq_QuadEncoder)(void); // 31
void (*irq_PLL1)(void); // 32 - USB PLL
void (*irq_USB_Activity)(void); // 33
void (*irq_CAN_Activity)(void); // 34
} VECTOR_TABLE;
Regards
Mark
http://www.uTasker.com
Reply by ●March 12, 20102010-03-12
On 12/03/2010 19:31, mjbcswitzerland wrote:
> --- In l..., prabuisin@... wrote:
>>
>> Hi all,
>> Please provide a startup file(ld script)for lpc176x for reference.I am started to uselpc176x series.This startup file will initialize exception vector table.First entry will be the top of the stack.
>>
>> Thanks,
>>
>
> Interestingly, together with Cortex M3 one of the advertising gags was that assembler (start-up code) was something of the past and not needed for the new chips. In fact it uses the same technique as Motorola 68000s have been using for years, but it is nevertheless strange that none of the available packages (or not the ones that I have seen) make any particular effort to avoid assembler start-up code either.
>
> With GNU (example below) - and others - it is however quite easy:
>
> const VECTOR_TABLE __attribute__((section(".vectors"))) reset_vect= {
> { (void *)(RAM_START_ADDRESS + SIZE_OF_RAM), // stack pointer to top of RAM
> (void (*)(void))START_CODE, // start address
> },
> ..followed by a list of interrupt routines which is partly processor specific
> ..
> };
>
Problems can arise where you use a loop in C to zero out RAM. It can
work well in pure C code when the optimiser is on as the loop counter
will be in a register, but crash horribly when the optimiser is off
because it tries to use a stack (that has not been set up) and tries to
zero out its own loop counter.
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.
+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.
> --- In l..., prabuisin@... wrote:
>>
>> Hi all,
>> Please provide a startup file(ld script)for lpc176x for reference.I am started to uselpc176x series.This startup file will initialize exception vector table.First entry will be the top of the stack.
>>
>> Thanks,
>>
>
> Interestingly, together with Cortex M3 one of the advertising gags was that assembler (start-up code) was something of the past and not needed for the new chips. In fact it uses the same technique as Motorola 68000s have been using for years, but it is nevertheless strange that none of the available packages (or not the ones that I have seen) make any particular effort to avoid assembler start-up code either.
>
> With GNU (example below) - and others - it is however quite easy:
>
> const VECTOR_TABLE __attribute__((section(".vectors"))) reset_vect= {
> { (void *)(RAM_START_ADDRESS + SIZE_OF_RAM), // stack pointer to top of RAM
> (void (*)(void))START_CODE, // start address
> },
> ..followed by a list of interrupt routines which is partly processor specific
> ..
> };
>
Problems can arise where you use a loop in C to zero out RAM. It can
work well in pure C code when the optimiser is on as the loop counter
will be in a register, but crash horribly when the optimiser is off
because it tries to use a stack (that has not been set up) and tries to
zero out its own loop counter.
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.
+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.
Reply by ●March 12, 20102010-03-12
>
but crash horribly when the optimiser is off
> because it tries to use a stack (that has not been set up) and tries to
> zero out its own loop counter.
>
> Regards,
> Richard.
Hi Richard
The Cortex M3 loads its stack pointer from the address 0x00000000 as first operation so, as long as the initial SP has been set at this location, there is never a risk of such a thing happening.
(Note: (void *)(RAM_START_ADDRESS + SIZE_OF_RAM), // stack pointer to top of RAM - it can of course been modified later but for the first steps the top of SRAM is as safe as could be.)
The only exception that I know of is when working with Rowley Crossworks and debugging from SRAM when the FLASH is empty. In this case the SP gets the value 0xffffffff (since this value is at 0x00000000) and so crashes as soon as the stack is used (unless the start up code additionally sets the SP actively or course). The IAR and Keil debuggers will additionally copy the value from the first SRAM location into the SP so that the behavior is the same as when running from FLASH. Probably it would be possible to change the Crossworks reset script to achieve this but I just ensure that there is an old program in FLASH to achieve the same effect.
The Cortex M3 marketing people have been so industrious to promote this feature that I am determined to oblige...;-)
Regards
Mark
PS. While on the LPC17XX subject, you are probably one of the leading experts. Do you have any explanations for the following points:
1) According to the Cortex M3 model, internal SRAM resides between 0x20000000 and 0x3fffffff. The LPC17XX SRAM starts however at 0x10000000. I have not been able to get the NVIC to access this RAM - it always gives an excess violation when trying to vector - like it can't access this area. Putting the vectors in the Ethernet or USB SRAM areas works normally - supposedly because this area is in the Cortex M3's official SRAM area. Is there some way to allow the NVIC to access SRAM outside the 'official' Cortex SRAM area or is this something that was overlooked in the LPC17XX design?
2) The IAP uses 32 bytes of memory "at the top of RAM" when operating and the user should keep these free to avoid corruption.
However if I put a pattern in memory at the top of any of the RAM blocks and run IAR routines (writing and deleting FLASH for example) the pattern remains unchanged.
Any ideas which part of RAM the IAP routines are using (and potentially corrupting) because I haven't been able to find them...?
but crash horribly when the optimiser is off
> because it tries to use a stack (that has not been set up) and tries to
> zero out its own loop counter.
>
> Regards,
> Richard.
Hi Richard
The Cortex M3 loads its stack pointer from the address 0x00000000 as first operation so, as long as the initial SP has been set at this location, there is never a risk of such a thing happening.
(Note: (void *)(RAM_START_ADDRESS + SIZE_OF_RAM), // stack pointer to top of RAM - it can of course been modified later but for the first steps the top of SRAM is as safe as could be.)
The only exception that I know of is when working with Rowley Crossworks and debugging from SRAM when the FLASH is empty. In this case the SP gets the value 0xffffffff (since this value is at 0x00000000) and so crashes as soon as the stack is used (unless the start up code additionally sets the SP actively or course). The IAR and Keil debuggers will additionally copy the value from the first SRAM location into the SP so that the behavior is the same as when running from FLASH. Probably it would be possible to change the Crossworks reset script to achieve this but I just ensure that there is an old program in FLASH to achieve the same effect.
The Cortex M3 marketing people have been so industrious to promote this feature that I am determined to oblige...;-)
Regards
Mark
PS. While on the LPC17XX subject, you are probably one of the leading experts. Do you have any explanations for the following points:
1) According to the Cortex M3 model, internal SRAM resides between 0x20000000 and 0x3fffffff. The LPC17XX SRAM starts however at 0x10000000. I have not been able to get the NVIC to access this RAM - it always gives an excess violation when trying to vector - like it can't access this area. Putting the vectors in the Ethernet or USB SRAM areas works normally - supposedly because this area is in the Cortex M3's official SRAM area. Is there some way to allow the NVIC to access SRAM outside the 'official' Cortex SRAM area or is this something that was overlooked in the LPC17XX design?
2) The IAP uses 32 bytes of memory "at the top of RAM" when operating and the user should keep these free to avoid corruption.
However if I put a pattern in memory at the top of any of the RAM blocks and run IAR routines (writing and deleting FLASH for example) the pattern remains unchanged.
Any ideas which part of RAM the IAP routines are using (and potentially corrupting) because I haven't been able to find them...?
Reply by ●March 12, 20102010-03-12
--- In l..., "mjbcswitzerland" wrote:
>
> --- In l..., prabuisin@ wrote:
> >
> > Hi all,
> > Please provide a startup file(ld script)for lpc176x for reference.I am started to uselpc176x series.This startup file will initialize exception vector table.First entry will be the top of the stack.
> >
> > Thanks,
> > Interestingly, together with Cortex M3 one of the advertising gags was that assembler (start-up code) was something of the past and not needed for the new chips. In fact it uses the same technique as Motorola 68000s have been using for years, but it is nevertheless strange that none of the available packages (or not the ones that I have seen) make any particular effort to avoid assembler start-up code either.
Besides the vectors, there is still the requirement to initialize the C enviorment: initialize .data, clear .bss, run the constructors (if any) and so on. About the only difference I see is that there are a lot more vectors. Other than that, it's the same as the ARM7.
It would take some pretty clever C code to initialize the .data segment. I suppose it could be done but I'm glad it isn't! A wee bit of assembly language just isn't that big of a deal.
Richard
>
> --- In l..., prabuisin@ wrote:
> >
> > Hi all,
> > Please provide a startup file(ld script)for lpc176x for reference.I am started to uselpc176x series.This startup file will initialize exception vector table.First entry will be the top of the stack.
> >
> > Thanks,
> > Interestingly, together with Cortex M3 one of the advertising gags was that assembler (start-up code) was something of the past and not needed for the new chips. In fact it uses the same technique as Motorola 68000s have been using for years, but it is nevertheless strange that none of the available packages (or not the ones that I have seen) make any particular effort to avoid assembler start-up code either.
Besides the vectors, there is still the requirement to initialize the C enviorment: initialize .data, clear .bss, run the constructors (if any) and so on. About the only difference I see is that there are a lot more vectors. Other than that, it's the same as the ARM7.
It would take some pretty clever C code to initialize the .data segment. I suppose it could be done but I'm glad it isn't! A wee bit of assembly language just isn't that big of a deal.
Richard
Reply by ●March 12, 20102010-03-12
Hi,
> Besides the vectors, there is still the requirement to initialize the C
> enviorment: initialize .data, clear .bss, run the constructors (if any) and
> so on. About the only difference I see is that there are a lot more vectors.
> Other than that, it's the same as the ARM7.
>
> It would take some pretty clever C code to initialize the .data segment. I
> suppose it could be done but I'm glad it isn't! A wee bit of assembly
> language just isn't that big of a deal.
>
> Richard
>
This is the code I use, from the Stellaris samples, very simple:
//*****************************************************************************
//
// The following are constructs created by the linker, indicating where the
// the "data" and "bss" segments reside in memory. The initializers for the
// for the "data" segment resides immediately following the "text" segment.
//
//*****************************************************************************
extern unsigned long _etext;
extern unsigned long _data;
extern unsigned long _edata;
extern unsigned long _bss;
extern unsigned long _ebss;
//*****************************************************************************
//
// This is the code that gets called when the processor first starts
execution
// following a reset event. Only the absolutely necessary set is performed,
// after which the application supplied main() routine is called. Any fancy
// actions (such as making decisions based on the reset cause register, and
// resetting the bits in that register) are left solely in the hands of the
// application.
//
//*****************************************************************************
void
ResetISR(void)
{
unsigned long *pulSrc, *pulDest;
//
// Copy the data segment initializers from flash to SRAM.
//
pulSrc = &_etext;
for(pulDest = &_data; pulDest < &_edata; )
{
*pulDest++ = *pulSrc++;
}
//
// Zero fill the bss segment.
//
for(pulDest = &_bss; pulDest < &_ebss; )
{
*pulDest++ = 0;
}
//
// Call the application's entry point.
//
main();
}
Regards.
Sergio.
> Besides the vectors, there is still the requirement to initialize the C
> enviorment: initialize .data, clear .bss, run the constructors (if any) and
> so on. About the only difference I see is that there are a lot more vectors.
> Other than that, it's the same as the ARM7.
>
> It would take some pretty clever C code to initialize the .data segment. I
> suppose it could be done but I'm glad it isn't! A wee bit of assembly
> language just isn't that big of a deal.
>
> Richard
>
This is the code I use, from the Stellaris samples, very simple:
//*****************************************************************************
//
// The following are constructs created by the linker, indicating where the
// the "data" and "bss" segments reside in memory. The initializers for the
// for the "data" segment resides immediately following the "text" segment.
//
//*****************************************************************************
extern unsigned long _etext;
extern unsigned long _data;
extern unsigned long _edata;
extern unsigned long _bss;
extern unsigned long _ebss;
//*****************************************************************************
//
// This is the code that gets called when the processor first starts
execution
// following a reset event. Only the absolutely necessary set is performed,
// after which the application supplied main() routine is called. Any fancy
// actions (such as making decisions based on the reset cause register, and
// resetting the bits in that register) are left solely in the hands of the
// application.
//
//*****************************************************************************
void
ResetISR(void)
{
unsigned long *pulSrc, *pulDest;
//
// Copy the data segment initializers from flash to SRAM.
//
pulSrc = &_etext;
for(pulDest = &_data; pulDest < &_edata; )
{
*pulDest++ = *pulSrc++;
}
//
// Zero fill the bss segment.
//
for(pulDest = &_bss; pulDest < &_ebss; )
{
*pulDest++ = 0;
}
//
// Call the application's entry point.
//
main();
}
Regards.
Sergio.
Reply by ●March 12, 20102010-03-12
On 12/03/2010 20:21, mjbcswitzerland wrote:
> The Cortex M3 marketing people have been so industrious to promote
> this feature that I am determined to oblige...;-)
As far as I know - ARM themselves don't use this feature and instead
provide assembly startup code.
GCC projects normally use C, but looking at the startup file provided by
Code Red (which uses GCC, and was written by CM3 experts) I see the
following comments:
//
// Copy the data segment initializers from flash to SRAM.
//
followed by a C loop to perform the copy, then...
//
// Zero fill the bss segment. This is done with inline assembly
since this
// will clear the value of pulDest if it is not kept in a register.
//
followed by a small amount of inline assembly to do the zeroing. 9
lines total. In-lining assembly in that way is really easy with GCC,
but less easy with other tool chains.
--
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.
+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.
>
> Regards
>
> Mark
>
> PS. While on the LPC17XX subject, you are probably one of the leading
> experts. Do you have any explanations for the following points:
>
> 1) According to the Cortex M3 model, internal SRAM resides between
> 0x20000000 and 0x3fffffff. The LPC17XX SRAM starts however at
> 0x10000000. I have not been able to get the NVIC to access this RAM -
> it always gives an excess violation when trying to vector - like it
> can't access this area. Putting the vectors in the Ethernet or USB
> SRAM areas works normally - supposedly because this area is in the
> Cortex M3's official SRAM area. Is there some way to allow the NVIC
> to access SRAM outside the 'official' Cortex SRAM area or is this
> something that was overlooked in the LPC17XX design?
>
> 2) The IAP uses 32 bytes of memory "at the top of RAM" when operating
> and the user should keep these free to avoid corruption. However if I
> put a pattern in memory at the top of any of the RAM blocks and run
> IAR routines (writing and deleting FLASH for example) the pattern
> remains unchanged. Any ideas which part of RAM the IAP routines are
> using (and potentially corrupting) because I haven't been able to
> find them...?
>
>
>
>
>
>
> The Cortex M3 marketing people have been so industrious to promote
> this feature that I am determined to oblige...;-)
As far as I know - ARM themselves don't use this feature and instead
provide assembly startup code.
GCC projects normally use C, but looking at the startup file provided by
Code Red (which uses GCC, and was written by CM3 experts) I see the
following comments:
//
// Copy the data segment initializers from flash to SRAM.
//
followed by a C loop to perform the copy, then...
//
// Zero fill the bss segment. This is done with inline assembly
since this
// will clear the value of pulDest if it is not kept in a register.
//
followed by a small amount of inline assembly to do the zeroing. 9
lines total. In-lining assembly in that way is really easy with GCC,
but less easy with other tool chains.
--
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.
+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.
>
> Regards
>
> Mark
>
> PS. While on the LPC17XX subject, you are probably one of the leading
> experts. Do you have any explanations for the following points:
>
> 1) According to the Cortex M3 model, internal SRAM resides between
> 0x20000000 and 0x3fffffff. The LPC17XX SRAM starts however at
> 0x10000000. I have not been able to get the NVIC to access this RAM -
> it always gives an excess violation when trying to vector - like it
> can't access this area. Putting the vectors in the Ethernet or USB
> SRAM areas works normally - supposedly because this area is in the
> Cortex M3's official SRAM area. Is there some way to allow the NVIC
> to access SRAM outside the 'official' Cortex SRAM area or is this
> something that was overlooked in the LPC17XX design?
>
> 2) The IAP uses 32 bytes of memory "at the top of RAM" when operating
> and the user should keep these free to avoid corruption. However if I
> put a pattern in memory at the top of any of the RAM blocks and run
> IAR routines (writing and deleting FLASH for example) the pattern
> remains unchanged. Any ideas which part of RAM the IAP routines are
> using (and potentially corrupting) because I haven't been able to
> find them...?
>
>
>
>
>
>
Reply by ●March 12, 20102010-03-12
> This is the code I use, from the Stellaris samples,
very simple:
I think this is from a very old sample, the StellarisWare code now
replaces the second loop with inline assembler, just like the Code Red code.
Your code will work, provided optimisation is not zero, then it *might*
work probably depending on the linker script. I have seen projects that
have a separate optimisation setting for the startup files to all the
other files to ensure it is never set to zero (in fact some of the much
older FreeRTOS CM3 demos do this).
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.
+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.
