Javascript Disabled Detected

You currently have javascript disabled. Several functions may not work. Please re-enable javascript to access full functionality.

The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

Netduino Go Firmware v4.2.1

Started by Chris Walker, Nov 08 2012 02:07 AM

Prev

Next

Please log in to reply

74 replies to this topic

#41 neslekkim

Advanced Member

Members
350 posts

LocationOslo, Norway

Posted 12 November 2012 - 12:49 PM

Read this post: http://forums.netdui...dpost__p__39124

Resolution
1. Dropping the SPI bus speed to 10MHz eliminates data corruptions and allows the display to work again
2. Anyone who is affected by this issue in 4.2.1 should try initializing their Nwazet modules like so (replace Socketx with the proper socket):

canvas.Initialize(GoSockets.Socketx, 10000); // 10 MHz

or if the issue persists:

canvas.Initialize(GoSockets.Socketx, 5000); // 5 MHz

3. The same recommendation applies to the DAQ

Conclusion
With release 4.2.1, the Netduino Go firmware introduced a change which made SPI communication above 10MHz unstable.
The Nwazet display and DAQ modules use ARM Cortex chips capable of high SPI frequencies and are configured to maximize SPI throughput by default, well above 10 MHz.
Other STM8S-based modules are unaffected by the change introduced in 4.2.1 because they work at much lower frequencies, typically much lower than 5MHz.

--
Asbj�rn

Back to top

#42 neslekkim

Advanced Member

Members
350 posts

LocationOslo, Norway

Posted 12 November 2012 - 12:50 PM

Damn, Carb beat me to it..

--
Asbj�rn

Back to top

#43 supra

Advanced Member

Members
210 posts

LocationOntario, Canada

Posted 12 November 2012 - 04:03 PM

Hi Supra,

it works with 4.2.0.0 and it may work with 4.2.0.2, the issue however is to use the NWAZET screen under 4.2.1.x ;-)

Have you tested it under the new firmware?

Cheers

Andi ;-)

Yes. I have tested 4.2.1.0 to use nwazet LCD

Back to top

#44 supra

Advanced Member

Members
210 posts

LocationOntario, Canada

Posted 13 November 2012 - 01:55 AM

Are you sure?, also if you scope the PWM class?

That is, doing this:
  leds[0] = new PWM(Microsoft.SPOT.Hardware.Cpu.PWMChannel.PWM_0, 100, 1, false);

This one is better. W/out using namespace
leds[0] = new PWM(Cpu.PWMChannel.PWM_0, 100, 1, false);

Back to top

#45 iandi

Member

Members
23 posts

Posted 13 November 2012 - 11:11 AM

Hi Andi,

The 4.2.1 update is mostly bug fixes in the NETMF firmware. One of those bug fixes is that we were not throwing exceptions properly in some cases in the earlier versions (such as when trying to create two OutputPorts with the same pin).

Let's make sure we get your serial comm back up and running, along with the [nwazet touchscreen accessory. Let's attach one of those at a time.

First, the serial communication. What is/is not working, specifically? Are you able to open the port? Does data get sent? What type of device are you talking to? If you switch to a GoPort on the other side of the board, does it work then?

Chris

Hi Chris,

we have reduced SPI speed to 10MHZ as NWAZET recommended and the screen works well now.

As far as the serial comm is concerned, yes, we can open the port and we can send data to it, but our serial module, which is connected to the GO! port, doesnt recognize it (which it did before we flashed to 4.2.1). It was working all the time and we have neither changed any code nor electronic wiring.

Also, there is no error thrown when sending to the port...

Cheers

Andi ;-)

Back to top

#46 Chris Walker

Secret Labs Staff

Moderators
7767 posts

LocationNew York, NY

Posted 13 November 2012 - 04:58 PM

Hi iandi, What speed are you using to communicate with the serial device? If you connect it to one of the COM ports on a Shield Base instead, does that work for you? Do you happen to have a logic analyzer? Or can debug the sent/received data from the device itself? In other words...is data getting lost/corrupted getting _to_ the device or en route to the mainboard? Chris

Back to top

#47 indimini

Member

Members
15 posts

Posted 13 November 2012 - 05:01 PM

