NETMF / netmf-interpreter

.NET Micro Framework Interpreter
http://netmf.github.io/netmf-interpreter/
Other
487 stars 224 forks source link

STM32F4 discovery board + extension board(STM32F4DIS-BB) #385

Open pilidj opened 8 years ago

pilidj commented 8 years ago

Hi all,

I have succesfully compiled the binaries of NETMF. I have these two boards in the title. I would like to connect my USB weather station WMR88(usb HID protocol) to the discovery board and transform usb packets to ip packets to manage my weather station since the web. The method getallnetworkinterfaces doesn't work. The STM32F4DIS-BB board uses a PHY LAN8720 that is not implemented in drivers of NETMF. Have you any support on this? Can I find examples on how can I use sockets in .net microframework? I don't find system.net.sockets namespace under NETMF.

Thanks.

SytechDesigns commented 8 years ago

Hi, In general the phy initialisation just uses the 'standard' registers and not any 'custom' registers specific to a particular phy - so in principle any phy will work - but.. If you look in ..Stm32F4\DeviceCode\STM32F4_ETH_lwip_OS\STM32F4_ETH_phy.cpp you will see that the code is really specific to the horrible Keil board and whether it is a rev1.1 or 1.2 board ( different phys - one that wont connect properly at 100m). So in findphyAddr() it reads the PhyIdent register and looks for a return value that is assigned to either of the two phys used on the keil board. So if you have the LAN8720 you will get a different OUI id - so the variable g_foundPhyAddress will not be set as true - so other functions will now fail. To make this work you need to add the OUI for your phy to the .h and extend the test or result to phy1 || phy2 || phy3. For the future this needs to be made more generic to support any phy, or read the OUI from the solution config file. Incidentally phy address 0 is generally defined as a broadcast address, so all phys will normally respond to this, despite their real address setting so a found phy address will always be reported as 0 by this test, as this is the first address tried - but as its the broadcast address, this will work with most phys.

The other key thing is whether the phy interface is MMI or RMII - this needs to be set in the solution platform settings file, but the expansion board uses RMII like the keil board.

A quick look in the sample lwip app code that comes with the expansion board, shows that they force the board to connect 10M not 100M - so either the phy does not support 100M or like the rev1.1 Keil board its not reliable at 100M, also the code shows that the phy address is 0x01 on the exp. board.

The use of Sockets in a managed app is by far a much easier thing to work out. A quick google or maybe the project code examples on either the GHI or Netduino forums should produce some sample code

If you do get a solution building and working for this I would be interested in seeing the solution project source.

Regards

pilidj commented 8 years ago

Thanks for your precious help. I've added the socket.dll reference to my project to get the system.net.sockets namespace. It's a little bit different from the classic Framework because System namespace is automatically included when you create a project. So if I understand the phy can not work at 100mb actually? If it works at 10mb speed it doesn't matter. I've change pinning for the phy and added the OUI ID. I also seen that the interface type is RMII so I have no change to do on this side. What I don't understand is when you say the phy address is 0X01. Where (what file)do you see that? and "Incidentally phy address 0 is generally defined as a broadcast address"?

Also how can i debug or emulate the native code? Because It is a little tricky to compile the binaries every time and flash it to test it.

I would like to use SD card slot eventually to store data. Is the pining is compatible? I'll post the source code when it will work because sharing is important for the community.

Regards

pilidj commented 8 years ago

sorry I've clicked on the wrong button.

SytechDesigns commented 8 years ago

