Could you post your current code? If I get a chance I will load it on my N+ this weekend and have a look.

Thanks Charles,

But I found the way to solve the issue

We need to disable IP_SOF_BROADCAST_RECV define in opt.h. This a filter at pcb level to drop any broadcast.

Instead of changing the firmware, I also see that we can leave this define as it is, and enable the pcb options SOF_BROADCAST to also solve this issue. I just need to find the way to enable it at C# level.

Pascal

Just a little check. Often, installer use the EV ProgramFiles to know where it is. So, open a cmd and type : echo %ProgramFiles% You should see F:\Program Files in your case. If not, you probably found what's happen, Pascal

Look at line 45 in AT91_EMAC_lwip.h:
static const UINT32 EMAC_NBC = (0x1ul << 5); // (EMAC) No broadcast.

That's not the right direction. I'm able now, with some firmware modifications, to send debug messages to COM1. And after putting messages on ip.c and udp.c, I can see that my NetduinoPlus receive UDP even if this is a local broadcast and the EMAC_NBC register is enabled. So, I will continue to search why these broadcast are not catched by my application.

DM9161_AutoNegotiate
Valid PHY Found: 31
PHY: Vendor Number Model = 0xA
PHY: Model Revision Number = 0x0
AutoNegotiate complete
DM9161_GetLinkSpeed passed
Link detected 0x0
ip address from interface info: 192.168.5.100
.NetMF v4.1.2821.0
NetduinoPlus, Build Date:Oct  7 2010 23:03:52
ARM Compiler version 410462

TinyCLR (Build 4.1.2821.0)

Starting...
Created EE.Started 
Hardware.
No debugger!
//
Extra lines removed
//   
Ready.
IP Received
UDP Received
IP Received
UDP Received
IP Received
UDP Received
IP Received
UDP Received
IP Received
UDP Received
IP Received
IP Received
UDP Received
IP Received
IP Received 

Pascal

Curious. We'll do a clean build and play with both RVDS and GCC compilation to see if we can help make it easier...

It seems that environment variables was changed between RVDS 4.0 and RVDS 4.1.

I'm successful with both Netduino & NetduinoPlus with this setenv_RVDS4.1.cmd content :

@echo off

set RVCT40BIN=%ARMCC41BIN%
set RVCT40INC=%ARMCC41INC%
set RVCT40LIB=%ARMCC41LIB%

setenv_base.cmd RVDS4.0 PORT

Without any files move or other files modifications,

Hope can help others,

Pascal

Quite possibly. lwIP is a bit of a black box of sorts, but we can look into it.

Chris,

To be able to receive a udp local broadcast, we need to be able to receive ethernet broadcast.

Look at line 45 in AT91_EMAC_lwip.h:
static const UINT32 EMAC_NBC = (0x1ul << 5); // (EMAC) No broadcast.

It seems that MAC layer is configured to not catch any broadcast packet.

Thought ?

Pascal

Hi pascal06,

