Hi Guys,
I have a strange problem. with the CTL(crossworks
tasking lib). Have created two tasks , and hooked the timer0 for the
task switching. every thing works fine if I program it using JTAG. but
when I start the application by switching the power off and on then
the application hangs when the ctl_taskrun
is called. boot loader is running and it starts the application.
Before application is started all the peripherals are reseted.This
problem is bugging me for a week.START_UP_FROM_RESET is defined.
I do not know how to debug it. I has some basic questions.
1) If you run your application form the JTAG (application starts form
boot block 1) , and there is a boot loader. does the boot loader runs
first then the application is started ?
2)found a strange behavior , the application runs(power ON/OFF cycle)
when I configure the RTC for a second alarm interrupt . In the
bootloader code the RTC is configured for the alarm interrupt. my
question is In bootlader the RTC is configured and then the startup
code is called where the software reset is performed, which clears all
the peripherals registers including the RTC registers and clock
configurations newly done, does the registers are not clearly reset ,
how do I check it?
I might sound bit confusing . but any help how to debug it would be
relay great.
crossworks Tasking library
Started by ●March 2, 2008
Reply by ●March 3, 20082008-03-03
> Hi Guys,
'mornin..
> I have a strange problem. with the CTL(crossworks
> tasking lib). Have created two tasks , and hooked the timer0 for the
> task switching. every thing works fine if I program it using JTAG. but
> when I start the application by switching the power off and on then
> the application hangs when the ctl_taskrun
> is called. boot loader is running and it starts the application.
> Before application is started all the peripherals are reseted.This
> problem is bugging me for a week.START_UP_FROM_RESET is defined.
> I do not know how to debug it.
Nor do I. Luckily, I do not see this problem on my 2129.
I has some basic questions.
>
> 1) If you run your application form the JTAG (application starts form
> boot block 1) , and there is a boot loader. does the boot loader runs
> first then the application is started ?
IMHO, the built-in boot loader must run first in order to run the
protocol with the host and blow the application into flash.
> 2)found a strange behavior , the application runs(power ON/OFF cycle)
> when I configure the RTC for a second alarm interrupt . In the
> bootloader code the RTC is configured for the alarm interrupt.
Why would the built-in boot loader configure the RTC? Do you have a
secondary boot loader - you load your app from an SD card or something??
my
> question is In bootlader the RTC is configured and then the startup
> code is called where the software reset is performed, which clears all
> the peripherals registers including the RTC registers and clock
> configurations newly done, does the registers are not clearly reset ,
> how do I check it?
Why does you boot loader set up the RTC? Surely, there is little
point in setting it before the main app runs?
> I might sound bit confusing . but any help how to debug it would be
> relay great.
I'm not sure where your problem is. I have taken the approach of
keeping my main app 'self-sufficient'. It is built with 'startup from
reset' and 'copy interrupt vectors to RAM' and performs its own
hardware init, ctl init etc. My main app does not call anything in my
secondary boot loader - a simple C/C++ polling-type app that does the
minimun hardware init. for itself, loads the main app and jumps to it.
If I had put my ctl OS, I/O etc. into the boot code and got at it via
software interrupts from the main app, I would be forever reblowing
the boot code because of my bugs!
Rgds,
Martin
'mornin..
> I have a strange problem. with the CTL(crossworks
> tasking lib). Have created two tasks , and hooked the timer0 for the
> task switching. every thing works fine if I program it using JTAG. but
> when I start the application by switching the power off and on then
> the application hangs when the ctl_taskrun
> is called. boot loader is running and it starts the application.
> Before application is started all the peripherals are reseted.This
> problem is bugging me for a week.START_UP_FROM_RESET is defined.
> I do not know how to debug it.
Nor do I. Luckily, I do not see this problem on my 2129.
I has some basic questions.
>
> 1) If you run your application form the JTAG (application starts form
> boot block 1) , and there is a boot loader. does the boot loader runs
> first then the application is started ?
IMHO, the built-in boot loader must run first in order to run the
protocol with the host and blow the application into flash.
> 2)found a strange behavior , the application runs(power ON/OFF cycle)
> when I configure the RTC for a second alarm interrupt . In the
> bootloader code the RTC is configured for the alarm interrupt.
Why would the built-in boot loader configure the RTC? Do you have a
secondary boot loader - you load your app from an SD card or something??
my
> question is In bootlader the RTC is configured and then the startup
> code is called where the software reset is performed, which clears all
> the peripherals registers including the RTC registers and clock
> configurations newly done, does the registers are not clearly reset ,
> how do I check it?
Why does you boot loader set up the RTC? Surely, there is little
point in setting it before the main app runs?
> I might sound bit confusing . but any help how to debug it would be
> relay great.
I'm not sure where your problem is. I have taken the approach of
keeping my main app 'self-sufficient'. It is built with 'startup from
reset' and 'copy interrupt vectors to RAM' and performs its own
hardware init, ctl init etc. My main app does not call anything in my
secondary boot loader - a simple C/C++ polling-type app that does the
minimun hardware init. for itself, loads the main app and jumps to it.
If I had put my ctl OS, I/O etc. into the boot code and got at it via
software interrupts from the main app, I would be forever reblowing
the boot code because of my bugs!
Rgds,
Martin
Reply by ●March 3, 20082008-03-03
Hi Martin;
> Why would the built-in boot loader configure the RTC? Do you have a
> secondary boot loader - you load your app from an SD card or
something??
we do some hardware testing stuff in the bootloader, thats why the
RTC is used. but when my App starts it should make sure that all the
registers are cleared and start the app(to my knoweledge its done in
startup but there is some loop hole in it, like RTC registeres are
not cleared in the software reset)
> If I had put my ctl OS, I/O etc. into the boot code and got at it
via
> software interrupts from the main app, I would be forever reblowing
> the boot code because of my bugs!
I do not call any functions or expect any configuratuion form the
bootloader (except to start my startup code and my application).
regards
Ashok
> my
> > question is In bootlader the RTC is configured and then the
startup
> > code is called where the software reset is performed, which
clears all
> > the peripherals registers including the RTC registers and clock
> > configurations newly done, does the registers are not clearly
reset ,
> > how do I check it?
>
> Why does you boot loader set up the RTC? Surely, there is little
> point in setting it before the main app runs?
>
> > I might sound bit confusing . but any help how to debug it would
be
> > relay great.
>
> I'm not sure where your problem is. I have taken the approach of
> keeping my main app 'self-sufficient'. It is built with 'startup
from
> reset' and 'copy interrupt vectors to RAM' and performs its own
> hardware init, ctl init etc. My main app does not call anything
in my
> secondary boot loader - a simple C/C++ polling-type app that does
the
> minimun hardware init. for itself, loads the main app and jumps to
it.
>
> If I had put my ctl OS, I/O etc. into the boot code and got at it
via
> software interrupts from the main app, I would be forever reblowing
> the boot code because of my bugs!
>
> Rgds,
> Martin
>
Hi Martin
> Why would the built-in boot loader configure the RTC? Do you have a
> secondary boot loader - you load your app from an SD card or
something??
we do some hardware testing stuff in the bootloader, thats why the
RTC is used. but when my App starts it should make sure that all the
registers are cleared and start the app(to my knoweledge its done in
startup but there is some loop hole in it, like RTC registeres are
not cleared in the software reset)
> If I had put my ctl OS, I/O etc. into the boot code and got at it
via
> software interrupts from the main app, I would be forever reblowing
> the boot code because of my bugs!
I do not call any functions or expect any configuratuion form the
bootloader (except to start my startup code and my application).
regards
Ashok
> my
> > question is In bootlader the RTC is configured and then the
startup
> > code is called where the software reset is performed, which
clears all
> > the peripherals registers including the RTC registers and clock
> > configurations newly done, does the registers are not clearly
reset ,
> > how do I check it?
>
> Why does you boot loader set up the RTC? Surely, there is little
> point in setting it before the main app runs?
>
> > I might sound bit confusing . but any help how to debug it would
be
> > relay great.
>
> I'm not sure where your problem is. I have taken the approach of
> keeping my main app 'self-sufficient'. It is built with 'startup
from
> reset' and 'copy interrupt vectors to RAM' and performs its own
> hardware init, ctl init etc. My main app does not call anything
in my
> secondary boot loader - a simple C/C++ polling-type app that does
the
> minimun hardware init. for itself, loads the main app and jumps to
it.
>
> If I had put my ctl OS, I/O etc. into the boot code and got at it
via
> software interrupts from the main app, I would be forever reblowing
> the boot code because of my bugs!
>
> Rgds,
> Martin
>
Hi Martin
Reply by ●March 3, 20082008-03-03
--- In l..., "virtualashok"
wrote:
>
> Hi Guys,
>
> I have a strange problem. with the CTL(crossworks
> tasking lib). Have created two tasks , and hooked the timer0 for the
> task switching. every thing works fine if I program it using JTAG.
but
> when I start the application by switching the power off and on then
> the application hangs when the ctl_taskrun
> is called. boot loader is running and it starts the application.
> Before application is started all the peripherals are reseted.This
> problem is bugging me for a week.START_UP_FROM_RESET is defined.
> I do not know how to debug it. I has some basic questions.
>
> 1) If you run your application form the JTAG (application starts
form
> boot block 1) , and there is a boot loader. does the boot loader
runs
> first then the application is started ?
> 2)found a strange behavior , the application runs(power ON/OFF
cycle)
> when I configure the RTC for a second alarm interrupt . In the
> bootloader code the RTC is configured for the alarm interrupt. my
> question is In bootlader the RTC is configured and then the startup
> code is called where the software reset is performed, which clears
all
> the peripherals registers including the RTC registers and clock
> configurations newly done, does the registers are not clearly
reset ,
> how do I check it?
>
> I might sound bit confusing . but any help how to debug it would be
> relay great.
>
The tasking library has this nagging requirement that there is a main
loop always ready to run (they do not supply an "idle" task). Have
you supplied this low priority task?
That said, how do you know that the program runs until ctl_taskrun is
called?
Regards,
Bruce
wrote:
>
> Hi Guys,
>
> I have a strange problem. with the CTL(crossworks
> tasking lib). Have created two tasks , and hooked the timer0 for the
> task switching. every thing works fine if I program it using JTAG.
but
> when I start the application by switching the power off and on then
> the application hangs when the ctl_taskrun
> is called. boot loader is running and it starts the application.
> Before application is started all the peripherals are reseted.This
> problem is bugging me for a week.START_UP_FROM_RESET is defined.
> I do not know how to debug it. I has some basic questions.
>
> 1) If you run your application form the JTAG (application starts
form
> boot block 1) , and there is a boot loader. does the boot loader
runs
> first then the application is started ?
> 2)found a strange behavior , the application runs(power ON/OFF
cycle)
> when I configure the RTC for a second alarm interrupt . In the
> bootloader code the RTC is configured for the alarm interrupt. my
> question is In bootlader the RTC is configured and then the startup
> code is called where the software reset is performed, which clears
all
> the peripherals registers including the RTC registers and clock
> configurations newly done, does the registers are not clearly
reset ,
> how do I check it?
>
> I might sound bit confusing . but any help how to debug it would be
> relay great.
>
The tasking library has this nagging requirement that there is a main
loop always ready to run (they do not supply an "idle" task). Have
you supplied this low priority task?
That said, how do you know that the program runs until ctl_taskrun is
called?
Regards,
Bruce
Reply by ●March 3, 20082008-03-03
> The tasking library has this nagging requirement that
there is a
main
> loop always ready to run (they do not supply an "idle" task).
Have
> you supplied this low priority task?
>
> That said, how do you know that the program runs until ctl_taskrun
is
> called?
>
> Regards,
> Bruce
>
Hi Bruce,
Well i did supply the main task to low priority and its
always ready to run when all the higher priority task suspends its
self.
I try to print to the uart before i call this ctl_taskrun, which is
executing and i see the message in the UART.
Regards
Ashok
main
> loop always ready to run (they do not supply an "idle" task).
Have
> you supplied this low priority task?
>
> That said, how do you know that the program runs until ctl_taskrun
is
> called?
>
> Regards,
> Bruce
>
Hi Bruce,
Well i did supply the main task to low priority and its
always ready to run when all the higher priority task suspends its
self.
I try to print to the uart before i call this ctl_taskrun, which is
executing and i see the message in the UART.
Regards
Ashok
Reply by ●March 3, 20082008-03-03
--- In l..., "virtualashok" wrote:
>
> > The tasking library has this nagging requirement that there is a
> main
> > loop always ready to run (they do not supply an "idle" task).
> Have
> > you supplied this low priority task?
> >
> > That said, how do you know that the program runs until ctl_taskrun
> is
> > called?
> >
> > Regards,
> > Bruce
> > Hi Bruce,
>
> Well i did supply the main task to low priority and its
> always ready to run when all the higher priority task suspends its
> self.
>
> I try to print to the uart before i call this ctl_taskrun, which is
> executing and i see the message in the UART.
>
Where is 'ctl_taskrun'? What file is it in?
Rgds,
Martin
>
> > The tasking library has this nagging requirement that there is a
> main
> > loop always ready to run (they do not supply an "idle" task).
> Have
> > you supplied this low priority task?
> >
> > That said, how do you know that the program runs until ctl_taskrun
> is
> > called?
> >
> > Regards,
> > Bruce
> > Hi Bruce,
>
> Well i did supply the main task to low priority and its
> always ready to run when all the higher priority task suspends its
> self.
>
> I try to print to the uart before i call this ctl_taskrun, which is
> executing and i see the message in the UART.
>
Where is 'ctl_taskrun'? What file is it in?
Rgds,
Martin
Reply by ●March 3, 20082008-03-03