I hope somebody can help with my Go board post-4.2.1.0 upgrade. I reflashed per the instructions and everything looks good - when I run MFDeploy I can ping the Go, and I see CLR version 4.2.0.0 and the SecretLabs solution vendor version of 4.2.1.0, so it looks like the device is properly set up. However, when I try to debug a simple application from VS 2010, after compiling and selecting the Debug option, the message in the status bar indicates the assemblies are deployed, but then it sits with the message "The debugging target is not in an initialized state; rebooting..." I then hear the sound of the USB device disconnecting, but the device never reboots. If I stop the debugger, and try to restart debugging, I get an error message saying that there is no connected device. Checking the status of the Go in MFDeploy, the device does not appear. I am unable to do anything with the board in this state - I can't deploy/debug any code. I've tried this on two different machines with the same outcome.

Back to top

#48 Chris Walker

Secret Labs Staff

Moderators
7767 posts

LocationNew York, NY

Posted 13 November 2012 - 05:05 PM

Hi indimini, Did you upgrade the Netduino SDK on your computer to the latest version (4.2.1)? You'll need the newest assemblies. If so, please check the output in your Output window while deploying. What does it say? Where does it get stuck? This information will help guide us to resolve the issue. Thank you, Chris

Back to top

#49 indimini

Member

Members
15 posts

Posted 13 November 2012 - 05:48 PM

Chris, Yes I am on the latest version of the SDK. I guess I didn't read previous posts carefully enough. I was trying to use the PWM w/ the on-board LED's which was what was causing the Go to behave badly. That'll teach me to read more and learn from others experiments before writing code. Bob

Back to top

#50 Lunddahl

Advanced Member

Members
152 posts

LocationEurope, Denmark

Posted 13 November 2012 - 10:06 PM

If I stop the debugger, and try to restart debugging, I get an error message saying that there is no connected device. Checking the status of the Go in MFDeploy, the device does not appear.

I am unable to do anything with the board in this state - I can't deploy/debug any code. I've tried this on two different machines with the same outcome.

There might be a chance that everything is in perfect order, but you have a "faulty" program that is using so many resources that the board can't function normally.

I used to boot the board in DFU mode by holding down the button, and reflash all firmware with the DufSe Demo app, but that takes a long time, and is quite annoying when you have make the same programming error for the 10th time...:-)

So now i use MFdeploy and the erase button besides the ping button, sometimes it takes a few tries to hit erase just after you have booted the board, but 9 out of 10 times i manage to erase the deployment only, and now that we have removed the "faulty" program, VS have a chance to deploy again.

Usually i get into this kind of trouble when i try to do anything that uses hardware, last time it was with PWM, but you can force this behavior quite easily by overloading the board.

As Chris said, using the wrong (old) .dll files in your project can also act like a "faulty" program, and make the Go unresponsive.

- Ulrik

Back to top

#51 iandi

Member

Members
23 posts

Posted 14 November 2012 - 09:08 AM

Hi iandi,

What speed are you using to communicate with the serial device?

If you connect it to one of the COM ports on a Shield Base instead, does that work for you?

Do you happen to have a logic analyzer? Or can debug the sent/received data from the device itself? In other words...is data getting lost/corrupted getting _to_ the device or en route to the mainboard?

Chris

Hi Chris,

we are communicating with 9600 baud.

We have a logic analyzer which I wanted to use today, but after rebooting the board and I dont know why, serial communication works reliably ;-) This is magic and hopefully won't dissapear magically ;-))

I havent rebooted the board after I changed the SPI speed for the NWAZET screen.

Cheers

Andi ;-)

Back to top

#52 Chris Walker

Secret Labs Staff

Moderators
7767 posts

LocationNew York, NY

Posted 14 November 2012 - 09:34 AM

Hi Andi,

we are communicating with 9600 baud.

We have a logic analyzer which I wanted to use today, but after rebooting the board and I dont know why, serial communication works reliably ;-) This is magic and hopefully won't dissapear magically ;-))

Okay, glad it's working for you. If it acts up, please capture a stream of data on the logic analyzer to determine which data is making it through. Also please verify that the clock speed is correct, as seen on the logic analyzer. The most common issue for serial port issues is baud rate divisor math...and while we're using the default calculation I'd want to rule that out as a possibility first.

Chris

Back to top

#53 supra

Advanced Member

Members
210 posts

LocationOntario, Canada

Posted 14 November 2012 - 10:18 AM

@Chris
I still had problem 4.2.1.0

'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:\Program Files\Secret Labs\Netduino SDK\Assemblies\v4.2\le\GoBus.dll', Symbols loaded.
A first chance exception of type 'System.Exception' occurred in Microsoft.SPOT.Hardware.dll
An unhandled exception of type 'System.Exception' occurred in Microsoft.SPOT.Hardware.dll

