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 - Jean-Marc DELPRAT

Pages: [1] 2 3
Hi everyone.

Netloader is no more able to remotely update the EEPROM (webpages)

Netloader fails with an error suggesting to use PASV (passive mode) instead.

wireshark trace shows that the FTP transfer is aborted by a QUIT command issued by the PC.

The same day I tried with an old PC and the same SBC board get updated fine.

Netloader logfile does not show anything interesting.

If anyone has the same issue, feel free to post here.

best regards,

Ethernet Boards (8-bit) / Re: 128k for web-page
« on: January 07, 2010, 01:20:13 AM »
Hello All,

I'm sorry about my FTP server beeing down for long time and therefore modified files for 128K EEPROM beeing no more available. I had not realised that.

I have now attached the files to this post, so everybody can easily download them. :-D

Please note this was made for an SBC44, but i think it will work as well for other boards.

Also, you need a small hardware modification (A2 to +5V), as explained by modtro2 higher in this topic.

Jean Marc.

Hello Giorgio,

Yes, windows duplicates all TCP/IP messages, but just twice and with no delay. As far as i know this is done in purpose to speedup reply. to know more about that, we'd ask to Bill !

The problem i encountered, was not the repeated sending of acks itself, it creates no problem, I just found that totally unnecessary and considered that repeated ack sending as a bug that should probably be fixed one day.

Thanks for the explanation about the doubling of delay. (thanks also to Mr karn & Partridge) But this was not the problem either.

My main problem was that the connection was shutted down after 45 seconds without transmission. This seemed a little too short to me and I wanted to increase that delay. ( I'm establishing a TCP socket between the SBC and a mobile phone, and i want the minimum data transfer in order not to pay a lot of trafic taxes for nothing !) Sending a keep alive every 4 seconds is not acceptable in that case, but one every 3 minutes would be fine. that's when i looked at the code to find out where was that 45 seconds timer that i found that the delay was instead made by the total of 3 TCP timeouts with doubling time and re sending acks at the end of each timeout I was then a little perplex!

Note that I understand also that never disconnecting is dangerous, because after some time all available sockets could be locked because of dead connections. I just posted my code because someone asked me.

Thanks for your contribution, I just hope that a TCP specialist can put an eye on that routine and make it better... better...


For the moment I have done a dirty quick fix:
see somewhere in the middle of TCPTick(void) from TCP.C :

                else {
                    #if (DEBUG_TCP >= LOG_WARN)
                    debugPutOffsetMsg(s, 41);    //@mxd:41:Timeout, resending ACK

                    // This will be one more attempt.
                      ps->RetryCount--;      //$$$JMD ADDED I DON'T WANT CONNECTION TO END = counter will not increment
//                    flags = ACK;         //$$$JMD REMOVED : DO NOT SEND UNECCESSARY ACKS

also I have changed that strange way of doubling the retry timer each time:

        // Restart timeout reference.
        ps->startTick = TickGet16bit();

        // Update timeout value if there is need to wait longer.
//        ps->TimeOut <<= 1;  //Times two //$$$JMD i don't like this idea of doubling time.

I'm not a TCP guru, so just take the above as my idea, not the absolute perfection.

best regards,

Ethernet Boards (8-bit) / Re: 128k for web-page : small bug fixed
« on: March 17, 2008, 01:17:11 PM »
I have found a small bug in the code i had written:

in the fseeGetByte() the file handle should have been given to the fseeRelease() function because the "read" and "write" flags are file specific. This bug caused data errors when reading a file crossing the 64K bank border.

//            fseeRelease(0);    // wrong
            fseeRelease(fhandle) ;  // correct

I have updted the files in my FTP server.

Ethernet Boards (8-bit) / Re: 128k for web-page
« on: February 06, 2008, 01:15:19 PM »
Thanks for your reply,
I'm happy i could help, once i had done the job, why not share with others...
as you wrote, now it is very easy to go beyond 128K, the needed modifications would be minor...
now i'm very happy and i'm using the new extra memory space with animated ajax meters.

best regards,

Ethernet Boards (8-bit) / Re: Timeout Error in TCP/IP
« on: February 04, 2008, 10:24:28 AM »
Hello Hung,

you complain about exactly the same problem i had described a few days before in this post:

did you read it before posting ?

Anyway, i have fixed the problem at 75%..... I mean that the unnecessary acks are killed, and i can keep the socket opened forever. But i would like to add a timeout of about 3 minutes in order to avoid having dead sockets stay opened forever...

I think i'll do that soon.

best regards,

Ethernet Boards (8-bit) / Re: 128k for web-page
« on: February 03, 2008, 03:41:17 AM »
Hello Danchoi,

Unfortunately my programmers did not have this new EEPROM in their list of known devices !!!
So it took me a little longer !
Here is the list of modifications I had to do in the MX 3.06 stack:

1) Change a few variables from 2 bytes to 3 bytes size. (most were already 3 bytes)
2) Check for the 64K limit and set B0 accordingly in the EEPROM command byte.
3) Memorise the B0 bit for XEEIsBusy that is called without the adress (this one was less obvious !!!)
4) Create a bank test in the read routine in case the file crosses the 64K border
5) increased the FSEE_WRITE_PAGE_SIZE to 128Bytes to make writing a little faster.
6) i also defined FSEE_FILE_SIZE_16MB to be able to make testing with a single big file.
    and also selected corresponding option in the bootloader !
