Has anyone managed to set up VS2013 / NETMF 4.3 / SDK 2015 R1 (for Panda III) on the same PC as VS2010 / NETMF 4.1 / SDK 4.1 (for Panda II)?
I have a legacy product using Panda II, and looking at switching to Panda III, so installed VS2013 etc on my development PC. But, now I am having issues with VS2010 seeing the Panda II (which I need to keep developing on), so it won’t deploy. I can also see it with MFDeploy, but not USBizi updater. FezConfig also sees it okay and I can deploy hex files from there.
If I connect it to another PC with only the older Panda II install on, VS2010 sees the same Panda II unit perfectly and deploys without a hitch. This happens with both Panda IIs I have tried.
It feels like the install of the later SW has somehow messed with the original setup (I actually lost USBizi updater when adding the later SW somehow, and had to re-install the SDK to get it back).
Does anyone know if it is only possible to have one setup on a single PC, or whether I just have to install everything in a specific sequence?
Any hints much appreciated!
@ HalfGeek - The 2015 R1 SDK comes with the 4.1 SDK, as long as you check it under the Advanced options in the installer. It should work just fine with VS2013. The NETMF SDK the 2015 R1 SDK requires is no longer compatible with VS2010.
(I had to wait 8+ hours to reply, as that was my first post!)
I had misunderstood the notes about legacy and thought Panda II had to stick with VS2010. I double-checked it still failed in VS2010 (it did) and then tried VS2013 - it deployed first time. In hindsight, a search for Panda II and VS2013 gives me this answer many times over - I just didn’t hit the needed search phrase when I was looking before!
Thanks very much for the swift help.
Oddly, my Panda II is now not booting up the main application on it’s own unless I have the MOD pin shorted to GND (which is standard for this product as we use USB-MSC). If I do not have the MOD pin shorted, then it talks to VS and runs fine as debug, but won’t boot up the app on it’s own. We use the bootloader function for in-field update and I have also been experimenting on these 2 Pandas with USB-CDC with debugging as well to add serial port control, so I may well have messed up something else there. I will grab a “fresh” Panda and try with that to see if it is a completely separate issue of “user error”!!
@ HalfGeek - Yea sorry about that 8 hour thing; it’s part of the spam control. When you’re famous…
@ HalfGeek - welcome to the community
@ Mr. John Smith - It was quite nice to be forced to actually go and check before replying
@ Gus - Thanks, Gus. I have lurked around here for a while, enjoying the very helpful resources that are here, but not posted before. Now I have stepped out of the dark, I hope that one day someone has a simple enough problem that even I can be a help!
On the latter past of my last note (Panda not starting without MOD pin shorted), I grabbed some fresh Pandas and had a play.
On my development PC with VS2010/NETMF4.1 and VS2013/NETMF4.3 and also the CDC/USB debug drivers, I also tried FezConfig and had issues. Usually, after deploying hex files from FezConfig, the Panda II reboots itself. However, since installing VS2013/NETMF4.3 (I think that was the point of change), the deploy works but the Panda II does not reboot. Even resetting the Panda II does not help, but, oddly, if I then try and deploy again, the application does run briefly before the deploy (I have a display attached during deploy and can see what is running).
I then tried on a PC with VS2010/NETMF4.1 and the CBC/USB debug drivers and it works as expected (resets after the deploy), and then on a PC with VS2010/NETMF 4.1 without CDC/USB debug drivers and that worked fine as well.
Has anyone seen this at all, with or without the upgrade to VS2013/NETMF4.3? Does installing NETMF4.3 modify anything the FezConfig uses to deploy to a Fez Panda II?
The hex files I am deploying are ones I made ages ago, way before installing VS2013/NETMF4.3. I assume that FezConfig should not care about that.
The deploy sequence I use is :
- Deploy a program which simply runs SystemUpdate.EnableBootloader(); to partition the Panda, and display a confirmation message. This then reboots to the main application address
- Deploy the main application. This can then reboot to the bootloader address on certain button presses. This is triggered to boot to the (empty) bootloader address.
- Deploy the update application to the bootloader memory. This is also then triggered to return to the “normal” booting to application memory.
I don’t think that sequence has anything to do with it, but I note it here just in case!! If anyone knows a quicker/simpler way to take a “fresh” Panda II, partition it to bootloader/app, and then deploy the main app and updater apps to the partitions, then I would gratefully hear it
The WinUSB driver change is responsible for behavior changes on older 4.1 legacy devices. Nothing you can do about it besides have a parallel install of tools if you really care. One simple way to deal with the impact we’ve discussed here before is to simply open MFDeploy and connect to the debugging engine.
@ Brett - Thanks, Brett.
Not a major problem for development, so I can leave it as it is on my main PC. I will do all my deploying on a PC without VS2015 as any extra steps when deploying a lot of boards would be a pain.