Uncaught exception
The thread '<No Name>' (0x2) has exited with code 0 (0x0).

Module: Shield Base
Firmware: v0.3.0.0 beta 4
Socket: 5

Press BTN to start.
powering up socket and connecting to bootloader...
A first chance exception of type 'System.Exception' occurred in Microsoft.SPOT.Hardware.dll
An unhandled exception of type 'System.Exception' occurred in Microsoft.SPOT.Hardware.dll

I erased 20 times.

Switching back to 4.2.0.2 fine with me.

It my NGO is virus? Posted Image

Back to top

#54 Chris Walker

Secret Labs Staff

Moderators
7767 posts

LocationNew York, NY

Posted 14 November 2012 - 05:31 PM

Hi supra,

@Chris

Switching back to 4.2.0.2 fine with me.

It my NGO is virus?

We're updating the Shield Base updater to work with the 4.2.1+ firmware. It tries to reserve some I/O pins what are already reserved and an exception is thrown.

We should have an update for it by the end of next week, alongside the 4.2.1.1 update.

Chris

Back to top

#55 GregR

Advanced Member

Members
32 posts

LocationKeller, Tx

Posted 14 November 2012 - 06:19 PM

Hi supra,

We're updating the Shield Base updater to work with the 4.2.1+ firmware. It tries to reserve some I/O pins what are already reserved and an exception is thrown.

We should have an update for it by the end of next week, alongside the 4.2.1.1 update.

Chris

Hmmm...in the other thread on the updater issues you said around 3 days...now we have gone to 2 weeks. I guess that's why I get so frustrated. I keep waiting and waiting for the shieldbase to work fully but then something new comes out and then the shieldbase has to take the back seat to the new toys.

Fabien Royer likes this

Back to top

#56 Chris Walker

Secret Labs Staff

Moderators
7767 posts

LocationNew York, NY

Posted 14 November 2012 - 06:46 PM

Hi Greg,

Hmmm...in the other thread on the updater issues you said around 3 days...now we have gone to 2 weeks. I guess that's why I get so frustrated. I keep waiting and waiting for the shieldbase to work fully but then something new comes out and then the shieldbase has to take the back seat to the new toys.

If you want to use the Shield Base reflasher now, here are two options:

1. Flash your Netduino Go with 4.2.0 firmware, and then run the updater. When you're done, you can then update your mainboard to 4.2.1.

2. If you comment out all the code which turns on/off the GoPorts and LEDs, the updater will probably run fine. Those are non-critical features.

The Shield Base did not require any updates for the 4.2.1 firmware, so hopefully your Shield Base was already updated for the previous firmware. If not, please try one of these two methods while we work on a more elegant update. Sorry for not syncing the two releases; this was due to a last minute bug fix to the NETMF Port.ReservePin class.

Chris

Back to top

#57 NXTwoThou

Advanced Member

Members
68 posts

LocationTulsa, OK

Posted 29 November 2012 - 05:32 PM

Kind of curious to know the status on the update to correct the issues with 4.2.1 and the new updater code.

Back to top

#58 Chris Walker

Secret Labs Staff

Moderators
7767 posts

LocationNew York, NY

Posted 30 November 2012 - 08:54 AM

Hi NXTwoThou,

Kind of curious to know the status on the update to correct the issues with 4.2.1 and the new updater code.

Quick update on this.

We're working on a revised updater which will premiere with the Shield Base Beta 5 update. This update will bring the last missing feature to Shield Base--I2C

It'll be ready in December.

We're also updating the Netduino Go firmware to match the new updater. It'll expose the LEDs via objects so that they can be controlled by GoBus and used by the updater automatically. The update will also include a bug fix regarding SPI transfer speeds on one of the two GoBus channels.

In the meantime, if you need to update your Shield Base to beta 4, we have a quick workaround:

Flash your Netduino Go with the 4.2.0.x firmware
Deploy the Shield Base Beta 4 updater, to update your Shield Base
Update your Netduino Go to 4.2.1.x firmware

Once we get enough feedback that the I2C feature is working well, we'll start the migration to GoBus SPI transport. Then the Shield Base firmware will come out of beta and we'll be able to use several on a single board at once

Thanks for your patience while we sorted this out and while we work on the next firmware update for Netduino Go and the Shield Base.

Chris