In my previous post I describe how I chose a board from an open design to use as my development environment. By now, I had assembled the board, I had searched in Microchip’s site, downloaded the USB drivers for Windows (unfortunately, I only have a single laptop on which I do all development plus my daily officework, so it had to be this), and everything seemed ready to kick off. So the big moment came, I plugged in a USB cable from my PC to the board.
And then nothing.
No smoke coming up from the board. No sign that my PC had seen a USB device. Had I burned my PC’s USB port? Naaah, the red power LED was on, plus I measured 5V DC on the PIC’s power supply line. Still, no signs of action at all. Time to re-read the instructions: to get the bootloader running, I had to hold down the USER switch of my board while pressing and releasing the RESET switch. Did that and still nothing. So, I repeated this step, trying several dozens of button combinations and holddown times, when suddenly… oops!! There was a glimpse of something on my PC!
I am saying “something”, because what happened was that a USB device appeared, then it disappeared again and an error message popped up about Windows not being able to recognize my USB device because the device had malfunctioned. So, there was a sign of life on my board after all! However, when I tried again, I could not even reproduce this “malfunction”. The board seemed dead again. Another several dozens of tries, and I managed to bluescreen my PC, with an error message appearing about the Microchip USB driver causing trouble. This had to be my board again, which was a good sign! My board was definitely not dead, but it was clear that I had to debug the situation further to see what was going on.
To cut a long story short, and after several hundreds of rounds of reset sequences, where I occasionally managed to make the “device malfunction” message appear and and/or to bluescreen my PC, I accidentally noticed that when I held the PCB with my left hand, pressing the buttons with the other hand, I could get the PC to see the board as a USB device for a few seconds, until it disappeared again.
By the next half hour, I had perfected myself in holding the board in a certain manner for long enough to get Windows to recognize the board as a USB device and to have the Microchip’s boot loader controller program talk to it. Holding the board “in a certain manner” means that I had to hold it with one hand, somehow making a “nest” for it, much like one would hold a wounded little bird or other small-size animal. It was clear: this board needed a lot of tenderness, or else it would refuse to work!
One other worrying sign was the green “user” LED of the board, which was not showing any activity. I had to look at the bootloader source files for this. It turned out that the bootloader source as modified for nuxie1’s board, was still using a different PIC port for the user LED — obviously, this was correct for Microchip’s own development board (which BTW has two user LEDs), but not for this one. So, I needed to recompile the and re-flash bootloader.
I installed Microchip’s MCC18 and MPLAB IDE, jumping into another day or two of steep learning curves, however at the end of the second day I had the modified-modified bootloader ready, and flashed it back into my PIC. Plugged back into the USB port of my PC, held the board tenderly and – voila! – the green user LED came to life! This was definitely a good sign!
Next I decided to demystify the “hold-me-tender” issue. I thought that it might have something to do with the LVP warning I had mentioned in my previous post. So, I read all about LVP, a configuration mode in modern PIC chips which allows In-Circuit-Serial-Programming (ICSP) without needing a high programming voltage (12V or higher). PICs come with this setting preconfigured on, and in in order to reset this to off, one needs to have 12V or higher available in the programmer — which FDART2003 does not.
Moreover, mumble, mumble, in LVP mode, PIC’s RB5 is used as a PGM (program) strobe, and in normal operation it has to be set to logic zero, otherwise the PIC will reset! A quick look back to nuxie1’s board: RB5 was an open pin. This sounded much like what was happening: Windows was seeing the board for a while, then it lost it because the PIC was resetting. I tried connecting RB5 to the GND and then letting the board work without my own tender hold, and, yes! This was it!
So, how was then ever possible that the board worked at all before this? Well, when I was holding the board “tenderly”, I was accidentally connecting the open RB5 pin available at the one side of the board to the GND signal available at some other open pin at the opposite side of the board via my own hand! Mystery solved!
Now that I had a reliable environment to work on, I tried some of Microchip’s examples, changing the code and recompiling to get at least the user LED right. Microchip’s development board has several peripherals which are of course absent in nuxie1’s board, so I had to modify code here and there, but at the end of the day I managed to have the board communicate to the PC, accepting commands and returning back some values.
I deemed that this was enough for now, so I decided to pause and turned my attention to the actual project: design and build an FXS board. This is covered in my next post.