chipkit dp32 usb-serial drivers problem

Created Fri, 29 Jul 2016 01:00:38 +0000 by lpereira

lpereira

Fri, 29 Jul 2016 01:00:38 +0000

Hello I'm facing a strange problem. I'm using a dp32 board (windows 10 x64 and arduino IDE 1.6.10) and after several weeks running OK, the serial port (USB chipkit driver) stop working, with the message "USB device not recognized" (yes I know that is common, but...). I tried everything possible (uninstall and reinstall the drivers, update the FTDI drivers, make a clean installations after deleting every drivers files and registry keys, etc...). The board still not working. Sometimes I can have the board working for a few minutes and the problem appears again. I sought for a solution in all known forums without find anything that covers this case. I'm an advanced user in hardware / software and honestly, I'm suspecting that perhaps I have an hardware fault. Someone can give me some indication about this problem? Many thanks in advance.

EmbeddedMan

Fri, 29 Jul 2016 04:00:37 +0000

The chipKIT DP32 board does not use FTDI drivers - it uses the chipKIT USB (STK500) drivers. You can see more information on these drivers (and a download link if you need it) here :[url]http://chipkit.net/wiki/index.php?title=ChipKIT_Drivers[/url]

I'm suspecting the same thing you are - a hardware problem - because of the intermittent nature of your problem.

If you put the board into bootloader mode, and leave it there, is it OK? Or does it still show the same driver problems?

*Brian

majenko

Fri, 29 Jul 2016 09:52:55 +0000

Actually in Windows 10 you don't need any drivers at all anyway - CDC/ACM is built in now (at long long last) and it should just work without installing anything.

One side effect of using CDC/ACM like the DP32 and the Lenny etc is that it relies on the main chip functioning all the time in order to process USB data. And that puts a certain amount of onus on you to ensure that your sketch doesn't lock up the system. It is perfectly possible that some kind of buffer overflow or something similar in your code could kill the USB data space and cause the USB system to crash.

Also, if you aren't actively using the USB CDC/ACM connection ("Serial.begin(...)") it won't create one, and so the board will be invisible to your computer.

If the board is seen by the computer when it programming mode but not when it's in normal run mode then the problem must lie in the sketch or libraries loaded on the board. If the board is still not visible even when in programming mode then it is possible that you have a hardware problem - maybe you have managed to break the main chip with static electricity or something (it happens).

lpereira

Fri, 29 Jul 2016 12:36:01 +0000

Hi Thanks (for both) for our opinions. Effectively I know that the chipKIT USB uses the STK500 drivers (I just tried the FTDI to see if any virtual COM was recognized...). Actually I reinstall the STK500 drivers but majenko is right, the drivers are "part" of win10. Today, in a simple try, I connect the board again, and, surprising, everything appears to be OK (!). I successfully programmed (just once) the pic32mx, without problems. I don't make any intensive work (several programming cycles) but I will do that later. And, once again, majenko is right, I need to be careful to do not corrupt USB data space. My sketch needs a lot of ram (approx. 15Kb), a little more than 50% of total predicted (!), I don't discard the possibility of some corruption due to a spurious overflow not accounted when the variables are declared. I will check that. The only library that I'm using is the serial to communicate with two peripheral chips and even at 115200 Kbps I never facing problems with some "native arduinos" (mega, due, m0 and 101) but I really prefer the pic32. In other hand, when the problem appears, is precisely trying to put the board in programming mode. I can't do anything after such crash, the board becomes unusable until some days...(maybe desktop on/off cycle?) and I use ever (for debug purposes) the serial.begin() for IDE serial monitor. Well, I will try again. And will I try to see if effectively a faulty hardware is responsible (for instance I will try in others computers). I'm using microcontrollers since several years (pic, atmel and different programming environments like arduino IDE, microC, mplab) and I never "burn" one device. But we know that this occurs very easily.. Once again, thank you. As soon I have news, I shared them.