Before I get excited does this: 1) fix the usb deployment that fails and blue screens the machine. 2) contain the missing math functions like math.pow(x,y) which previously threw a wobbly with not implemented exception.

Hi DrJaymz,

Are you using the NETMF 4.2 beta drivers on your computer (the unsigned ones)?

Chris

Indeed I am, it doesn't say netduino - its something reference board.

I've ruled out current consumption and tight timing loops on the netduino itself.

Upgraded my code to 4.2 RC4 no operational problems noted with execution. The missing FP operations seem back and the values are correct. Deployment still fails after a couple of debug executions, the problem is a bug in the bootloader on the netduino not with the driver on the PC. Once the deployment fails, there is no way to gain control of VS. If you remove the USB the machine blue screens. End task then remove and reconnect works. This is the bug nobody seems able to fix still after all this time? I know this because it still in the stuck state after removing the usb connection and reconnecting without resetting the board.

Hi DrJaymz,

With the .NET MF 4.2 beta firmware, there are a few known bugs. The new emulated math library has a few missing or mis-calculating routines. There are a few networking and driver glitches. These are all being worked on, to make the production 4.2 firmware as high-quality as possible.

If you're looking for stable firmware and repeated-start-bit, perhaps you can try the v4.1.1 beta firmware (which is more or less release quality--we just haven't stamped it as such)? We have created an I2C wrapper which will let you do repeated start bit with it as well.

Sorry for the troubles with the beta firmware,

Chris

Thanks for your reply.

Well OK, I got miffed with it and went to the pub instead. I have posted the problems I had with it anyway so that someone can fix them in due course.

If I use the 4.1.1 firmware where is the *current* beta release and can I keep my 4.2 SDK and change the target to 4.1 in VS? If this is the case how do I use the repeated start functionality out of the available functions - is there an example of this? I guess I was lucky that all my other I2C went so smoothly but it means I didn't learn anything! So far I have not had a bean out of the Melexis Temp Sensor.

On a positive note, with the shipped firmware, I frequently got a lock up when trying to debug some code. It would get stuck on the deployment part. I would then force it with a remove and reinsert which would then make VS go nuts with a null reference error and then another error (hardware), following that it worked. When I updated to 4.2 this lock up did not occur once, but deployment was a little slower.

I tried this update to fix my issue with the I2C and repeated start. It did not fix my repeated start issue and I noticed the following.

• system.math.pow(x,y) is not implemented, which is a pain because I cannot easily implement this another way.
• (float).tostring(f2) gives a result like 1.0000 regardless of the argument placed in the tostring.
• port.read is working in an inverted manner for some reason.

Am a bit peeved to be honest.

Hello all,

Just wondering if there is any eta on the 4.2 firmware? It's a little frustrating the number of NotSupported exceptions that are in the production release. I've tried flashing RC3 a couple of times now but I can't seem to get it to work, always results in an error to the effect of 'cant find entry point' after flash with MFDeploy and VS just bombs out with CNC_ENTRY_POINT_SOMETHING when trying to deploy. anyone happen to know a fix?

I'm hoping RC3 is going to be just around the corner as it will save me a load of coding for even a basic network device, but looking at some of the open issues that seem's unlikely

Thanks,
Jamie

There doesn't appear to be any roadmap for this development so I guess you are stuck with 4.1.1 for now. As for your error, did you fully erase the firmware? It might be that the bootloader is pointing to the wrong address and thus it cannot execute your program.

Hi DrJaymz,

You can use the new 4.2 beta drivers with 4.1 if you'd like.

If you want to free up the space used by Ethernet, erase your Netduino Plus (using the gold ERASE pad) and then reflash it with the regular Netduino firmware. You'll need to add one line of code to enable the SD card slot...but otherwise you'll be good to go.

Chris

Ok, I changed the driver with the instructions, and it no longer comes up with a netduino device, it comes up as a reference board. But the result is the same.

I agree with other comments I have read it seems to be a memory leak - works fine until about 4th deployment then boom.