Whenever we do large amounts of code, we use the Atmel AT91SAM7X-EK (the Atmel dev board), placing an AT91SAM7X512-AU chip on it. We've specifically made the Netduino firmware compatible with the EK board so that it's possible to use the Netduino firmware with it... [You might have to tweak SPI channels or cut traces for the SD to work--but that's about it].

We haven't tried to build code within an emulator--but technically .NET MF has a Windows port (used in the .NET MF Emulator) so it might be possible...

Chris

After some research, it seems that the Emulator works only with managed code. So, it's great to simulate C# project, but it seems that not possible to use any firmeware (native code) with it,

Pascal

Quite possibly. lwIP is a bit of a black box of sorts, but we can look into it.

Please note that the emulator on Windows probably uses RTIP (the commercial stack) or Microsoft's IP stack instead of lwIP--so you may different behavior in the emulator than on an open-source .NET MF device.

Chris

Thanks Chris,

For me, the emulator use the host windows stack because the emulator is 100% written with managed code.

I have tested my program on a TAOHE-II which use RTIP, and it works.

So, my conclusion is the lwIP doesn't catch broadcast packets. I will also take a look on it.

A little question, how to see firmware debug message like LWIP_DEBUGF ....

Pascal

Hello,

Netbios name resolution can be a easy way to communicate with a NetduinoPlus. Especialy in case of using DHCP. With this feature, you can use (only on local subnet) the name of your Netduino instead of using IP address. But, it seems that NetduinoPlus doesn't support local broadcast UDP. My sample works on Emulator, but not on NetduinoPlus.

using System;
using System.Threading;
using Microsoft.SPOT;
using System.Net.Sockets;
using System.Net;
using Microsoft.SPOT.Net.NetworkInformation;

namespace Netbios
{
    public class Program
    {
        private const int UDP_PORT_NETBIOS_NS = 137;

        public static Byte[] EncodeNetbiosName(string Name)
        {
            byte[] result = new byte[32];
            char c;
            for (int i = 0; i < 15; i++)
            {
                c = i < Name.Length ? Name[i] : ' ';
                result[i * 2] = (byte)(((byte)(c) >> 4) + 65);
                result[(i * 2) + 1] = (byte)(((byte)(c) & 0x0f) + 65);
            }
            result[30] = 0x41;
            result[31] = 0x41;
            return result;
        }

        public static string DecodeNetbiosName(byte[] NbName)
        {
            string result = "";
            for (int i = 0; i < 15; i++)
            {
                byte b1 = NbName[i * 2];
                byte b2 = NbName[(i * 2) + 1];
                char c = (char)( ( (b1 - 65) << 4 ) | ( b2 - 65  ) );
                result += c;
            }
            return result;
        }

        public static bool BytesEqual(byte[] Array1, int Start1, byte[] Array2, int Start2, int Count)
        {
            bool result = true;
            for (int i = 0; i < Count - 1; i++)
            {
                if (Array1[i + Start1] != Array2[i + Start2])
                {
                    result = false;
                    break;
                }
            }
            return result;
        }

        public static void Main()
        {
            byte[] myNbName = EncodeNetbiosName("NETDUINO");

            NetworkInterface[] networkInterfaces = NetworkInterface.GetAllNetworkInterfaces();

            using (Socket serverSocket = new Socket(AddressFamily.InterNetwork,
                                                    SocketType.Dgram,
                                                    ProtocolType.Udp))
            {
                EndPoint remoteEndPoint = new IPEndPoint(IPAddress.Any, UDP_PORT_NETBIOS_NS);
                byte[] IP = IPAddress.Parse(networkInterfaces[0].IPAddress).GetAddressBytes();
                serverSocket.Bind(remoteEndPoint);
                while (true)
                {
                    if (serverSocket.Poll(1000, //timeout in micro seconds
                                               SelectMode.SelectRead))
                    {
                        byte[] inBuffer = new byte[serverSocket.Available];
                        int count = serverSocket.ReceiveFrom(inBuffer, ref remoteEndPoint);
                        if ((inBuffer[2] >> 3) == 0) // opcode == 0
                        {
                            byte[] nbName = new byte[32];
                            Array.Copy(inBuffer, 13, nbName, 0, 32);
                            Debug.Print("NETBIOS NAME QUERY: "+DecodeNetbiosName(nbName));
                            if (BytesEqual(inBuffer, 13, myNbName, 0, 32))
                            {
                                byte[] outBuffer = new byte[62];
                                outBuffer[0] = inBuffer[0]; // trnid
                                outBuffer[1] = inBuffer[1]; // trnid
                                outBuffer[2] = 0x85;

                                outBuffer[3] = 0x00;
                                outBuffer[4] = 0x00;
                                outBuffer[5] = 0x00;
                                outBuffer[6] = 0x00;

                                outBuffer[7] = 0x01;

                                outBuffer[8] = 0x00;
                                outBuffer[9] = 0x00;
                                outBuffer[10] = 0x00;
                                outBuffer[11] = 0x00;

                                outBuffer[12] = 0x20;
                                for (int i = 0; i < 32; i++)
                                {
                                    outBuffer[i + 13] = myNbName[i];
                                }

                                outBuffer[45] = 0x00;

                                outBuffer[46] = 0x00; outBuffer[47] = 0x20; // RR_TYPE: NB
                                outBuffer[48] = 0x00; outBuffer[49] = 0x01; // RR_CLASS: IN

                                outBuffer[50] = 0x00; // TTL
                                outBuffer[51] = 0x0f;
                                outBuffer[52] = 0x0f;
                                outBuffer[53] = 0x0f;

                                outBuffer[54] = 0x00; outBuffer[55] = 0x06; // RDLENGTH

                                outBuffer[56] = 0x60; outBuffer[57] = 0x00; // NB_FLAGS

                                outBuffer[58] = IP[0];
                                outBuffer[59] = IP[1];
                                outBuffer[60] = IP[2];
                                outBuffer[61] = IP[3];

                                serverSocket.SendTo(outBuffer, remoteEndPoint);
                            }
                        }

                    }
                    Thread.Sleep(100);
                }
            }
        }

    }
}

To test this program, run it on emulator and try to ping NETDUINO with a computer connected on the same subnet.

Is it possible to change the configuration of lwIP to support udp local broadcast ?

Pascal

In theory yes,

You need to check if a shields doesn't use the same pin as another ... Look at schematic of each shield,
And some shield are designed to be the last shield, like lcd,

Chris is the winner,

Pascal

Why the ARM compiler provided with Embedded Compact 7 is not supported by .NET MF ? There is certainly a good reason, Just curious, Pascal

Hi Pascal,

What are the pinouts you used to interface between the netduino and the 3310 lcd?

PipZ

Hello PipZ,

I use the nuelectronics shield, pinouts can be found in this schematics:
http://www.nuelectro...ia_3310_lcd.pdf

Strip the joystick part, it's not compatible with netduino due to 3v3 vs 5v.

Pascal

Hello, To simplify developing and debuging of some piece of firmware, I imagine to use the emulator. Due to very constrained environement, the price of RVDS, the size of code generated by GNU G++ and the size of debug information, it would be great if I can write/test/debug my native code with emulator before. As a example, for a IP stack , instead of using socket level with emulator, is it possible to strip this part, write a driver for WinpCap, and work on code between socket assembly and this driver with emulator ? Anyone have experience on this ? Any comments appreciate, Pascal

I´m planning build Netduino from scratch (board, solder)
I have a question.
How to burn firmware in processor?
Thanks

If you realy want to start from strach (good luck to solder the MCU ), you need to use SAM-BA tools from ATMEL to burn the TinyBooterDecompressor.bin first :
http://www.atmel.com...sp?tool_id=3883

After, you can use MFDeploy to burn the firmware,

Good luck,
Pascal

Great idea, thanks to work on it ... Very interested for Netduino Plus ... Pascal

Yes, the default gateway address means your router's address ... When your Netduino need to communicate with a destination address not in your subnet, it will send this packet to this address by default. If no other static route in Netduino match this destination. But in your case, you probably not need to specify any other static route. Pascal

I have the same experience, I can see the first ARP request, but no retry (after waiting 30 minutes ). A IP stack must retry after a timeout, and after multiple requests it must generate a exception. And it's not the case, like a infinite timeout after the first request. It's probably a bug. Pascal

I've just found out that by default the netduino plus is responding to icmp(ping) requests..

Is this the only default behaviour of the network stack? or are there more services that run?
And.. can I disable this behaviour?

This is the default of all ip stack without firewall. This is true for any kind of network product.
Why you want to disable it ?

Pascal

Hello Szymon, ATMEL provide very nice and sheeper chip for 802.15.4. I personally use AVR-RAVEN DevKit. But 802.15.4 is only for layer 2. 6lowPAN is a IPv6 stack which can work over 802.15.4, because it change header of IPv6 by a compressed version. So, with 6lowPAN, you must use IPv6. What's the relation with uIP ? uIP is the smallest IPv6 stack and it's certified by "IPv6 ready". lwIP is not certified, bigger and only experimental. Now, why we need IP and why is better than other wireless technology. A good start for this reflexion would be IPSO Alliance white papers : http://ipso-alliance.org/ Hope your help, Pascal

I have downloaded the zip file of the Netduino board. The file type is .BRD and I would like to know how
to open this file. I tried to use Eagle with no luck.

Any enlightenment will be appreciated.

Vic

Hello Vic,

Here is a answer from Chris:
http://forums.netdui...rd-layout-file/

Pascal

Hello Netduino Community, Some information about uIP, uIP is a very small open-source TCP/IP stack written by Adam Dunkels from Swedish Institude of Computer Science. Same author as original lwIP. This stack can run also on 8 bits MCU. The official uIP web site: http://www.sics.se/~...x.php/Main_Page This site is dedicated to the first version uIP and it support IPv4. In parallel, Adam Dunkels work on a mini OS named Contiki: http://www.sics.se/contiki/ In this mini-OS, you can see a more up-to-date version of uIP stack for IPv4 and IPv6. This stack is IPv6 ready. Compare to IPv6 support on lwIP which is experimental. It doesn't support Dual Stack, so you need to choice between IPv4 and IPv6. uIP can be used without Contiki. Here is a example of porting IPv6 uIP on Arduino without Contiki using a enc28j60 chip: http://sites.google....ipv6ethershield A little question to Netduino Community : What's your priority regarding porting IPv6 or IPv4 ? Regarding this, one very important information: If you plan to use low-power wireless like 802.15.4, IPv6 can be a good choice because of 6lowPAN. 6lowPAN use header compression to be compatible with 802.15.4. The dream is to be able to communicate with all devices, wire and wireless, simply by using IP. IPv4 over 802.15.4 is impossible due to low MTU size of 802.15.4 frame. Pascal

Excellent video, Thanks for sharing, When I work with serial port and programming, I use this powerful free tools: http://www.der-hammer.info/terminal/ Pascal

And, I don't know why, the device capabilities function on MFDeploy reply Not Supported (any idea ?),

Forget this remark, I have tested this function with TinyBooterDecompressor only , with no firmware,
It works know,
Pascal

Please have a look at the following post which contains updated blockrange for GCC 4.4. The *GCC_SPECIAL* symbols are used to differentiate the block range layout between GCC and the other compilers - when compiling with GCC, there is more blocks for bootstrap, because the generated code is twice as big.

Many thanks,

I'm finally successful with a firmware and TinyBooterDecompressor compiled with GCC 4.2.
And a simple blink led application works. For some of you, it's not a huge step, but for me, it was a long way.

But I have only 32k for C# project Without any new firmware feature.
And, I don't know why, the device capabilities function on MFDeploy reply Not Supported (any idea ?),
When I will have time, I will write a little document with my experience, because my feeling is that we don't have enought document about that, it's not realy trivial. Perhaps a little tools to manipulate both files needed to modify would be useful.

Thanks again,
/pascal

How can I detect the firmware version on my Netduino board ?

Thanks,
Paolo

Using MFDeploy.exe, select USB -> Netduino_Netduino, in Menu Target -> Device Capabalities,
The "SolutionReleaseInfo.solutionVersion" show the Netduino firmware version,

Pascal

Yes, each block is 8KB. There are 64 blocks total (8KB * 64KB = 512KB).

Does that help at all? It sounds like you had already figured that out though...

When making firmware modifications, we typically compile the image--and then measure the size of TinyBooter (using SAM-BA) and the size of TinyCLR (using MFDeploy). Then we re-adjust the block layout, recompile (with /t:rebuild), and reflash.

Chris

Thanks Chris,

And :
BLOCKTYPE_BOOTSTRAP = TinyBooter size
BLOCKTYPE_CODE = TinyCLR size
BLOCKTYPE_DEPLOYEMENT = Free memory for managed code size

But what's both *GCC_SPECIAL* blocks ? Do I need to change his size, and if yes, based on what ?

Many thanks,
Pascal