hi all. I've got my webplatform but can't get it to connect to my network. I can flash the firmware based on the various ones available on the svn server, but none of them seem to work.
I think i've seen as far as some dhcp traffic from the device, but I couldn't tell you which firmware it was.
Can anyone point me at a hex file that's known to work, or any other things I can check?
Cheers
S8.
p.s. I can run it powered from the usb assuming I have the jumper correct, right?
Hi S88,
Thanks for the report. Sorry about the issues with the web platform.
Yes, with the jumper you can power it from USB. If it is blinking it is powered and working.
Is DHCP enabled on your router/network? The web platform acquires the IP address dynamically.
The latest good firmware is in the package here:
http://code.google.com/p/dangerous-prot ... rm.v0a.zip (http://code.google.com/p/dangerous-prototypes-open-hardware/downloads/detail?name=web-platform.v0a.zip)
What tests have you tried so far? Have you tried the dhcpdetect app - you should see the announcement packet with the web platform restarts.
Thanks for your help.
I've downloaded and flashed that firmware. It hasn't made much of a difference.
I can tell from my router that the mac address of the card appeared and got assigned an ip address
(00:04:A3:00:10:05 192.168.0.45). The activity led does blink occasionally as well, so its seeing the network for sure. My network uses a 255.255.255.0 mask.
However, I can't ping that address (destination host unreachable) nor can I connect to it via the browser.
(00:04:A3:00:10:05 192.168.0.45)
The MAC (first part) looks correct. The IP is good news too.
Is there a firewall between you and the web platform that stops your pings? Could be a windows firewall, or a router not allowing local traffic.
There is a small program that can detect the announce packet, could you please try running that on a PC while the web platform starts. It should receive a packet with all the network settings:
http://code.google.com/p/dangerous-prot ... Detect.zip (http://code.google.com/p/dangerous-prototypes-open-hardware/downloads/detail?name=MCHPDetect.zip)
http://dangerousprototypes.com/docs/Web ... P_announce (http://dangerousprototypes.com/docs/Web_platform_firmware#DHCP_and_IP_announce)
Which operating system are you using? Windows, Unix, OS X?
No, there's no firewall in the way. The MCHPDetector doesn't show anything other than the "waiting for data..." message.
I have win 7, winXp and os-x
I should note that the leds on the network jack aren't lit. Should they be? I've tested the network cable on another machine and it seems ok.
is there anything i can check to confirm/disprove that its dying after doing dhcp but before the broadcast?
The jack LEDs are not connected, but the two LEDs at the front are the same thing.
is there anything i can check to confirm/disprove that its dying after doing dhcp but before the broadcast?
If the stack is working, the LED should blink about once per second as a 'heartbeat'.
It looks like there should be a UART echo in that firmware:
http://dangerousprototypes.com/docs/Web ... #UART_echo (http://dangerousprototypes.com/docs/Web_platform_firmware#UART_echo)
If you open a serial terminal to the USB serial port, it should echo any characters you type. This would show the the processor is still alive.
If there is no heartbeat (see LED LD1), then you'll need to re-compile as per the docs on the Wiki.
See http://dangerousprototypes.com/docs/SD_ ... erver_demo (http://dangerousprototypes.com/docs/SD_card_web_server_demo) for details.
A quicker test would be to download my HEX file from the forum post at:
viewtopic.php?f=24&t=1486#p13827 (http://dangerousprototypes.com/forum/viewtopic.php?f=24&t=1486#p13827)
Note: The http port has been moved from 80 to 81 in this version. If you connect to the USB port virtual com port, you should see the names of the files being accessed (assuming you get that far).
Anyway, if it works, then you will definitely need to recompile the example following the Wiki docs. If you need the superseded C30 version 3.23 (there seem to be problems compiling the stack with versions after that, though I've not tried the very latest), PM me.
ok, so the heartbeat is happening. The firmware I had wasn't echoing properly. It was giving a lowercase y with umlouts for every character.
With the hex file that Trev suggested things are a bit better. It does echo characters and does respond to a ping. Still nothing when accessing it via the browser, though.
Might be time to check that the sd card I have is formatted correctly.
Sorry was wrong about the ping working. Its still not, although the terminal echo is ok.
So, the web platform is alive. Good news :)
1. Is the web platform LNK LED lit?
2. From an OS X console terminal, ping the IP address of the web platform. Does the web platform ACT LED blink?
3. From an OS X terminal, what does "arp -a" show?
The link led is lit.
Pinging the ip address does cause the act led to flash. It does flash occasionally without it, but presumably that's just other broadcast traffic on the network. There's a noticeable increase during a ping.
the mac address and ip address doesn't show up in the computer's arp table.
Its also NOT in the arp table on the router, just in the DHCP.
This rather points to the idea that the board isn't processing network traffic at all after the dhcp. Is the code threaded in such a way that this is possible and the echo & heartbeat are still working?
Grasping at straws... try adding an arp entry for the IP and MAC addresses in an OS X terminal:
arp -s 192.168.0.45 00:04:A3:00:10:05
and then seeing if you can ping the web platform.
The software architecture for the web platform is the cooperative multitasking model.
Is the code threaded in such a way that this is possible and the echo & heartbeat are still working?
I think Trev beat me to it, but yes, that is possible. The echo is and 1hz LED blink are part of the main software loop, the TCPIP stack is also serviced from there.
It could be helpful to see what (if any) packets the web platform is putting out with wireshark.
Some interesting things showing up when I look at the network traffic with wireshark....
Remember, my network is set up as a /24. ie 192.168.0.* with a mask of 255.255.255.0
I see a number of DHCP requests (DHCP Discover and DHCP Request). I then see a DHCP Offer packet from my router setting it to 192.168.0.80.
What I don't see in there is a DHCP Ack packet.
I also then get an ARP packet from the webserver "who has 192.168.1.2, tell 192.168.1.100". Those numbers should never even occur on this network. I'm going to guess that these are the defaults for the firmware. Can anyone confirm?
So it looks like its not processing the dhcp offer properly and setting the local ip and netmask.
The .1.x is the default from the firmware:
http://code.google.com/p/dangerous-prot ... IPConfig.h (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/Web_Platform/firmware/MCstack-SDcard-server/TCPIPConfig.h)
well, I guess the next step is to see what happens if I move myself to a 192.168.1.x network
For some reason DHCP from your router is not working and the web platform is falling back to its static IP addresses. These are the defaults in my firmware (if you're still using it):
255.255.255.0 - mask
192.168.1.100 - web platform
192.168.1.4 - gateway
192.168.1.2 - DNS server
yup, got it working today by switching myself over to a 192.168.1.* network.
Its also working fine with the MCSDServer firmware from the svn repository.
going to look at the code to see if i can spot why the dhcp doesn't work correctly.