View previous topic :: View next topic |
Author |
Message |
prondeau
Joined: 26 Mar 2008 Posts: 11
|
usb_cdc_putc - lesson learned |
Posted: Sat Jan 19, 2013 12:53 pm |
|
|
I'm just throwing this out here because it took me far longer than I care to admit to troubleshoot and maybe it will help somebody else out in the future.
I recently integrated the serial2 usb example code into my own project. I was actually shocked at how quickly it was up and running. A few changes to ex_usb_common to match my hardware, including the appropriate header files, and adding the usb_kbhit loop to my own code.. boom! it was up and running. So then I began the process of modifying things for my project requirements. Things were going great.
I came back to the code the next day and suddenly things aren't so great anymore. The code was stalling in usb_cdc_putc. I tried commenting out recent changes, did some searching here on the forums and found folks talking about Vusb capacitors and such but nothing I did made a difference.
Then I started looking at registers and noticed that when stalled, the global interrupt enable bit was off. I found if I manually flipped this bit I'd get another few characters to spit out.
In the end I realized I had added a call to usb_putc into a function that was also called by an interrupt. Had I understood more about the inner workings of this USB driver, or possibly was searching the forums for the correct problem, or noticed the issue immediately after making the change that caused the problem- the following line put out by the compiler might have thrown up more of a red flag. Code: | interrrupts disabled during call to prevent re-entrancy: (usb_cdc_putc) |
Lesson learned, don't call usb_cdc_putc from any function that is also used in an interrupt.
Looking back on it all I realize exactly how this happened. Upon first realizing I had a problem I commented out the changes I made in the mainline loop to return it to what I knew was working code. But I forgot about that one late night change to a function tucked away elsewhere in the code. (and that function worked fine with the usb when tested anyways so no need to look there, right? lol) So I started looking at all the hardware issues discussed here and was off on a wild goose chase. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9244 Location: Greensville,Ontario
|
|
Posted: Sat Jan 19, 2013 1:44 pm |
|
|
Been there ..done that..
It's one reason why I have 'incremental' versions of my projects. Save the current source, close, open new project with copy of source, make changes (just a few !), see what happens. Sure I can have 20-30-50 'versions' but once it's 'up and running', I can easily delete all but say the last 3 or 4.
Storage is cheap these days...time is very valuable!
Also..I now use a $3 USB<->TTL module for projects. It eliminates a LOT of code (USB stuff) out of a PIC, saves man hours too as they always work. |
|
|
prondeau
Joined: 26 Mar 2008 Posts: 11
|
|
Posted: Sat Jan 19, 2013 2:34 pm |
|
|
Normally I'd have that same backup scheme going too but I just started this and I kinda dove in without a net.
As for the USB module, I'm not opposed to that and have done it in the past. This is actually the first project where we are getting away from that. Seemed to make no sense to pay extra for functionality that was already sitting there. I boldly went forth with the opinion... "If other manufacturers can figure this out, I certainly can" I'm willing to invest a few hours once to get a library working that I can include in future projects rather than spending $3 over and over. And in this particular application there is an enclosure size restraint where there just isn't room for one more thing. |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Sat Jan 19, 2013 2:48 pm |
|
|
temtronic wrote: | .Sure I can have 20-30-50 'versions' but once it's 'up and running' | I do agree with saving many intermediate versions, it will save you a lot of trouble being able to go back to a known working version. But... creating full backup copies is not of this time any more, that is what Version Control Systems were designed for.
A well known VCS, or Source Management System, is Subversion. On the Windows PC I like the client software called TortoiseSVN. |
|
|
|