7) By the way i fixed a hidden bug where EEPROM bank switching was wrongly coded:
    to see this bug, just try and select a FSEE_RESERVE_BLOCK with a value not multiple of 64 !!!
    the file system becomes totally garbled due to EEPROM block buffer overflow.
8) Of course, I bent 24LC1025 pin 3 under the chip and wired it to pin 8 (VCC)
    (bending over is more easy, but looks not so nice!)

I have put the modified files zipped in my ftp:

see PIC directory in

Best regards, and tell me if it works on your side !


And for the one who wrote "Abandon all hope, all ye who enter here", As you can see, at countrary, you must keep hoping, just be patient....

You did not include the definition of rtc structure... but i guess is a byte...   then

intead of this

        theData[4] =*10;

try this

        theData[4] = (unsigned short)*10;

best regards,

Ethernet Boards (8-bit) / Re: 128k for web-page
« on: January 27, 2008, 11:07:31 PM »

I would like also to have more EEPROM memory. I want to save pictures and javascript...

Have you solved your problem ?

In case no, i'll make some testing where I'll write the new EEPROM with a programmer and concentrate on reading, then once reading is working properly, I'll check the writing routines...

Best regards,

Ethernet Boards (8-bit) / Re: SBC44 with 18F4525......... IT WORKS !!!!!!
« on: January 23, 2008, 10:35:21 PM »
I've had a look to the adaptor you mentionned, it looks nice and sure you can make a PCB to carry the 18F4525.

I had chosen the "cheap" way, but it takes one hour of soldering with a Binocular microscope. the small 0.2mm silver plated wires soldered from top to bottom are quite tricky to solder. My solution is only acceptable for hobby applications where man time is free of charge.

Best would be that Modtronix upgrades the SBC44 to the 18F4525. I have seen that the SBC44 is NOT rhos compliant, so a new version is obviously to be expected and it would be a chance to get this CPU upgrade together with the rohs !  (David, please!!!!!!!!!!!!!!!!)

I had also thought of stripping the 3.06 but i had already size problems with the old stack, so you can imagine !!!

Best regards,

Ethernet Boards (8-bit) / Re: SBC44 with 18F4525......... IT WORKS !!!!!!
« on: January 22, 2008, 11:33:06 PM »
I have prepared some pictures of the adapter in my FTP site: (anonymous)
see PIC directory

and the modifications I had to do on the 3.06 stack are:

      TO GET IT RUNNING ON AN SBC44 with 18F4525

add "|| defined(_18F4525)" in projdefs.h to have CPU clock = 20MHZ

bug fixed in mac.c where B6 port is wrongly forced as input if board is not an SBC65/68

>>> fuses
added 18F4525 specific fuses in cpuconf.h

    #elif  defined(__18F4525)
        #pragma   config   OSC=HS,   IESO=OFF, FCMEN=OFF, PWRT=ON, BOREN=SBORDIS, BORV=0
        #pragma   config   WDT=OFF, WDTPS=128
        #pragma   config   MCLRE=ON, LPT1OSC=OFF, PBADEN=OFF, CCP2MX=PORTC
        #pragma   config   STVREN=ON, LVP=OFF, XINST=OFF, DEBUG=OFF
        #pragma   config   CP0=OFF, CP1=OFF, CP2=OFF, CPB=OFF, CPD=OFF
        #pragma   config   WRT0=OFF, WRT1=OFF, WRT2=OFF, WRTB=OFF, WRTC=OFF, WRTD=OFF
        #pragma   config   EBTR0=OFF, EBTR1=OFF, EBTR2=OFF, EBTRB=OFF