I have successfully managed to use this and get the repeated start bit working with my Melexis temperature thing as well as coexist with a few other things. I loose my temper with it a bit with a 1 in 3 chance that deployment will freeze up. Sometimes you can unplug and replug the device and it will just say failed and then you can hit run again. Sometimes that will blue-screen the machine screwing things up in a big way. I have found that on freeze its best to end-task VS2010 and then replug the device. This does not bluescreen. Is there an alternative driver for the netduino? I suspect this is due to a bug in the driver a hardware issue would not bluescreen the machine. I cannot go backwards because I need repeated start bit and I cannot go forward because the 4.2 firmware doesn't work for me, has functions that don't work or is missing functionality. Finally, how to remove the ethernet when not needed the release says 'users can now do this' somehow.

Hi DrJaymz,

You can use the new 4.2 beta drivers with 4.1 if you'd like.

If you want to free up the space used by Ethernet, erase your Netduino Plus (using the gold ERASE pad) and then reflash it with the regular Netduino firmware. You'll need to add one line of code to enable the SD card slot...but otherwise you'll be good to go.

Chris

Which download do I need for the driver? Is it the one in the post for an update of the beta driver? Its a real pain because it really slows development and debugging because its crapping out a lot. I didn't notice the problem so bad when my app wasn't multithreaded.

Has anyone got this working yet? I am using a Melexis MLX90614 IR Thermometer and I cannot get it to respond to a read from 0x07. I don't understand what the internal address register and size fields mean in this context. I have other devices on the I2C bus responding correctly, and I have pullups etc. I just cannot get a bean out of the MLX90614. I'm running 4.2.0.0 RC3. With the other devices I wrote to the device telling it what I wanted then do a read. Can I do only a read transaction? I'm about to give up on this.

I am using NetworkChange.NetworkAvailabilityChanged to detect if it is available, the callback contains if it is or not connected, but there is no way I can see to determine it on startup. i.e. if I pull the cable in or out I can tell the status, but on startup I can't tell. Anyone else got a solution?

Hey there,

Do you think you can find a similar working Baud rates, etc for the same chip but with GFX?

I cannot make it work for some reason, don't know why.

I don't know anything about the GFX implementation, but I do know that its sensitivity is down to the limitation of the chip they are using.

The way I set the new baudrate seems to do the trick and it doesn't seem too sensitive to the actual baudrate.

OK - here is the answers - hopefully its of use to someone.

When using the Netduino with the Picaso SGC neither of them operate at the correct baudrate - so I wrote a program that used trial and error to work out what the settings should be.

For 115200 bps (0x0D) the netduino serial ports peed should be set to 113250.
For 256kbps the netduino serial port speed should be set to 260900.

Then it all works dandy. So even if the Picaso was operating it the correct published speed it is unlikely that it would have worked anyway.

also change it like this:

                SetBaud(0x0F); //256K
                ChangePortSpeed(260900 , portName);
                Thread.Sleep(500);
                port.DiscardInBuffer();
                port.DiscardOutBuffer();


where: 


        private bool ChangePortSpeed(int baudrate, string portName)
        {

            Debug.Print("New Port Speed " + baudrate.ToString());
            if (port != null)
            {
                port.Close();
                port.Dispose();
            }

            port = new SerialPort(portName, baudrate, Parity.None, 8, StopBits.One);
            port.Open();

            return true;
        }


/// <summary>
        /// tells the display to go to new baud rate
        /// </summary>
        /// <param name="Baud">parameter for baudrate see data sheet</param>
        public void SetBaud(byte Baud)
        {
            var bytes = new byte[]
                            {
                                0x51, // cmd = B
                                Baud
                            };
            Write(bytes);
        }

Basically you will have to forget the response byte on baud change, but the next command is fine - I have set up a read response with a timeout so if it is not ok then I will know. There isn't a NOOP or equivalent.

Can we set this thread to -SOLVED and include details of the 4DSystems SGC so that others can find it?

