Strange UCOS behavior

Hi all,

I am working with an XG4200 board from X-Graph. This is based on the 4000
processor.

I can't seem to get UCOS to work with this and it should as it says it is
supported.

I have reduced the code down to 1 task I create and then this is started
when OSStart is called.

The application starts OK and goes through some initialising of the XG
hardware which it does fine.

Break pointing my task I see it start and I can step through it. Nothing in
there at present just a while loop (I commented out all the code) and call
to OSTimeDly(1);

Now, everything runs until I hit step on the OSTimeDly when I suddenly get
what at first I thought was a restart of the code but after the init
completes, I am left sitting back to the OSTimeDly I just stepped into. The
breakpoint I have in the init code never gets called when this apparent
restart happens. It does when I do a normal startup.

It looks like the task scheduler of UCOS is jumping to the wrong location. I
have used the same code that works fine with a 9.62 and a 10.64 UCOS apps I
have written. They all have 5 or more tasks that work fine.

After a few steps or a run at this point I get a debugging timeout which I
expected due to eventual stack curruption.

I am using 10.66 for this and tomorrow morning I am going to try this on
10.64 after installing the XGraph drivers for it.

The following is the defines I have for UCOS. As I said, this is basically
what I have for the 9.62 and 10.64 application albeit different task count

/***************************************************************************
**

* uC/OS-II CONFIGURATION

****************************************************************************
*/

// Redefine uC/OS-II configuration constants as necessary

#define MAX_SOCKET_LOCKS (MAX_TCP_SOCKET_BUFFERS + MAX_UDP_SOCKET_BUFFERS) +
7

#define OS_MAX_EVENTS MAX_TCP_SOCKET_BUFFERS + MAX_UDP_SOCKET_BUFFERS + 2 +
10

#define OS_MAX_TASKS 5 // Maximum number of tasks

#define OS_TASK_CREATE_EN 0 // Disable normal task creation

#define OS_TASK_CREATE_EXT_EN 1 // Enable extended task creation

#define OS_TASK_DEL_EN 0 // Enable task deletion

#define OS_TASK_QUERY_EN 0 // Enable statistics task creation

#define OS_TASK_STAT_EN 0 // Enable statistics task creation

#define OS_SEM_EN 1 // Enable semaphores

#define OS_SEM_QUERY_EN 0 // Enable semaphore querying

#define OS_MBOX_EN 0 // Enable mailboxes

#define OS_MBOX_POST_EN 0 // Enable posting messages to mailbox

#define OS_MBOX_QUERY_EN 0 // Enable mailbox querying

#define OS_Q_EN 1 // Enable queues

#define OS_Q_ACCEPT_EN 1 // Enable accepting messages from queue

#define OS_Q_POST_EN 1 // Enable posting messages to queue

#define OS_Q_POST_FRONT_EN 1 // Enable posting messages to front of
queue

#define OS_Q_QUERY_EN 1 // Enable queue querying

#define OS_TASK_CHANGE_PRIO_EN 0 // Enable task priority change

#define OS_TASK_SUSPEND_EN 0 // Enable task suspend and resume

#define OS_TIME_DLY_HMSM_EN 0 // Enable OSTimeDlyHMSM

#define OS_MUTEX_EN 0 // Enable
Mutex creation

#define OS_FLAG_QUERY_EN 1

// Must reserve stacks for tasks plus 2 additional stacks:

// 256 byte stack for uCosII's idle task

// 512 byte stack for this main() program

#define STACK_CNT_256 1 // number of 256 byte stacks

#define STACK_CNT_512 1 // number of 512 byte stacks

#define STACK_CNT_1K 0 // number of 1K stacks

#define STACK_CNT_2K 4 // number of 2K stacks

#define STACK_CNT_4K 0 // number of 4K stacks

#define OS_CPU_HOOKS 0 // Hook functions are defined in this
file

#define OS_MAX_FLAGS 8 // Max. number of Event Flag Groups in
application ...

#define OS_FLAG_EN 1 // Enable event flags

#define OS_FLAG_ACCEPT_EN 0 // Enable OSFlagAccept()

#define OS_ARG_CHK_EN 0 // Enable argument checking

#define OS_FLAG_WAIT_CLR_EN 1 // Include code for Wait on Clear EVENT
FLAGS

Any ideas where I should be looking?

Dave.

---

Very funny Scotty, now beam down my clothes.

--- Start a New Thread

On Oct 31, 2011, at 8:31 AM, Dave McLaughlin wrote:
> Any ideas where I should be looking?
>

