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 - sparkcatcher

Pages: [1] 2 3
Ethernet Boards (8-bit) / Re: Various bugs in the network stack
« on: December 15, 2008, 04:20:51 PM »
The tcip stack has fairly long history and has gone through some major revs.  I think it orginated at some version of the Microchip stack, and was subsequently updated as Microchip updated their stack.  It's very possible because of this history it is very possible that what you think is logical might not actually be the case.

Also, because fitting the stack in what was originally a microcontroller with very limitied resource (ie, 32kROM, 1.5k RAM, 4k or 8k of receive/transmit buffer in the MAC chip) neccessitated some tradeoffs, and most likely robustness was involved in the tradeoff.  Now that many of the microcontrollers have 64k rom and 3k to 9k RAM,  it is most likely the case that the stack needs to be be re-architected, because with the increased resources, people will definitely be expecting  more robust performance.

If you are interested in doing more in-depth bug fixing you might want to start scanning the Microchip Ethernet Stack forum.  There are other stacks that have split from the main direction for various reason.  There is a stack, I seem to recall a Version 3.75, forgot the name, that is said to be fairly robust, though that depends on how one is using it.  These most likely need porting to work on Modtronix product, but you could review certain modules to look to see how different they are from the Modtronix stack.

I think most here are expecting some degree of operability in the provided stack, though certianly not the same level of resilience provided by a more resource full client adaptor.   Most aren't going to look into the stack to try to troubleshoot it.  I think doing so most likely should be a paying position somewhere, because whoever can do it, would most likely end up learning how to write a complete tcp stack. Plus, to get it right you are going to need a well equipped testing lab and reams of changelogs. :cry:


Ethernet Boards (8-bit) / Re: Various bugs in the network stack
« on: December 14, 2008, 08:49:29 PM »

>>There is nothing to protect StackTask to overwrite the current Rx buffer when it calls MACGetHeader.

I wrote my app about a year ago and so don't remember the exact details, but I do recall in the in the documentation something about what you state.  Essentially once a header is received, the application has to retreive all of the bytes as quickly as possible to prevent what you are describing.   Just based on the documentation I just assumed that some overwrite might be possible.  If any overwrite were to happen it would seem that it would gum up the application and not cause corruption in the receiving buffers, though I'm not sure.  I haven't experenced an application "gum up" at this point.

I'm wondering if you could provide some results as to the benefit your modification has provided.

>>TCPPut and TCPPutArray don't ensure the buffer of the socket is the active MAC buffer.

I recall from the documentation that some function had to be called prior to TCPut and this function set the default buffer that TCPPut used.

Looks like you are diving into this hard core.  It gets very messy fast.  I haven't had a problem my my application receiving bad data or getting confused, I've only seen an annoying issue where sometimes the receiver stops receiving, though the application still works and the transmitter still transmits.  I've attributed this to some type of receiver corruption, though it is very interrmitent.  I'm still interested in tracking this down and wonder if you could characterize the issues that you were having that the mods you made fixed.


Ethernet Boards (8-bit) / Re: Ethernet interface on SB65EC stops responding
« on: December 09, 2008, 03:19:42 PM »
Interesting post.  I note that in my application when the board stops accepting packets, it does still issue DHCP requests, which are udp packets, so your observations are very similar to what I have been seeing.

Just wondering what your criterion was for resetting the NIC like you do, and if you reset this way it would seem that you would also have to re-intialize the tcp stack.

However, if your criteria for detecting the glitch is 100% then it would be very easy to just reset the complete controller when the detection condition is met.

Is there a repeateable set of error messages that you see prior to the corruption happening? 
In my case the incoming packets simply stop being detected, so there is no get mac header request, no sign that a packet has arrived from the realtek chip.  It could be that your detection criterion would be worth monitoring, so if you could expand on that I'd appreciate it.



Ethernet Boards (8-bit) / Re: Ethernet interface on SB65EC stops responding
« on: November 04, 2008, 01:31:06 PM »
Here's some information you had requested regarding the lockups:

===== sparkcatcher =====
Lock up reported by sparkcatcher
Description: When the error happens, the receiver module stops receiving packets from the Realtek chip - tcp and udp, nothing comes in even though the receive light blinks on the ethernet connector

