Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - hervé

Pages: 1 2 [3] 4 5 ... 7
31
µTasker general / Re: Slow Telnet
« on: December 02, 2010, 09:03:34 AM »
Hi Mark,

To illustrate my statements : (4 frames to send one written information)


32
µTasker general / Re: Slow Telnet
« on: December 01, 2010, 01:08:27 PM »
Hi Mark,

Of course I did but not so easy to analyze.
What looks strange is that the debug send a block of data at once, but the display show only some data then waits 2 or 3secunds then continue.

How is it possible during the same sending routine?

33
µTasker general / Slow Telnet
« on: December 01, 2010, 08:20:01 AM »
Hi Mark,

When I test my board, after some hours, the telnet becomes really slow : event the echo takes some secund to be send.
All the debug output are then send by packet but not completely, and later complete.

Do you have an idea where to search for this type of problem ?

Thanks.

34
µTasker general / Re: INTERNAL_ROUTE
« on: December 01, 2010, 08:14:49 AM »
Hi Mark,

In fact :

if (fnEventMessage(TASK_DEBUG,CHECK_QUEUE, 0) >= message_length) { // check that the message will fit in the receiver's input queue
 // send message to task's input queue
}

35
µTasker general / Re: INTERNAL_ROUTE
« on: November 30, 2010, 03:36:31 PM »
Hi Mark,

I made the following changes :

Code: [Select]
#define SIZE_TEST  0xFF
....
        if (output_buffer[MSG_SOURCE_TASK] == SIZE_TEST) {                       // check on destination's queue
            return (ptQUEQue->buf_length - ptQUEQue->chars);             // remaining space in queue (before adding new message)
        }

and also

Code: [Select]
....
    int_message[MSG_SOURCE_TASK]      = SIZE_TEST; // setting the source task to SIZE_TEST causes the write to return the available queue size (before any extra data is entered)

because in fact the function fnWrite( INTERNAL_ROUTE....
is called with ucMessage[ MSG_SOURCE_TASK ] = TIMER_EVENT;
which is defined as null....



36
µTasker general / Re: INTERNAL_ROUTE
« on: November 29, 2010, 02:50:22 PM »
Thank you Mark,

It looks fine.

But as I'm only interested in knowing if I could write or not I will change the test

        if (output_buffer[MSG_SOURCE_TASK] == 0) {                       // check on destination's queue
            return (ptQUEQue->buf_length - ptQUEQue->chars);             // remaining space in queue (before adding new message)
        }

to

        if (output_buffer[MSG_SOURCE_TASK] == 0) {                       // check on destination's queue
            return ((ptQUEQue->buf_length - ptQUEQue->chars)>=nr_of_bytes);             // check remaining space in queue (before adding new message)
        }

Thanks for help again.


37
µTasker general / INTERNAL_ROUTE
« on: November 28, 2010, 05:43:54 PM »
Hello Mark,

When sending a message to a task we can test if it fits the buffer size allocated, by pointing the message to null.
Code: [Select]
fnWrite( TASK_TEST, 0, MSG_LENGTH); // test if we can write
How to do when sending to  INTERNAL_ROUTE, as the message is used to find the correct heap in this case ?

In fact I don't want to start writing a message if I could not complete ( it will be misinterpreted by the listener)

 
                

38
µTasker general / Re: Thumb strange behaviour
« on: November 24, 2010, 10:02:19 AM »
Hi Mark,

Thanks for your comments which help a lot.

Best Regards.

39
µTasker general / Re: Thumb strange behaviour
« on: November 19, 2010, 10:47:52 AM »
Hi Mark,

I do this only to debug some problem (even if it induces new one ;)
Unfortunately my IRQ stack is already at 0x1000 which is large enough for my use....


Thanks for help.


40
µTasker general / Re: Thumb strange behaviour
« on: November 18, 2010, 02:37:43 PM »
Hi Mark,

Finally it looks like the problem was because I placed a fnDebugDec() call inside fnI2CInt().
As long as I removed this debug there was no more problem......

Yours.

41
µTasker general / Interrupt strange behaviour
« on: November 18, 2010, 09:22:24 AM »
Hi Mark,

I compiled my code for ARM but got the same problem...
It happens when the interrupt occurs : As you note before, the stack pointer had also jumped to 0x4000fecc.
What is strange is that it is the start address of the stack. As the code is running through different calls to get there it would had change normally...



42
µTasker general / Re: Thumb strange behaviour
« on: November 17, 2010, 05:39:04 PM »
Hi Mark,

I already enabled ARM/Thumb Interworking for C/C++ and ASM, of course (If I don't I can't compile without error...)

If the processor automatically changes mode, I don't understand how I can have the Thumb bit cleared in entry_que() function.
When I step through this function (with ARM Mode set), the processor always finish to reach a PAbt exception.

Quite annoying.

Regards.

43
µTasker general / Re: Thumb strange behaviour
« on: November 17, 2010, 04:42:52 PM »
Hello Mark,

I think your may be right.

If the thumb mode is cancelled during the interrupt and if I call a function compiled for thumb during this interrupt , what will happen ?
With the debbuger I skip a line on two.

How can I make it works ? Is there a pragma to force the compilation of a function in ARM mode ?

Thanks for your help .



44
µTasker general / Thumb strange behaviour
« on: November 17, 2010, 03:32:00 PM »
Hello Mark,

My code is running for a while but sometime there's a strange behaviour :
From time to time, when going through the code uDisable_Interrupt();, the Thumb mode is cancelled, and then I got an exception.
Do you have any idea about this ?
Code: [Select]
extern QUEUE_TRANSFER entry_que(QUEUE_HANDLE channel, unsigned char *ptBuffer, QUEUE_TRANSFER Counter, unsigned char ucCallType, QUEUE_HANDLE DriverID)
{
    QUEQUE *ptQUEQue;
    QUEUE_TRANSFER rtn_val = 0;
    uDisable_Interrupt();                                                // disable all interrupts
    switch ( ucCallType ) {


T= 1 before uDisable_Interrupt();
T= 0 after uDisable_Interrupt();


Using Keil µVison in step by step debug mode.


45
NXPTM LPC2XXX and LPC17XX / Re: Stack_Mem
« on: October 06, 2010, 07:00:52 AM »
Thanks Mark, you help a lot.

Pages: 1 2 [3] 4 5 ... 7