Try a larger stack. The task that calls tcp_tick() should probably have a 4KB stack. It might not need to be that large in DC 10, but I seem to recall that in DC 8 or DC 9, the DHCP client could chew up a lot of stack.

I have no idea how much stack the XG4200 requires.

-Tom Start a New Thread

Hi Tom

Thanks for the pointers. This task did have a 4K stack but still the same.

By the way, if I remove the OSTimeDly() call the task runs just fine.

It certainly sounds like a stack issue and this task calls tcp_tick() as
part of the XG library call.

I'll have a play with it tomorrow when I get the board back. I'll see if any
of the other tasks will run with the main task set to a lower priority and
not call to OSTimeDly()

The thing is that X-Graph have not actually tested any of their code with
UCOS but did inform me that one customer was using it without any issues.

Cheers.

Dave.

From: r... [mailto:r...] On
Behalf Of Tom Collins
Sent: 02 November 2011 11:07
To: r...
Subject: Re: [rabbit-semi] Strange UCOS behavior

On Oct 31, 2011, at 8:31 AM, Dave McLaughlin wrote:

Any ideas where I should be looking?

Try a larger stack. The task that calls tcp_tick() should probably have a
4KB stack. It might not need to be that large in DC 10, but I seem to
recall that in DC 8 or DC 9, the DHCP client could chew up a lot of stack.

I have no idea how much stack the XG4200 requires.

-Tom Start a New Thread

Hi Dave,

I have a custom board from X-Graph and have used UCOS for that with no issues so far. However my board does not use a lot of the features of the X-Graph libraries as it does not have any LCD support.

The only area I had any problems with was the remote firmware upgrade
library which seemed to give me some issues but I think they were related to running out of code space and I just dropped that feature and haven't had the time to go back and see if it is still there.

I did add the XG4100 as a port to the BACnet stack but didn't use UCOS for that one as I wanted to have an example of the stack running without it - all the other ports use it.

Regards,
Peter
--- In r..., "Dave McLaughlin" wrote:
>
> Hi Tom
>
>
>
> Thanks for the pointers. This task did have a 4K stack but still the same.
>
>
>
> By the way, if I remove the OSTimeDly() call the task runs just fine.
>
>
>
> It certainly sounds like a stack issue and this task calls tcp_tick() as
> part of the XG library call.
>
>
>
> I'll have a play with it tomorrow when I get the board back. I'll see if any
> of the other tasks will run with the main task set to a lower priority and
> not call to OSTimeDly()
>
>
>
>
>
> The thing is that X-Graph have not actually tested any of their code with
> UCOS but did inform me that one customer was using it without any issues.
>
>
>
> Cheers.
>
> Dave.
>
>
>
>
>
> From: r... [mailto:r...] On
> Behalf Of Tom Collins
> Sent: 02 November 2011 11:07
> To: r...
> Subject: Re: [rabbit-semi] Strange UCOS behavior
>
>
>
>
>
> On Oct 31, 2011, at 8:31 AM, Dave McLaughlin wrote:
>
> Any ideas where I should be looking?
>
>
>
> Try a larger stack. The task that calls tcp_tick() should probably have a
> 4KB stack. It might not need to be that large in DC 10, but I seem to
> recall that in DC 8 or DC 9, the DHCP client could chew up a lot of stack.
>
>
>
> I have no idea how much stack the XG4200 requires.
>
>
>
> -Tom
>

Start a New Thread

Thanks Peter,

When I get the board back tomorrow from the client (they wanted to show the
box to their client) I will try out a few things in regards to Tom's
referrence the stack size.

I am using the module with the 7" LCD.

The XG4200 uses serial flash so is not remote upgradable so I may change out
the processor module of my design for something else after this one is done.
I need to upgrade remotely for new designs so this being a missing feature I
can't really consider this again other than for this particular unit (the
client is local so no real issues upgrading this one).

This is a pity as the unit works well and the graphics display is quick, if
a little flickering at times when viewed at less than or greater than 90
deg.

Dave.

From: r... [mailto:r...] On
Behalf Of petermcs
Sent: 02 November 2011 15:13
To: r...
Subject: [rabbit-semi] Re: Strange UCOS behavior

Hi Dave,

I have a custom board from X-Graph and have used UCOS for that with no
issues so far. However my board does not use a lot of the features of the
X-Graph libraries as it does not have any LCD support.