Model of SBC Board that locks up: sbc45 boards running 3.06
Lockup occurs on board with original or modified firmware: modified firmware
How is board connected to network:  switch:
Does activity and link LED still work:  Yes
Does unpluging network cable fix problem:  No
Make and model of switche board is connected to: LinkSys 10/100 4 port
DHCP Server on network: Yes
Is the board connected to a network with multiple computer? Yes
If so, what operating system are they running: XP, 98, Linux, FreeBSD
Sending UDP packets to board when it locks up: Don't Know
Is DHCP enabled on board: Yes
Has netBIOS and IP address of board been changed: NetBios Module Removed

I'd like to add that I think this is a stack timing issue.  I've monitored my application for over a year using the serial port as an output.  Everytime the lockup occurred, the main application continued to run, my serial port debug statements in the main loop continued to execute.  I had debug statements at the MAC layer of the stack and those statements stopped  executing after the lockup occurred, even though the ethernet connector LEDs showed packet activity, but the main loop logic continued to perform.  So the MAC layer never received notification from the RealTek chip that a new packet was ready for processing.  This leads me to believe that the receive transmit buffers are being corrupted.

If this were a power supply glitch problem, the main loop would glitch and would force a reset via the watchdog.  I never saw that, and that wouldn't cause a hangup because within 20 msec the board would be reset. 

That's what made the problem so difficult to engineer away - the processor continues executing like there is nothing wrong.

Because the mainloop application continues to execute, it seems that one might be able to write a test application that queried the the state of the network transmit and receive buffers.  These are on the Realtek chip, so might be hard to do.  Someone with very good knowledge of the way the Realtek chip interfaces with the controller will be required to find this.  I did study the Realtek interface and I have to say that interface is very unorthodox, you'd need the design engineer or a RealTek App Engineer to help you, good luck with that!

hope this helps. 
Now that the aussie dollar has depreciated so much, wonder if board prices is $us can return to previous levels? :wink:


peter f and Modtro2:
If you read through this board and the Microchip board I think you'll find enough people who have a similar problem.  The issue is most likely not a hardware problem and most likely a stack (software) problem. 

My sbc45 boards running 3.06 all have the same problem.  I've engineered a fix for my app, but would like to fix the underlying problem. 

Modtro2: I've monitored the stacktsk module using the serial port and logged packet receive errors for over a year and popped the boards with broadcast storms.  Neither are issues.  When the error happens, the receiver module stops receiving packets from the Realtek chip - tcp and udp, nothing comes in even though the receive light blinks on the ethernet connector.  That says the receive buffers have filled up and the packets are being discarded or there is a hangup.  It's very difficult to go any further, you have to monitor the contents of the receive buffers.

It is my belief that somewhere in the stack as all of the housekeeping is being done, something writes faulty data to the receive buffer manager.   It's going to be very hard to find out.  Best way is to isolate by removing modules.  I haven't done this yet.

In the interests of finding the solution,
Peter f:  are you using dhcp?
Modtro2:  it sounds like your board has a static address, but just for research purposes, are you using dhcp?


Ethernet Boards (8-bit) / Re: == Compatible third party boards ==
« on: May 30, 2008, 10:23:01 AM »
Purpose Built Sprinkler controller features SBC45     :-o

EtherRain is a sprinkler controller that provides network control of up to 8 standard 24VAC sprinkler valves.  The device requires only a single 24VAC transformer for power, has built-in rain detection, and was designed for reliable operation.

The device is based upon the modtronix SBC45 board.  The internal firmware has been customized specifically for reliable operation as a sprinkler controller.  You donít have to do any embedded programming or hardware design/integration to use the device.

The device was designed to operate with either local scheduling software or with remote Internet-based scheduling software.  A Windows administration program that features a built-in discovery function is available to provide configuration and operating tests. The device contains functionality that allows it to be controlled remotely, via the Internet, operating either as a client (best for security) or as a server.

The device is controlled using a set of commands that were customized for the application (login, configure, status, reset, execute).  The commands are all delivered via http protocol with the device acting as an http server.  Discovery is via UDP.

