Messages

61

µTasker general / Re: TCIP

« on: August 05, 2010, 11:03:16 AM »

Hi Mark,

Where can I got some flags, indicating that The TCP stack has still not yet acked a former frame from the Pc, to prevent me sending a new TCP frame, before this ack....

I found inside fnHandleTCP() whne we ask for an Ack, but how to do from the application level ?

Thanks.

62

µTasker general / Re: TCIP

« on: August 03, 2010, 09:08:01 AM »

Hi Mark ,
I still have a question concerning this problem : I effectively send the frame 27 of the following screen capture before the ACK of the frame 26 was send by the board, but why the ACK flag was set in frame 27, it look like it's an ack of the frame 26. So why a new ACK was sent by the µtasker stack ?

Thanks for your help.

Hervé

63

µTasker general / Re: TCIP

« on: August 02, 2010, 01:16:51 PM »

Hello Mark,

In fact that's also what I supposed. But there is effectively a problem in this TCIP sequence: My board send the two frames (15 and 16)with to different Ack number but with the same Sequence Number. So the windows socket's, on the PC, saw only the last one (So I think...) .
Why the sequence number of the frame 15 was not increased ?
I think it could resolve my blocking : The board is undefinitely waiting for an Ack of the frame 14; which will never occur.
And then reset the TCPIP Session.

What do you think of my point of view ?

64

µTasker general / TCIP

« on: August 02, 2010, 08:25:45 AM »

I don't know so much about TCPIP protocole, and I need some help to understand this behaviour :
My board at 192.168.167.205 replies to a PC at 192.168.167.83 but on frame #15 of this record there is an unnecessary ack for me. Can somebody explain it to me ?

65

NXP^TM LPC2XXX and LPC17XX / Prefetch Abort debugging

« on: April 02, 2010, 07:35:34 AM »

I'm using LPC2387 and during the normal operation I got a Prefetch Abort Exception.
To determine the cause I put a breakpoint and had a look to the differents registers.
I saw that at this time r14_abt = 0x02.
If I substract 4 to see the PC address of the exception source I should got the caller address, but in this case it means nothing?
I tried :

Code: [Select]

SUBS PC,R14,#4 (to get back to the exception caller) but it goes nowhere.

How can I see what was the address which caused this exception?
How is it possible to have R14 = 0x02 during an exception ?

Thanks for help.

66

µTasker general / Re: uNetwork

« on: March 29, 2010, 01:04:49 PM »

Hello,

Let suppose I plan to use uNetwork in a Master/Slave network.
Can I suppose each node only has to have a 2 entry ucNodeMac ?

    MAC : 0.0.0.0.0.1 IP : 192.168.0.1    MASTER
    MAC : 0.0.0.0.0.x IP : 192.168.0.x    Board Id

