9 replies to this topic

[sst.thad]

I think I found a bug the other day in the framework, and I don't know where I should post about it, so i'm posting it here. I could be considered user error, but in my constructor for the PWM class, i was setting the hertz input to .00005 because I was dividing instead of multiplying. When I ran this code, it said unhandled error in microsoft.spot.hardware.pwm. When this happened, the Netduino completely stopped responding to any input. MFDeploy could not find it, and I could not redeploy code. It also was not responding to the reset button. I had to completely re-image the netduino in order to get it responsive again. I know this is not a normal use case, but I don't think an error like this should require reimaging in order to fix. I am using a Netduino Plus 2 with the newest firmware.

[Gutworks]

Hi sst.thad,

 

Can you paste the code you are using for the PWM constructor? I can try and reproduce it here. One thing I have found with the Microsoft NETMF PWM class is that when it receives bad values it crashes and at times can corrupt the Netduino. Also make sure you are using the PWMChannels and not Cpu.PWMChannel.

 

For example:

 

PWM led= new PWM(PWMChannels.PWM_PIN_D3,1000,1,false);

 

This of course is assuming you are using the MS PWM class. 

 

Cheers,

Steve

[Arron Chapman]

This of course is assuming you are using the MS PWM class. 

 

Which if your not, then we've found your problem

[sst.thad]

Cpu.PWMChannel pin = PWMChannels.PWM_PIN_D3;double period = 5.0;int periodMultiplier = 4;double m_centerPWM = 1.5;double period = period * periodMultiplier;double hertz = 1 / period / 1000;double duty = m_centerPwm / period;channel = new PWM(pin, hertz, duty, false);

 

If i change the hertz line to

double hertz = 1 / period * 1000;

 

It works. 

 

It was a math error on my part, but i dont think an error like that should completely corrupt the system.

[mackelen]

I also ran into this problem a few times ... Had to flash the board a couple of times (for the Netduino Plus) and only one till now for the Netduino Plus 2. But it is strange that a programming error can make the board completely unresponsive.

[NooM]

why thats strange?

same happens for native coding too.

 

you could add a try/catch where this happens, than it wount be unresponsive.

 

i am using a thread.sleep(5000) before my code, so when something crashes i just reset it and flash the fixed software as soon as power plugged in again

 

so i dont have to reflash it all the time when something goes wrong. - and iam young, i have 5 seconds time

[CW2]

But it is strange that a programming error can make the board completely unresponsive.

 

It is not really that strange, depending on the nature of the bug the microcontroller could be stuck in an endless loop, exception/fault handler (usually implemented as some diagnostic output followed by an endless loop), or continuously resetting itself (in an endless loop) 

 

On Netduino/Plus, you can use MFDeploy to erase just the application:

• Launch MFDeploy,
• unplug the USB cable,
• press and hold the Reset button (on Netduino),
• plug in the USB cable,
• release the Reset button,
• connect to Netduino in MFDeploy (F5), press the Erase button to erase the application.

There used to be a timeout for the connection, I think 3 seconds, but it seems to be removed, the recent bootloader (4.2.0) will wait for the connection forever.

[Gutworks]

Cpu.PWMChannel pin = PWMChannels.PWM_PIN_D3;double period = 5.0;int periodMultiplier = 4;double m_centerPWM = 1.5;double period = period * periodMultiplier;double hertz = 1 / period / 1000;double duty = m_centerPwm / period;channel = new PWM(pin, hertz, duty, false);

  If i change the hertz line to

double hertz = 1 / period * 1000;

  It works.    It was a math error on my part, but i dont think an error like that should completely corrupt the system.