Hi, In general with phys there is a control register that you can use to set the phy address, but you can also use pullup/pull downs on various pins ( phy dependant0 that get the levels latched during rest to configure the address on reset, allowing faster setup. In general yo only want to change the phy address if you have multiple phys connected to the same processor mac. Problem with this is, if the address is set by hardware, how does the software know the address? So to get round this address 0 is usually a 'broadcast' address, meaning no matter what the phy address is set to ( say 0x01), you can still read the internal phy addres register ( or any other) using address 0 - i.e the phy will respond to address 0 or its hardware/register set address. On the Lan8720 the pin is rx_error - and on the expansion board this is floating, so will use the internal pull down resistor which will latch phy address 0 ( the default),

The code I was referring too, about using address 1 and only 10m speed, was the example code for the expansion board from embest ( which is a modified STM example code for another board). However I was quickly looking at it with a text viewer, and in fact the lines forcing it to 10m mode were actually commented out! I quickly compiled the project and loaded it into a disco board + exp ( I also enabled dhcp in the code) and quickly tried it out. It does work and gets a dhcp address assigned from my router and I can ping it and it it is working at 100m full duplex.

So forget what I said about it 10M - it does work fine at 100M

According to the data sheet phy ident reg 1 (0x02) has an OUI of 0x7 So if in STM32F4-ETH_phy.h you can change the value of PHY_KENDIN_OUI_ID1 to 0x7 or Add a new constant for Lan8720 OUi ( and add to the findPhyAddr() function test line so that it also checks if the OUI is the Lan8720 OUi as well as the ST802 or the KSZ phy it will find th phy address.

In the autonegotioation function eth_enableAutoNegotitiation() it will read the phy ident reg and if it is not an ST802 will auto negotiate at 100M.

Sorry there is no short cut to build and flash. As for debug - I can only speak for MDK and uvision. If you set up a dummy project ( see the keilboard etherent project solution for example) you can debug using uVision - in theory using the stLink built into the disco board - but on my set up this is broken now, due to mismatch of the st link firmware versions - and I havn't had time to fix it - but it used to work. Easier way is do a debug build, connect to MFdeploy over usb, select device connect, then in mfdeploy- plugin-debug select reboot clr - then clr will restart and debug messages will be displayed in mfdeploy (not that manner - but its a start)

If you have a solution for this building, could you stick it on dropbox or something - so I can download it and have a look?

regards

pilidj commented 8 years ago

Hi, I have CLR_E_NOT_SUPPORTED exception when I call new socket constructor... Same thing with getallnetworkinterfaces. Any ideas??

smaillet-ms commented 8 years ago

That would suggest that the networking libraries aren't included in your device firmware. Check you platform's TinyCLR.proj file to be sure you have them included. You can use the MCBSTM32F400 as an example as it has networking support along with a variant without networking for easier comparison.

pilidj commented 8 years ago

Hi,

I've successfully built project with networking stack but without ssl support. But now on new socket constructor I have CLR_E_FAIL error. I think I must rebuild project with /p:flavor=debug to see debug messages in MFdeploy...

pilidj commented 8 years ago

Very helpfull!!

Pinging... TinyCLR Connecting to STM32F4DISCOVERY_a7e70ea2...Connected

Exception System.Net.Sockets.SocketException - CLR_E_FAIL (1)

#### Message: 
#### Microsoft.SPOT.Net.SocketNative::socket [IP: 0000] ####
#### System.Net.Sockets.Socket::.ctor [IP: 001f] ####
#### Test.Module1::TestLedRoutine [IP: 0036] ####
#### Test.Module1::Main [IP: 0010] ####
#### SocketException ErrorCode = -1

The output in MFdeploy is inefficient!

Here is the source code: `` Private Sub TestLedRoutine() Dim RedLED As New Hardware.OutputPort(Microsoft.SPOT.Hardware.STM32F4.Pins.GPIO_PIN_D_15, False) Do Try Dim adapters As Net.NetworkInformation.NetworkInterface() Dim adapter As Net.NetworkInformation.NetworkInterface adapters = Net.NetworkInformation.NetworkInterface.GetAllNetworkInterfaces()

            For Each adapter In adapters
                adapter.EnableDhcp()
            Next

            Dim Client As Socket

            Client = New Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp)
            Client.Connect(New IPEndPoint(IPAddress.Parse("192.168.1.1"), 80))
            Client.Send(Encoding.UTF8.GetBytes("hello world"))
            Client.Close()

        Catch ex As SocketException
            RedLED.Write(True)
            System.Threading.Thread.Sleep(15000)
            RedLED.Write(False)
        End Try
    Loop``

What can I do with that?