Does anyone know what baudrates are available with the netduino and what their bitrate errors are? Despite the .netMF functions for creating serial ports, the rates are not infinitely variable. I am trying to talk to a device that should be 256kbaud and its actually 282,393 and I wanted to know how close I could get to that rate. Failing that I should be able to find some happy medium somewhere above 128k. I have had a look at the Atmel datasheep and its not that useful without knowing exactly how it was implemented on for .net. For example, you can specify exactly how the input is sampled, in my case a single sample would probably work where multi-sampling probably wouldn't. Thanks if anyone knows.

You'd probably need to check the current implementation in the source code, namely AT91_UART.cpp. Unfortunately, oversampling configuration is not supported in the managed wrappers (SerialPort class). Please note COM1 is in fact Debug Unit, which has limited features (compared to 'full' USART module), as described in the datasheet section 26.4 DBGU UART Operations.

Ok, depending on if you can divide it 10 and the remainder is more than 5 it divides by 10 and adds 1. But it does look like it more or less just passes an int in for the baudrate in hz. I did look at the datasheet for this, but doesn't really help.

At the bottom, there are two functions, BaudrateBoundary and IsBaudrateSupported.

I will try to get something on the scope and we can see whats actually going on then.

I am having issues talking to a 4DLabs SGC display using the picaso serial interface. This is the issue. You talk to it at 9600 and then tell it you want 256k baud. It then changes and now you get 256k. The problem is that to change the baudrate on the netduino you need to close the port set the new rate and open it again. This causes a level change and results in the picaso interpreting that as a start bit and completely messing the whole thing up. I can prove that you need to close the port because the driver has a check for m_portopen and throws invalid operation if the port is open. Why is this the case, you can change the baudrate on just about anything else without having to do this? Surely its a case of updating the baudrate generator register and it should work - though I don't think that is possible from managed land. So, when the port is open the idle state is 1, when its closed is it 0 or floating? If it is floating then I can bodge it with a weak pull-up? Or perhaps anyone can tell me if they have closed and opened the port and it does in fact function at all after being closed? Its driving me up the wall because these are my last ideas, after which its probably game over for this project. That and the fact that I am really getting sick and tired of deployment failing after 4 or so deployments and then blue screening windows - make me wish I hadn't started with the netduino. Nobody seems to be able to fix it. If I find a solution to the 4dLabs I will remember to post it here as most people don't bother to update a forum when they fix something!

Update - I have tried closing and opening the port at 9600 and I do not loose the connection with the display. So thats all fine and no pull ups are needed. I found port.close followed by dispose, then new port at 9600 worked, where close then new baudrate and then open didn't seem to. But it has come to my attention that the SGC slave controller has an implementation of baudrate that has rounding errors in it probably as a result of how they have implemented it. Which sounds a bit like they are bit banging. Here is my discussion with 4D http://4d.websitetoo...post?id=5734058 I have tried incrementing the baudrate in a for-next loop to find the actual rate it is talking at but I cannot get communication above 9600 with the display. At this stage in my investigation, when I open the serial port I supply an integer for the baudrate - but how does the baudrate generator work on the netduino? I would imagine it is not infinitely variable, and that there is a list of available rates somewhere that fit the internal generator scalers. My next thing is to get a scope trace from the display when it thinks its at say 115200 measure the bit period and try to find a compatible rate on the netduino. I am sure that a few other people would find this work useful once we find the magic rates! For 256kbd the actual rate is 282353bd but if I set that with the netduino it doesn't work. Without a scope I can't do anything other than trial and error - but I will have a DSO Quad next week to investigate it further.

Have you tried the .NET MF 4.2 beta drivers yet?

Tried RC3 and it was hopeless, I may try RC4 later on - is there any change with the deployment? It is really tiresome when you are trying to debug something and then deploy fails after 4 or so goes. I have found the only way to avoid blue screen is to end-task on visual studio and then remove and replug the netduino then restart Visual studio.

I know its the netduino that is the problem because if it has its own 12V supply, replugging the USB doesn't help i.e. it has not been reset by power cycling.

Hi
As far as the BSODs go, the only time I ever get them is if I reset the Netduino while Visual Studio is doing the deployment.
For me it is a golden rule, cancel a deployment via visual studio before cycling power to the netduino.