The only area I had any problems with was the remote firmware upgrade
library which seemed to give me some issues but I think they were related to
running out of code space and I just dropped that feature and haven't had
the time to go back and see if it is still there.

I did add the XG4100 as a port to the BACnet stack but didn't use UCOS for
that one as I wanted to have an example of the stack running without it -
all the other ports use it.

Regards,
Peter Start a New Thread

I have run into similar problems using the PPP stack.

While uCOS is 'supported', there are a lot of bugs in the implementation, especially when using it with hardware devices that generate interrupts.

Does the XG4200 generate any interrupts? If it does, I would bet that is where everything is failing. None of the interrupt handlers that come with DynamicC are compatible with uCOS.

--- In r..., "Dave McLaughlin" wrote:
>
> Hi all,
>
>
>
> I am working with an XG4200 board from X-Graph. This is based on the 4000
> processor.
>
>
>
> I can't seem to get UCOS to work with this and it should as it says it is
> supported.
>
>
>
> I have reduced the code down to 1 task I create and then this is started
> when OSStart is called.
>
>
>
> The application starts OK and goes through some initialising of the XG
> hardware which it does fine.
>
>
>
> Break pointing my task I see it start and I can step through it. Nothing in
> there at present just a while loop (I commented out all the code) and call
> to OSTimeDly(1);
>
>
>
> Now, everything runs until I hit step on the OSTimeDly when I suddenly get
> what at first I thought was a restart of the code but after the init
> completes, I am left sitting back to the OSTimeDly I just stepped into. The
> breakpoint I have in the init code never gets called when this apparent
> restart happens. It does when I do a normal startup.
>
>
>
> It looks like the task scheduler of UCOS is jumping to the wrong location. I
> have used the same code that works fine with a 9.62 and a 10.64 UCOS apps I
> have written. They all have 5 or more tasks that work fine.
>
>
>
> After a few steps or a run at this point I get a debugging timeout which I
> expected due to eventual stack curruption.
>
>
>
>
>
> I am using 10.66 for this and tomorrow morning I am going to try this on
> 10.64 after installing the XGraph drivers for it.
>
>
>
>
>
> The following is the defines I have for UCOS. As I said, this is basically
> what I have for the 9.62 and 10.64 application albeit different task count
>
>
>
> /***************************************************************************
> **
>
> * uC/OS-II CONFIGURATION
>
> ****************************************************************************
> */
>
> // Redefine uC/OS-II configuration constants as necessary
>
> #define MAX_SOCKET_LOCKS (MAX_TCP_SOCKET_BUFFERS + MAX_UDP_SOCKET_BUFFERS) +
> 7
>
> #define OS_MAX_EVENTS MAX_TCP_SOCKET_BUFFERS + MAX_UDP_SOCKET_BUFFERS + 2 +
> 10
>
>
>
> #define OS_MAX_TASKS 5 // Maximum number of tasks
>
> #define OS_TASK_CREATE_EN 0 // Disable normal task creation
>
> #define OS_TASK_CREATE_EXT_EN 1 // Enable extended task creation
>
> #define OS_TASK_DEL_EN 0 // Enable task deletion
>
> #define OS_TASK_QUERY_EN 0 // Enable statistics task creation
>
> #define OS_TASK_STAT_EN 0 // Enable statistics task creation
>
> #define OS_SEM_EN 1 // Enable semaphores
>
> #define OS_SEM_QUERY_EN 0 // Enable semaphore querying
>
> #define OS_MBOX_EN 0 // Enable mailboxes
>
> #define OS_MBOX_POST_EN 0 // Enable posting messages to mailbox
>
> #define OS_MBOX_QUERY_EN 0 // Enable mailbox querying
>
> #define OS_Q_EN 1 // Enable queues
>
> #define OS_Q_ACCEPT_EN 1 // Enable accepting messages from queue
>
> #define OS_Q_POST_EN 1 // Enable posting messages to queue
>
> #define OS_Q_POST_FRONT_EN 1 // Enable posting messages to front of
> queue
>
> #define OS_Q_QUERY_EN 1 // Enable queue querying
>
> #define OS_TASK_CHANGE_PRIO_EN 0 // Enable task priority change
>
> #define OS_TASK_SUSPEND_EN 0 // Enable task suspend and resume
>
> #define OS_TIME_DLY_HMSM_EN 0 // Enable OSTimeDlyHMSM
>
> #define OS_MUTEX_EN 0 // Enable
> Mutex creation
>
> #define OS_FLAG_QUERY_EN 1
>
>
>
> // Must reserve stacks for tasks plus 2 additional stacks:
>
> // 256 byte stack for uCosII's idle task
>
> // 512 byte stack for this main() program
>
> #define STACK_CNT_256 1 // number of 256 byte stacks
>
> #define STACK_CNT_512 1 // number of 512 byte stacks
>
> #define STACK_CNT_1K 0 // number of 1K stacks
>
> #define STACK_CNT_2K 4 // number of 2K stacks
>
> #define STACK_CNT_4K 0 // number of 4K stacks
>
> #define OS_CPU_HOOKS 0 // Hook functions are defined in this
> file
>
>
>
> #define OS_MAX_FLAGS 8 // Max. number of Event Flag Groups in
> application ...
>
> #define OS_FLAG_EN 1 // Enable event flags
>
> #define OS_FLAG_ACCEPT_EN 0 // Enable OSFlagAccept()
>
> #define OS_ARG_CHK_EN 0 // Enable argument checking
>
> #define OS_FLAG_WAIT_CLR_EN 1 // Include code for Wait on Clear EVENT
> FLAGS
>
>
>
>
>
> Any ideas where I should be looking?
>
>
>
> Dave.
>
> ---
>
> Very funny Scotty, now beam down my clothes.
>
> ---
>