If anyone needs a device like this and has an interest in developing their own scheduling software please contact me.  For an update on available scheduling software, please contact me.  I can provide the software API and sample code in VB6 or .NET (.NET works with C#, C++, VB.Net).  The device can also be controlled with PHP, java,  and most likely perl.

Heres a link:

Thanks,  :wink:

Ethernet Boards (8-bit) / Re: SBC44 with 18F4525......... IT WORKS !!!!!!
« on: January 23, 2008, 07:18:32 PM »
Hi JM:

thanks  :-) for posting the adaptor circuit and the text file.

Looks like making a pcb adaptor would be fairly easy using the eagle pcb layout software and then using your adaptor files as connection guide.

Here's a plug that plugs into the plcc-44 socket:

by building the adaptor circuit board with pads that match this adaptor on the bottom and pads that match the tqfp 18f4525 on the other side it would be fairly easy to make.  After soldering this plug and the controller to the adator card would be fairly reliable, though costly, but for prototype fine.

I'm using the sbc45 and 3.06 beta 3 code.  I have 200 bytes left in rom code.  I've had to take out debug, icmp, ms networking, remove much of the http server functionality but it is working.  I'm using dhcp, minimal http server, dns, and a hacked up http client.

I'm limited to only 3 udp connections and 2 tcp connections, which is working, but I'm at the limit.

An 184525 would greatly expand application space, plus it seems from reading the data sheet that it is a generation advanced from the 18f52 in terms of power usage and reliability.

I'm developing a lot of external software for this app now, it's nice having 256MB of ram, and not 1.5kB :cry: to build software apps with!


Ethernet Boards (8-bit) / Re: SBC44 with 18F4525......... IT WORKS !!!!!!
« on: January 22, 2008, 11:39:28 AM »
Re: 18F4525
I found a PLCC-44 plug that brings all of the pins out of the socket to an exposed area allowing one to solder a pcb to connect the pins from the plcc to the 18f4525 tqfp.  The plug costs about $15.00.  Its made for prototypers.

can you post the CONFIG option changes that you had to make to get the 18F4525 working?



I don't know if this will work for you, but you can send commands directly to the sbc boards by sending an http command similar to this:

http://[ip address]/somepage.cgi?u=admin&p=pw&pincommandn=1&pincommandm=0

where somepage.cgi is a page that you develop, it could provide a status of the pins to ensure they are set because the commands in the url are processed before the page is sent back.

You have to look through the modtronix documentation to get the actual command names for the pins and for the user and password.  I believe you have to send the user and password which essentially logs you in (using the current code) before it will process I/O changes.

This will however send a page back to your server, however if you are working with say PHP on your server you should be able to send out this command, if the command is properly formatted you should receive the page back, and then you could deliver an updated page to your browser based on the results provided in the page.



>>Surely my method is not the most elegant

Your method is good, IMO.

I've implemented a variation of your method as a second watchdog timer in my application.

The first WDT, the one built into the chip, seems have a built-in time limit that seems to average somewhere less than 500 milliseconds.

If everything is working well within the application, then this might be all you need.  However, if say you are expecting a reply from a server on the Internet, and the reply never comes, or only half of the reply is transmitted and you are waiting for the other hald, you could be stuck in an infinite loop where your code resets the built-in WDT as it should, but application never returns to the main loop because it is waiting for an answer (calling stktsk() and fast user process while waiting for the response).

I'm using a variation of your timer1 method as a watchdog to protect the main loop.  So, if control doesn't come back to the main loop within, in my case 5 minutes, then something is wrong, and board resets.

So, what is better than 1 watchdog timer?  How about 2?  8-)

Thanks for posting your idea.


>>WDTCON = 0b00000001; that he is this?

This command apparently controls the operation of the built-in watchdog timer on the pic processor when the WDT configuration bit is OFF.

Specifically, this command sets then SWDTEN bit (SW WDT ENable) in the WDTCON register allowing software control of the built-in watchdog timer (WDT).

I was under the impression that the built-in watchdog timer would be enabled by default because of all of the FAST_USER_PROCESS commands interspersed throughout the code, but it appears that it is not enabled by default and you have to add the above code line in order to enable it. 