To be pedantic it is not the Netduino hardware itself causing any BSOD but it is the USB driver.

There is another thread where we discussed failed deployments that may help. Stuck Deployments

You are right about the 12v supply, I think the power cycle is critical sometimes.

I have tried quite a few embedded technologies and they are all full of compromise, the Netduinos compromises in particular are a little different than most.
but so are its advantages,

As far as your serial port problem goes, have you considered a hardware solution. Such as using a logic gate to hold the line how you want it.

eg.

Using a 2 input gate: one input is the Tx line; one input is an IO pin, that we could call enable; one output goes to the LCD.

Would that work?

I cannot cancel deployment withing visual studio it hangs. No matter how long you wait. The other failure mode is where it says deploy failed in the status bar and then visual studio won't respond to the mouse anymore. In this case you can only end task it. If you pull the usb you will get a BSOD, thus the only thing you can do is end task. Once in this state, if you keep the board powered and remove the usb connection, and plug it back in, the device isn't recognized, thus I have just proved that whatever is going on in the atmel, it is not in the correct state. At this point the driver has been reloaded - thus its not the driver per-se, though the driver could be responsible for putting it in this not allowed state.

I am all to familiar with compromises in the world of development, I still remember the various bodges for 8051's. I have BSOD my machine before when writing USB Hid devices in assembler - but I don't really expect it in this case. I have considered using a VM for this work but the whole point of the netduino was to enable me to be lazy.

The gate idea, did cross my mind or simply a pass transistor, but I think I proved that the transition wasn't the problem by demonstrating that it doesn't occur when closing and opening again at the same speed and the communication remains unaffected.

Yes, understand, but it will not let me. I'm running XP 32 bit.

I clicked uninstall driver

Then let it install it again.

then just now it worked.

There must be something iffy with the driver caching or something - but I rebooted the VM and changed my LED blink rate just to check, rebuild and deploy - it works fine. Now back to my original issue - I couldn't work out the PWM syntax as usual the MIcrosoft help file says exactly what the function name is and that it has parameters such as duty ratio, but doesn't bother to tell you what units they might be. Really I want to start a PWM signal 10k bananas with a duty ratio of 50 pears. On say D5. Just to add to the confusion, I saw a number of questions in the forum about this and they were using the secret labs definition of PWM and were told not to use the SPOT ones. If people were using the SPOT function then PWM_0 doesn't relate to any pin so I never did get a straight answer to this.

Hi DrJaymz,


Be sure that you're selecting the MFUSB_Netduino.inf file, not MFUSB.ini.

We're basically overriding the Windows driver system by forcing it to use MFUSB instead of WinUSB. Unless we select "no, let me choose" at every step it will try to use the driver specified for the VID/PID in the registry.

Chris

Yes, understand, but it will not let me. I'm running XP 32 bit.

Hi all, I have dusted off the netduino VMware system and aquired another netduino plus. I am confused because I cannot find a definitive guide to what I should be using with versions, the front page mentions 4.1 4.2 sdk, 4.2 firmware, 4.1.0 sdk for the plus and I can't figure out what I need. I have 4.2.0.0 RC4 firmware in my netduino and 4.2 SDK and latest netduino DSK but I cannot use the PWM because its all messed up and the checksums don't match and its all confused. So. Lets start over... Uninstall SDK's , Netduino and just have VS2010. Now, what to install and in what order? I'm happy to update the netduino firmware. Presumably even now, the bug where it cannot be reliably deployed is still with us?

OK, trying now, BRB

Switching to serial and then back again makes no difference.

I cannot install the MFUSB.ini because windows says:

The specified location does not contain information about your hardware.

With only OK as an option.

So I guess were stuffed then.

The only thing I thought about was the bootloader being at fault.

It does deploy the application, then afterwards it says preparing to deploy and then that times out.

Switching to serial and then back again makes no difference.

I cannot install the MFUSB.ini because windows says:

The specified location does not contain information about your hardware.

With only OK as an option.

So I guess were stuffed then.

The only thing I thought about was the bootloader being at fault.