>>> PWM
18F4525 PWM registers are different (CCWF). comment out offending lines
or fix if you really need PWM (i have just commented out)

18F4525 has a 16 bits baud rate generator like the 18F6621 but clock is 20Mhz instead of 40
then brg values have to be divided by 2

no changes needed except the well known bug:
//            AdcValues[adcChannel] = ((WORD)ADRESH << 8) || ADRESL;      //BUG !!!!!!!!!!
            AdcValues[adcChannel] = ((WORD)ADRESH << 8) | ADRESL;

Ethernet Boards (8-bit) / 3.06 sending unnecessary ACKS = TCP.C BUG ?
« on: January 22, 2008, 01:50:30 PM »
If one opens a TCP connection between a computer and the Board, the Board sends unnecessary acks.
This is done by the TCPTick() routine, just like retries are done, but here retrying ACKs is totally unnecessary!
Also after sending 4 of those unnecessary ACKs the socket is forcefully closed. This is quite ennoying, I would like to maintain a connection between a board an a PC without having to reconnect every 45 seconds as it is now.

I'm quite surprised that no one already complained about this... (i have searched in the forum before posting)
(may be because normally TCP sockets are used to serve web pages and they are closed just after the transfer)

please see ethereal log below all the TCP Dup ACK 16#n !!!!!!!!!

best regards,

No.     Time            Source                Destination           Protocol Info
14 22:13:10.587491         TCP      1813 > telnet [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460
15 22:13:10.587502         TCP      1813 > telnet [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460
16 22:13:10.591907         TCP      telnet > 1813 [SYN, ACK] Seq=0 Ack=1 Win=1024 Len=0 MSS=1024
17 22:13:10.591925         TCP      1813 > telnet [ACK] Seq=1 Ack=1 Win=65535 Len=0
18 22:13:10.591934         TCP      [TCP Dup ACK 17#1] 1813 > telnet [ACK] Seq=1 Ack=1 Win=65535 Len=0
19 22:13:13.609664         TCP      [TCP Dup ACK 16#1] telnet > 1813 [ACK] Seq=1 Ack=1 Win=1024 Len=0
20 22:13:19.647035         TCP      [TCP Dup ACK 16#2] telnet > 1813 [ACK] Seq=1 Ack=1 Win=1024 Len=0
21 22:13:31.711771         TCP      [TCP Dup ACK 16#3] telnet > 1813 [ACK] Seq=1 Ack=1 Win=1024 Len=0
22 22:13:55.830735         TCP      telnet > 1813 [FIN, ACK] Seq=1 Ack=1 Win=1024 Len=0
23 22:13:55.830779         TCP      1813 > telnet [ACK] Seq=1 Ack=2 Win=65535 Len=0
24 22:13:55.830785         TCP      [TCP Dup ACK 23#1] 1813 > telnet [ACK] Seq=1 Ack=2 Win=65535 Len=0
25 22:13:55.831018         TCP      1813 > telnet [FIN, ACK] Seq=1 Ack=2 Win=65535 Len=0
26 22:13:55.831022         TCP      [TCP Retransmission] 1813 > telnet [FIN, ACK] Seq=1 Ack=2 Win=65535 Len=0
27 22:13:55.837566         TCP      [TCP Keep-Alive] telnet > 1813 [ACK] Seq=1 Ack=2 Win=1024 Len=0

Ethernet Boards (8-bit) / Re: SBC44 with 18F4525......... IT WORKS !!!!!!
« on: January 22, 2008, 12:59:59 PM »
I'll prepare some document about the upgrade.
please wait.

Ethernet Boards (8-bit) / Re: SMTP module for sending Emails
« on: December 07, 2007, 04:08:39 AM »
Just to say that i'm very glad to see all the improvements to my original small SMTP state machine.

Especially the recent adding of DNS makes it very convenient to use now ! Thanks !!!

I wish that code sharing occurs even more often with various types of code for the benefit of all of us !

Best regards,

Pages: [1] 2 3