I have been getting some intermittent stoppages in my application, averaging about 1 every 7 days or so, when the application is in the main loop.  I'm hoping that enabling this timer will automatically reset the board when this happens.

If you have an especially long process you can turn the watchdog timer off with:

WDTCON = 0b00000000;

and then turn it back on with
WDTCON = 0b00000001;

when the long process is complete.  This watchdog timer is much more reliable as far as resetting under many differerent glitch causes, and so should most likely be used if possible.


It looks to me like the GetTickDiff functions within the Tick.h module of the V3.05 stack could provide unintended responses, but I'm unsure do to my ignorance of the subtraction methodology used with the PIC processor in the case of an overflow condition (ie substrating a larger number from a smaller one).

It looks like these functions simply subtract the stored Tick value (the test value) from the current tick value.

In most cases this differential would be correct.  However in the case where the tested value is closer to the rollover value than the test interval, then the differential value returned would not be as intended by the name of the function.

Here's an example use GetTickDiffSec(t) which has a range of 18 hours.

I store a time:  testTime = TickGetSec()
I want to execute a command every 4 hours, so my test interval is 14400 (4 x 60 x 60)
The TickGetSec() tick counter rolls over to zero at around 64800 (18 hours, or around there)

Lets say everything starts at zero.  For the first four iterations the function TickGetDiffSec(testTime) returns the correct differential between the tick clock and my stored time.  Every time the TickGetDiffSec(testTime) function is greater than 14400, my routine executes, and then I update the current time testTime=TickGetSec().  The 4 hour count process begins again. 

There will come a time when I store a value like testTime=TickGetSec() will equal say 57600 (4 x 14400).  The TickGetSec counter however rolls over at 64800 (or close to that).   When the TickGetSec() counter rolls over, it becomes 0, and at that point, the function TickGetDiffSec(testTime) returns ( 0 - 57600) which I presume to be some large number because of binary subtraction overflow.  The result is that the event occurs prior to 4 hours, in this case, more like two hours.

Caveat:  I'm not sure exactly how subtraction of a larger number from zero works within the PIC instructions.  I'm vaguely familiar with 1's complement arithmetic, so it could be that the situation takes care of itself.

Can anyone confirm whether the TickGetDiff functions (any tick function that returns a differential between current time and stored time) return the absolute value of the difference?   


Ethernet Boards (8-bit) / Re: bug fixed in ARPIsResolved()
« on: December 13, 2007, 07:48:48 PM »
This is just to update this old post.

The original code appears to be correct. 

If the ARP request is for an IP address not on the local network, the ARP request goes through the gateway to the Internet, the arp response will come back to the board from the gateway, and so the remote address in that response packet will be that of the gateway and not that of the original remote IP address.  The remote MAC address will however be the MAC address associated with the originally requested remote IP address.



The dns.c module is a bare skeleton.  If an address can't be resolved (old dns address, gateway down, etc) it just bounces back and forth between states and never exits.  It needs substantial modifications in order to be used in a commercial product.  But, once debugged,  it is a nice skeleton that works well if everything in the network is working like it is supposed to.

From your message I take it that the http client code posted above is free of errors and works well so I'll try that, and thanks to certeza for posting it.



The original DNS client always had the capability to connect to servers outside the local network.  Problem is that there is a bug in the code.

niroblock's solution, or workaround, will work most of the time, but he assigns the remote IP address before it has been verified, so it might overwrite a valid address and then have a subsequent dns resolve problem.  That's why the tempIP variable was used.

Here's a solution that has worked for me:

Old code:  (dns.c)

IP_ADDR             tmpIpAddr;

New Code:

static IP_ADDR     tmpIpAddr;

It other words, just declare the tmpIpAddr variable with a static.  It gets overwriten in a subsequant procedure and it's value changes from what it should be.

Hope this works for you and others.

By the way, I'm looking for a simple HTTP client, that takes up very little space (I'm working the the mx45 using the beta code that was derived from the 65 code).  It looks like your RSS feed http client is close, but it looks like it has some extra stuff in it.  I just want to request a simple page with less than 128 bytes on it.

If anyone can reccomend simple HTTP client that would be great, otherwise I'll go through the code that certeza and niroblock wrote.  Thanks for posting your code. 


Pages: [1] 2 3