Start a New Thread

Thanks Joey,

You have hit the nail on head, so to speak.

According to the docs, Dynamic C when used with UCOS2 should have the
interrupt handlers setup to work with and I can use RS232 drivers and they
are interrupt driven for receive and transmit.

It may be that the XG drivers are not UCOS2 aware and I will check with the
manufacturer on this to confirm if there is any interrupt handlers. There is
a document on how to make your code UCOS2 aware so I will send them the
details of this. They have been pretty responsive in the past so with luck
they can sort this out for me too.

By the way, but putting the graphics task as the lowest priority task and
removing the OSTimeDly call, the higher priority tasks run as they simply
pre-empt this non-yielding task. This seems to work well and my software now
runs. The other 4 tasks call OSTimeDly without any issues. Because the other
tasks don't do much, I don't see any delays in the graphical display
updating.

I am not happy with this solution and I certainly don't want to go back to
doing costatements etc as I love the way UCOS2 allows me to split tasks up
so much more easily so I will be in touch with the manufacturer to see if I
can get this resolved.

Cheers

Dave.

From: r... [mailto:r...] On
Behalf Of Joey
Sent: 10 November 2011 07:51
To: r...
Subject: [rabbit-semi] Re: Strange UCOS behavior

I have run into similar problems using the PPP stack.

While uCOS is 'supported', there are a lot of bugs in the implementation,
especially when using it with hardware devices that generate interrupts.

Does the XG4200 generate any interrupts? If it does, I would bet that is
where everything is failing. None of the interrupt handlers that come with
DynamicC are compatible with uCOS. Start a New Thread

There is a difference between making the handlers ucos aware and making them ucos compatible.
 
Problems occur when interrupts are enabled before all the data that is pushed on the stack by the handler is cleared.
 
Bad case:
 
interrupt start
    push data on stack
    A) re-enable interrupts        
    B) pop data from stack
    return from interrupt
 
In the bad case, ucos crashes when an interrupt occurs between A and B.  This is usually the timer interrupt.
 
This can be fixed simply.
 interrupt start
    push data on stack
    pop data from stack
    return from interrupt and enable interrupts
 
As long as the stack never has interrupt data on it when interrupts are enabled, you will be ok.
 
Of course, this means interrupts will be disabled for longer periods on time.
 
If you cannot tolerate that, you must mae the handler uCOS aware and manage the 'nesting level'.
 
That's what I did to make the serlink.lib ucos compatible. (I checked in the code into this website).
 
Joey

From: Dave McLaughlin
To: r...
Sent: Thursday, November 10, 2011 10:15 AM
Subject: RE: [rabbit-semi] Re: Strange UCOS behavior
 
Thanks Joey,
 
You have hit the nail on head, so to speak.
 
According to the docs, Dynamic C when used with UCOS2 should have the interrupt handlers setup to work with and I can use RS232 drivers and they are interrupt driven for receive and transmit.
 
It may be that the XG drivers are not UCOS2 aware and I will check with the manufacturer on this to confirm if there is any interrupt handlers. There is a document on how to make your code UCOS2 aware so I will send them the details of this. They have been pretty responsive in the past so with luck they can sort this out for me too.
 