And the master the complete table (assuming it's the only one which can send message and receive response...)

    MAC : 0.0.0.0.0.1 IP : 192.168.0.1    MASTER
    MAC : 0.0.0.0.0.x IP : 192.168.0.x    Board 1
    MAC : 0.0.0.0.0.y IP : 192.168.0.y    Board 2
    MAC : 0.0.0.0.0.z IP : 192.168.0.z    Board 3

67

µTasker general / Re: I2C control

« on: March 17, 2010, 04:15:45 PM »

For this issue I also got a problem with dynamic allocation of I2C drivers.
When I plug an I2C module, I can detect it and do something like that :

Code: [Select]

if((adc.modA_status==MOD_I2C) && (MODAPortID==0)){
    tIICParameters.Channel = MODA_IIC_CHANNEL;
    MODAPortID = fnOpen( TYPE_IIC, FOR_I_O, &tIICParameters); // open the channel with defined configurations
}
When I unplug it (to plug another sort of module) I wanted to shut down the corresponding MODAPortID driver.
But I did not found any fnClose()....

Is it normal?
What is the best way to free the corresponding buffer ?
Can I use fnFreeBuffer() ? Is it enough ?

Regards

68

µTasker general / Re: I2C control

« on: March 15, 2010, 06:31:16 PM »

Hi Mark,

Thanks a lot for your prompt reply.
It works fine and knox I got plugin-detection of mys pads....

This not so difficult when you explain it.

69

µTasker general / I2C control

« on: March 12, 2010, 12:08:49 PM »

Hello,

I use I2c for onboard component and it works fine.

I plan to use it with external PIA (8254 type) controlling a keyboard/display pad.
I send a command to the PIA but I don't know if it is connected or not :
"the function  (!fnWrite(MODAPortID, (unsigned char *)ucTramePIA, sizeof(ucTramePIA))) always reply OK."
How can I manage to see that there is no I2C component connected at this address?

The purpose is to test when keyboard/display are hot plugged so I can initialize them.
 
Thank.

70

NXP^TM LPC2XXX and LPC17XX / Re: Heap_Mem & HEAP_START_ADDRESS

« on: January 28, 2010, 08:35:27 AM »

Perfect I got it.

Thanks a lot.

71

µTasker general / Re: FTP

« on: January 28, 2010, 08:34:54 AM »

Hello Mark,

A small note to say that with some FTP Client uses the command :RETR \mufile.txt to upload a file.
uTAsker in this case reject it because it thinks there is no name (due to backslash at first poistion).
Is it possible to add the test of a null character in second position before saying there is no name ?

Thanks

72

NXP^TM LPC2XXX and LPC17XX / Heap_Mem & HEAP_START_ADDRESS

« on: January 25, 2010, 09:21:52 AM »

Hello Mark,

I think I quite misunderstood the stack and heap variables definition.

On LPC23xx_keil.s I wrote :

Code: [Select]

         EXPORT  Stack_Mem
          AREA    STACK, NOINIT, READWRITE, ALIGN=3
Stack_Mem       SPACE   USR_Stack_Size

Heap_Size       EQU     0x00004800
          AREA    HEAP, NOINIT, READWRITE, ALIGN=3
Heap_Mem        SPACE   Heap_Size
0x00004800    is what I considered correct for my application

On TaskConfig.h

Code: [Select]

const HEAP_NEEDS ctOurHeap[] = {
    {DEFAULT_NODE_NUMBER, OUR_HEAP_SIZE},                                // our node requires this amount of heap space
    {0}                                                                  // end
};with    
#define OUR_HEAP_SIZE (HEAP_REQUIREMENTS)((18*1024)*MEM_FACTOR)
So both have the same value.....

But on LPC23XX.c I saw that you wrote

        #define HEAP_START_ADDRESS  &Stack_Mem                          // Keil - start of stack

So I don't understand why you do this ?
On the map file I saw
   0x400042a8   0x00004800   Zero   RW         2637    HEAP                lpc23xx_keil.o
    0x40008aa8   0x00000434   Zero   RW         2636    STACK               lpc23xx_keil.o
But in fact the uTasker Heap is starting at 0x40008aa8 and reserve 0x4800 byte for uTaskerHeap.
Does that means that the Heap define in lpc23xx_keil.s is not used, and do I have to put its value to zero (to recover this memory) ?

Please clarify these varaibles for me.

73

µTasker general / Re: FTP

« on: January 25, 2010, 08:45:27 AM »

Hi Mark,

I don't have the problem no more now, so you solved it.

Thanks a lot.

74

µTasker general / FTP

« on: January 21, 2010, 04:38:13 PM »

Hello Mark,

As I understand,
"favicon.ico" is a part of user_files.
When I upload it, I got 1150 bytes which matches sizeof(_favicon).

When I look into the file, the first byte is in fact nxp_favicon[5] : It starts after the FILE_HEADER.
And it ends with five dummy bytes outside of nxp_favicon.

It will be better to cancel this 5 bytes (HEADER size) sending no ? and correct the file size also ...

What is the use of the FILE_HEADER for these user_files ?

Regards

75

µTasker general / Re: fnSendBufTCP

« on: January 08, 2010, 03:02:29 PM »

Thanks a lot,
I understand that the simulator can cause an exception , which I think is a good thing.

In fact when I call fnSendBufTCP(), it is not on a Telnet Session so I did not call fnStartTelnet() before.
So it is quite normal TELNET_session == 0, no ?

Concerning fnReleaseTCP_Socket() as I told you on the former topic :
http://www.utasker.com/forum/index.php?topic=472.0
I had to use it...if not the TCP Socket is not freed....
And furthermore fnStopTelnet() is using it also.

But I will look closely to find another way.