Hi All,
I currently have a problem where I can't get my software to run
standalone on the LPC-E2294 dev board from Olimex. Using the CrossWorks
compiler and FreeRTOS, I have a simple application that creates a task
to flash an LED every second. Everything works fine when I debug it
using the CrossConnect JTAG interface. But the problem I'm having is,
if I now download the hex file and reset the board the code will not
run. I think it has something to do with FreeRTOS because I can get
applications to run standalone on the dev board that don't use it.
Any advice would be helpful.
Thanks a lot.
Problem running FreeRTOS standalone on LPC-E2294
Started by ●October 27, 2006
Reply by ●October 27, 20062006-10-27
Defined STARTUP_FROM_RESET?
> -----Original Message-----
> From: l...
> [mailto:l...] On Behalf Of plovell2
> Sent: 27 October 2006 12:52
> To: l...
> Subject: [lpc2000] Problem running FreeRTOS standalone on LPC-E2294
>
> Hi All,
>
> I currently have a problem where I can't get my software to
> run standalone on the LPC-E2294 dev board from Olimex. Using
> the CrossWorks compiler and FreeRTOS, I have a simple
> application that creates a task to flash an LED every second.
> Everything works fine when I debug it using the CrossConnect
> JTAG interface. But the problem I'm having is, if I now
> download the hex file and reset the board the code will not
> run. I think it has something to do with FreeRTOS because I
> can get applications to run standalone on the dev board that
> don't use it.
> Any advice would be helpful.
>
> Thanks a lot.
>
>
> -----Original Message-----
> From: l...
> [mailto:l...] On Behalf Of plovell2
> Sent: 27 October 2006 12:52
> To: l...
> Subject: [lpc2000] Problem running FreeRTOS standalone on LPC-E2294
>
> Hi All,
>
> I currently have a problem where I can't get my software to
> run standalone on the LPC-E2294 dev board from Olimex. Using
> the CrossWorks compiler and FreeRTOS, I have a simple
> application that creates a task to flash an LED every second.
> Everything works fine when I debug it using the CrossConnect
> JTAG interface. But the problem I'm having is, if I now
> download the hex file and reset the board the code will not
> run. I think it has something to do with FreeRTOS because I
> can get applications to run standalone on the dev board that
> don't use it.
> Any advice would be helpful.
>
> Thanks a lot.
>
>
Reply by ●October 27, 20062006-10-27
>I currently have a problem where I can't get my
software to run
>standalone on the LPC-E2294 dev board from Olimex. Using the CrossWorks
>compiler and FreeRTOS, I have a simple application that creates a task
>to flash an LED every second. Everything works fine when I debug it
>using the CrossConnect JTAG interface. But the problem I'm having is,
>if I now download the hex file and reset the board the code will not
>run. I think it has something to do with FreeRTOS because I can get
>applications to run standalone on the dev board that don't use it.
>Any advice would be helpful.
Check that the preprocessor definitions are the same for your debug and
release builds. I suspect that you have either SUPERVISOR_START or
VECTORED_IRQ_INTERRUPTS (or both) defined in your debug configuration but
not your release configuration.
Regards,
Richard.
+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
>standalone on the LPC-E2294 dev board from Olimex. Using the CrossWorks
>compiler and FreeRTOS, I have a simple application that creates a task
>to flash an LED every second. Everything works fine when I debug it
>using the CrossConnect JTAG interface. But the problem I'm having is,
>if I now download the hex file and reset the board the code will not
>run. I think it has something to do with FreeRTOS because I can get
>applications to run standalone on the dev board that don't use it.
>Any advice would be helpful.
Check that the preprocessor definitions are the same for your debug and
release builds. I suspect that you have either SUPERVISOR_START or
VECTORED_IRQ_INTERRUPTS (or both) defined in your debug configuration but
not your release configuration.
Regards,
Richard.
+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
Reply by ●October 30, 20062006-10-30
Thanks for your responses, I currently already have the following
preprocessor definitions in my debug build, VECTORED_IRQ_INTERRUPTS,
SUPERVISOR_START, STARTUP_FROM_RESET and GCC_ARM7.
Using the Crossworks facility to attach the debugger to the target
whilst it is running standalone, I can see that once I make a call the
function vTaskStartScheduler() and it goes through the various
initialisation tasks, one of the last calls it makes is to the
vPortISRStartFirstTask() within PortISR.c, which then does a call to
portRESTORE_CONTEXT(). It's at this point that the code seems to reset
itself and jumps to the main entry point _start in the file crt0.s.
Any advice?
Thanks Plovell2.
--- In l..., "FreeRTOS Info" wrote:
>
> >I currently have a problem where I can't get my software to run
> >standalone on the LPC-E2294 dev board from Olimex. Using the
CrossWorks
> >compiler and FreeRTOS, I have a simple application that creates a
task
> >to flash an LED every second. Everything works fine when I debug it
> >using the CrossConnect JTAG interface. But the problem I'm having is,
> >if I now download the hex file and reset the board the code will not
> >run. I think it has something to do with FreeRTOS because I can get
> >applications to run standalone on the dev board that don't use it.
> >Any advice would be helpful.
>
> Check that the preprocessor definitions are the same for your debug
and
> release builds. I suspect that you have either SUPERVISOR_START or
> VECTORED_IRQ_INTERRUPTS (or both) defined in your debug configuration
but
> not your release configuration.
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> + http://www.SafeRTOS.com
> for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
> Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
>
preprocessor definitions in my debug build, VECTORED_IRQ_INTERRUPTS,
SUPERVISOR_START, STARTUP_FROM_RESET and GCC_ARM7.
Using the Crossworks facility to attach the debugger to the target
whilst it is running standalone, I can see that once I make a call the
function vTaskStartScheduler() and it goes through the various
initialisation tasks, one of the last calls it makes is to the
vPortISRStartFirstTask() within PortISR.c, which then does a call to
portRESTORE_CONTEXT(). It's at this point that the code seems to reset
itself and jumps to the main entry point _start in the file crt0.s.
Any advice?
Thanks Plovell2.
--- In l..., "FreeRTOS Info" wrote:
>
> >I currently have a problem where I can't get my software to run
> >standalone on the LPC-E2294 dev board from Olimex. Using the
CrossWorks
> >compiler and FreeRTOS, I have a simple application that creates a
task
> >to flash an LED every second. Everything works fine when I debug it
> >using the CrossConnect JTAG interface. But the problem I'm having is,
> >if I now download the hex file and reset the board the code will not
> >run. I think it has something to do with FreeRTOS because I can get
> >applications to run standalone on the dev board that don't use it.
> >Any advice would be helpful.
>
> Check that the preprocessor definitions are the same for your debug
and
> release builds. I suspect that you have either SUPERVISOR_START or
> VECTORED_IRQ_INTERRUPTS (or both) defined in your debug configuration
but
> not your release configuration.
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> + http://www.SafeRTOS.com
> for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
> Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
>
Reply by ●October 30, 20062006-10-30
>Using the Crossworks facility to attach the debugger
to the target
>whilst it is running standalone, I can see that once I make a call the
>function vTaskStartScheduler() and it goes through the various
>initialisation tasks, one of the last calls it makes is to the
>vPortISRStartFirstTask() within PortISR.c, which then does a call to
>portRESTORE_CONTEXT(). It's at this point that the code seems to reset
>itself and jumps to the main entry point _start in the file crt0.s.
Are you compiling for ARM or THUMB? If THUMB then you must also have
THUMB_INTERWORK defined, and portISR.c configured to be compiled into ARM.
I suspect this might be the problem.
If this makes no difference then double check in the debugger that you are
indeed in Supervisor mode when portRESTORE_CONTEXT is called.
Finally, if you can confirm you are in Supervisor mode, zip up your entire
project and send it to me - using the email address available on the contact
page of the FreeRTOS.org site.
Regards,
Richard.
+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
--- In l..., "FreeRTOS Info" wrote:
>
> >I currently have a problem where I can't get my software to run
> >standalone on the LPC-E2294 dev board from Olimex. Using the
CrossWorks
> >compiler and FreeRTOS, I have a simple application that creates a
task
> >to flash an LED every second. Everything works fine when I debug it
> >using the CrossConnect JTAG interface. But the problem I'm having is,
> >if I now download the hex file and reset the board the code will not
> >run. I think it has something to do with FreeRTOS because I can get
> >applications to run standalone on the dev board that don't use it.
> >Any advice would be helpful.
>
> Check that the preprocessor definitions are the same for your debug
and
> release builds. I suspect that you have either SUPERVISOR_START or
> VECTORED_IRQ_INTERRUPTS (or both) defined in your debug configuration
but
> not your release configuration.
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> + http://www.SafeRTOS.com
> for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
> Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
>
>whilst it is running standalone, I can see that once I make a call the
>function vTaskStartScheduler() and it goes through the various
>initialisation tasks, one of the last calls it makes is to the
>vPortISRStartFirstTask() within PortISR.c, which then does a call to
>portRESTORE_CONTEXT(). It's at this point that the code seems to reset
>itself and jumps to the main entry point _start in the file crt0.s.
Are you compiling for ARM or THUMB? If THUMB then you must also have
THUMB_INTERWORK defined, and portISR.c configured to be compiled into ARM.
I suspect this might be the problem.
If this makes no difference then double check in the debugger that you are
indeed in Supervisor mode when portRESTORE_CONTEXT is called.
Finally, if you can confirm you are in Supervisor mode, zip up your entire
project and send it to me - using the email address available on the contact
page of the FreeRTOS.org site.
Regards,
Richard.
+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
--- In l..., "FreeRTOS Info" wrote:
>
> >I currently have a problem where I can't get my software to run
> >standalone on the LPC-E2294 dev board from Olimex. Using the
CrossWorks
> >compiler and FreeRTOS, I have a simple application that creates a
task
> >to flash an LED every second. Everything works fine when I debug it
> >using the CrossConnect JTAG interface. But the problem I'm having is,
> >if I now download the hex file and reset the board the code will not
> >run. I think it has something to do with FreeRTOS because I can get
> >applications to run standalone on the dev board that don't use it.
> >Any advice would be helpful.
>
> Check that the preprocessor definitions are the same for your debug
and
> release builds. I suspect that you have either SUPERVISOR_START or
> VECTORED_IRQ_INTERRUPTS (or both) defined in your debug configuration
but
> not your release configuration.
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> + http://www.SafeRTOS.com
> for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
> Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
>