By the way, but putting the graphics task as the lowest priority task and removing the OSTimeDly call, the higher priority tasks run as they simply pre-empt this non-yielding task. This seems to work well and my software now runs. The other 4 tasks call OSTimeDly without any issues. Because the other tasks don't do much, I don't see any delays in the graphical display updating.
 
I am not happy with this solution and I certainly don't want to go back to doing costatements etc as I love the way UCOS2 allows me to split tasks up so much more easily so I will be in touch with the manufacturer to see if I can get this resolved.
 
Cheers
Dave…
 
 
From:r... [mailto:r...] On Behalf Of Joey
Sent: 10 November 2011 07:51
To: r...
Subject: [rabbit-semi] Re: Strange UCOS behavior
 
 
I have run into similar problems using the PPP stack.

While uCOS is 'supported', there are a lot of bugs in the implementation, especially when using it with hardware devices that generate interrupts.

Does the XG4200 generate any interrupts? If it does, I would bet that is where everything is failing. None of the interrupt handlers that come with DynamicC are compatible with uCOS. Start a New Thread

Thanks for the information Joey,

It just seems crazy that Rabbit offer the UCOS OS with their software and yet they fail to actually change the code to work with it.

I switched to Netburner who use the older UCOS 1 and it is much more stable and works well with it. Their code was designed from the outset to work with the real time OS so has all the correct code to handle this.

I will look into the code a little more to see what the XGraph code is doing but as a lot of their code is encrypted, it is a little difficult to debug it.

Cheers,
Dave…

From: r... [mailto:r...] On Behalf Of Robert Grady
Sent: 11 November 2011 10:45
To: r...
Subject: Re: [rabbit-semi] Re: Strange UCOS behavior

There is a difference between making the handlers ucos aware and making them ucos compatible.

Problems occur when interrupts are enabled before all the data that is pushed on the stack by the handler is cleared.

Bad case:

interrupt start

push data on stack

A) re-enable interrupts

B) pop data from stack

return from interrupt

In the bad case, ucos crashes when an interrupt occurs between A and B. This is usually the timer interrupt.

This can be fixed simply.

interrupt start

push data on stack
pop data from stack

return from interrupt and enable interrupts

As long as the stack never has interrupt data on it when interrupts are enabled, you will be ok.

Of course, this means interrupts will be disabled for longer periods on time.

If you cannot tolerate that, you must mae the handler uCOS aware and manage the 'nesting level'.

That's what I did to make the serlink.lib ucos compatible. (I checked in the code into this website).

Joey Start a New Thread

On 11/11/2011 12:07 AM, Dave McLaughlin wrote:
>
> Thanks for the information Joey,
>
>
>
> It just seems crazy that Rabbit offer the UCOS OS with their software
> and yet they fail to actually change the code to work with it.
>
>
>
> I switched to Netburner who use the older UCOS 1 and it is much more
> stable and works well with it. Their code was designed from the outset
> to work with the real time OS so has all the correct code to handle this.
>
>
>
> I will look into the code a little more to see what the XGraph code is
> doing but as a lot of their code is encrypted, it is a little
> difficult to debug it.
>
>
>

The problem with the rabbit is it is slow and some of the hardware can
not handle much interrupt latency. Serial ports are one, Ports A-D have
no FIFO so interrupts have to be processed in one character time or
characters are lost. Ports E-F do have a 4-byte FIFO, so they are less
of an issue.

uCOS is written in C and with DC's inefficient compiler, it spends a lot
of time in the OS. Interrupts that don't use OS calls should not need
any change. They can enable interrupts if they can guarantee they will
finish before the next interrupt. Not the case if multiple devices use
the same interrupt level.

The Netburner is an order of a magnitude faster and the compiler
generates much better code, so there is less of a problem. I've moved on
to PIC32 to have much more speed (and much cheaper hardware.) I have
also used the Netburner modules with success but am not sure on their
future.

There has long been bugs in the uCOS support in DC. When porting the
stack to Softools, we found unbalanced semaphore calls. Later libraries
seem to ignore uCOS even exists. The debugger seems to have real issues
with it, had to make sure all debugging in the PPP code was turned off.

We basically did not use uCOS with Softools. I used the CoExec task
switcher (works in DC 9.x also) and users that needed hard real-time
used Turbotask.

I bought the uCOS book back when it came out. The disk has sat unused.
It looked overly complicated for low-end processors.

--
------
Scott G. Henion, Consultant
Web site: http://SHDesigns.org
------ Start a New Thread