So I did some playing around last night with PWM on both the Plus and Plus 2. The results on the Netduino Plus were as expected, however it did lead me to realize the minimum allowable PWM frequency of the Plus which seems to be 16Hz. I hadn't given much thought to it before, but it does make sense to have a min and max frequency since the firmware is using specific clock and capture/compare register settings that will eventually hit its limits (I can't explain it much further since my firmware knowledge is extremely limited). So in the case of your mathematical error you were going well below the 16Hz frequency and therefore causing a hardware error which is to be expected. Using the Netudino Plus I produced the error several times while trying to find the minimum values, and have yet to reflash my board.    As for the Netduino Plus 2, there were some slightly different results that are still puzzling me. Using the same code the results were varied and inconsistent. Initially I had 4 different PWM objects, each on the same four pins as the Netduino Plus, 5,6, 9, and 10. When using 16Hz on pin 5 my logic analyzer showed a constant high state for that pin, with the rest showing their expect results. After that first test I could no longer use any value for the frequency on pin 5, but was able to change the values of the remaining pins without any issue. I even switched my leads to make sure it wasn't a connection issue.    Then I tried setting the frequency to 100Hz on pin 3 (The NP2 has a couple more PWM pins). It worked as expected. Then I changed the value to 16Hz, and I rendered that pin to a permanant high state like pin 5. No matter the value I can't generate a PWM signal on it now.    Curiosity is said to kill the cat, so I thought why not try setting pin 6 to 16Hz. At this point, it would seem that I have finally corrupted the Netduino Plus 2. I have yet to reflash it, and won't have time until later today. But will try it again to see if I get the same results.    Here is a screen shot of the Netduino Plus and the various frequencies:  NetduinoPlus_PWM_Samples.png   652.98KB   38 downloads   The Netduino Plus 2, just has a bunch of flat lines stuck at a high state.    The code I was using was as follows:  

            PWM pin9 = new PWM(PWMChannels.PWM_PIN_D9, 1000, .5, false);            PWM pin10 = new PWM(PWMChannels.PWM_PIN_D10, 100, .5, false);            double period = 5.0;            int periodMultiplier = 4;            double m_centerPWM = 1.5;            period = period * periodMultiplier;            double hertz = 1 / period / 1000;            double duty = m_centerPWM / period;            Debug.Print("hertz: " + hertz);            Debug.Print("duty: " + duty);            PWM pin5 = new PWM(PWMChannels.PWM_PIN_D5, 16, .5, false);            hertz = 1 / period * 1000;            Debug.Print("hertz 2: " + hertz);            Debug.Print("duty 2: " + duty);            PWM pin6 = new PWM(PWMChannels.PWM_PIN_D6, hertz, .5, false);            pin5.Start();            pin6.Start();            pin9.Start();            pin10.Start();            Thread.Sleep(-1);

[Gutworks]

I tried a few more tests today and noticed an odd difference between the PWM on the Plus and Plus 2. What I found was that, not only did values below 16Hz fatally crashes the NP2 as noted before, but any frequency passed to the constructor is actually doubled on the actual waveform. This is unlike the Plus, where you pass a value of 50Hz, you get a 50Hz square waveform. The NP2 actually generates a square wave with a 100Hz frequency. 

 

Here is the code I used, however for the Netduino Plus, I commented out the pin3:

 

PWM pin3 = new PWM(PWMChannels.PWM_PIN_D3, 25, .5, false);  //comment out when using the Plus. PWM pin5 = new PWM(PWMChannels.PWM_PIN_D5, 50, .5, false);PWM pin6 = new PWM(PWMChannels.PWM_PIN_D6, 100, .5, false);PWM pin9 = new PWM(PWMChannels.PWM_PIN_D9, 1000, .5, false);PWM pin10 = new PWM(PWMChannels.PWM_PIN_D10, 10000, .5, false);pin3.Start();pin5.Start();pin6.Start();pin9.Start();pin10.Start();Thread.Sleep(-1);

The Netduino Plus 2 results:

 NetduinoPlus2_PWM_Samples-50to10000.png   583.07KB   50 downloads

 

And the Netduino Plus results:

 NetduinoPlus_PWM_Samples-50to10000.png   605.89KB   43 downloads

 

Is this a firmware bug, or is it expected behaviour?

 

Cheers,

Steve

 

[mackelen]

The strange thing is that the board also does not act as expected when powering while pressing the button. As I read it should not load the flashed program, however this does not prevent the board from blocking. That is the strange part, it is logical that the board can block due to a programming failure.