I am having issues deploying code/debugging line by line. Sometimes it connects fine and I can run code, other times it fails at the “attaching debugger,” step. Sometimes unplugging the USB and plugging back in allows for the debugger to work fine. Any advice on how to narrow down the problem? So far my only theory is I selected a crappy USB port that is extremely fragile.
Has anyone had issues with the micro-USB parts selected for debugging? As in durability issues/pins bending…I had one port somehow get bent and could no longer plug anything in. Must’ve been how one of my USB cables got damaged (pins are all pushed back on the one I was using, and no I was not hulk smashing the plug into the receptacle).
I am trying to get my stepper motor working and can set the register values correctly 99% of the time but am getting some odd behavior when I trip the Switch pin…most likely a software issue where I am detecting the wrong edge but that’s just a guess as this code worked on the development board. I know my components are installed correctly but the inconsistent USB debug connection is really making it hard to fine tune all my settings. Was not having this behavior initially.
Do you hear the device disconnecting and reconnecting when you attach the debugger?
Also, are you executing any major code in the entry thread? i.e. the thread that runs the main function.
If it was a faulty USB connection, the system would be much more intermittent than that. Also, since I’m estimating that the usb cable doesn’t move around when you’re debugging, then it should work reliably until the cable is jolted (and not on every other debug session).
About the step motor switch, is it on a resistor to limit the current? Are you using a board you designed or one that was off the shelf? Are there any pull up/down resistors on the line?
@Mr_John_Smith Ok I figured out the motor controller issue but still am dealing with weird debug connection issues. The problem with the L6470 was that I forgot the SW has an internal pull up so removing 5V from that line was not enough to pull it low, the L6470 was keeping it at 3.3 V (I am trying to mimic my hall effect sensor without having to rig up a magnet holder)…just have to pull SW to ground when I want to mimic home being found and it works.
As far as the debug issue - sometimes it get stuck at “Attaching Debugger” and does not proceed until I unplug the USB and plug it back in. Other times it will not detect the G30 at all and just keep counting iterations until I unplug USB and plug back in. Sometimes that doesn’t work and I have to reset to the G30 or kill the power. The device does indeed make a ding whenever the debugger is actually attached. My other board I built (the 2nd one) works much worse. On that board, it will randomly say “USB Device Not Recognized” as a Windows Notification when trying to attach the debugger. I am quite stumped right now…I have overcome so many random mistakes I am at a loss on how to check anything further.
Yes I do have major code inside of main, after it enters Main() it initializes an SPI1 connection and sets the L6470 registers before deciding to enter the calibration thread or to recall data from EEPROM. This runs fine on the development board (except I do recall a few instances where it had to be unplugged and plugged back in). Should I move this to an Initialization method that is called after entering main just to be safe?
I think one board may be having issues with the code in main and the other one has a bad connection somewhere since that is intermittent while debugging, the other issue is only when attaching the debugger.
All of this is combined on one board I am prototyping…I am combining the last 7 months worth of circuits you guys have been helping me breadboard. So in theory this has all been tested and working once.
Hm actually still getting some bugs with the motor controller, it isn’t behaving consistently. Hard to tell whats going on the times Go_Until is called and it doesn’t move (but current increases and you can hear the windings). One thing is for sure, when it does it work and I pull SW low to stop the go until command, the current will spike to 300 mA going through the L6470 but the running current is only like 160 mA…also my Khold is set to 0. 1% so it should not be spiking so high, its usually at like 30 mA or something
debug not being recognised is usually because the deployed code holds the processor in a tight loop and won’t let the debugging thread on the uC get any cycles. If you can set up the code with a 5 or so second wait to test and see if that means the attaching debugging at initiation is much more reliable, then that’s what you need to focus on - occasionally thread.sleep(10) to at least give the processor some relief
we’re talking 5 seconds not 50 milliseconds. In fact, why not make it 10 seconds for testing…
Yes, it needs to be early on in the startup. It doesn’t need to be before anything else, but the debugging engine needs time to get connected, and certainly needs to be before any of your main execution loop starts.
@Brett it seems like adding the 10second delay at the start of main isn’t started till after the debugger is attached anyways…so I get the message saying it was successfully attached then there is a 10 second pause before the code is initiated. But I think the failure is occurring even earlier…my brain is running out of steam though, almost time to go home. Catching 3 major errors was all I had in me for today…
You’re still not quite getting this all. Your code runs once your mucro comes out of reset (or gets power on). Debugging has nothing to do with whether your code runs or not - it will always run, with or without a debugger attached. The sleep you added should always execute as well - now it just appears that nothing happens at startup for longer, when the sleep holds execution
Then doesn’t that confirm what we were endeavouring to prove? That your code is stopping the debugger from attaching, but with this sleep in place it always does attach? (obviously the 10 second “pause” you mention is this added code doing it’s thing). I can’t figure out what you mean by: [quote=“hwalker_MIWV, post:10, topic:21051”]
I think the failure is occurring even earlier[/quote]
because this post is about debug inconsistent connection - it now either connects or doesn’t. If there are any failures to connect, then there’s more to look at - otherwise it’s just your code that you need to investigate, and you need to sprinkle thread.sleep(10) in your code when timing isn’t critical, so that other parts of the system (the debugging engine) can access the processor.
@Brett I don’t fully understand the timing of attaching the debugger with respect to the code being built/at what point it is considered “running.” I expected the delay to be added before the debugger was attached, not just extend the time between it being successfully attached and when it begins running the code.
So I guess what is really happening is the debugger is attached at the same speed, but the pause has been added between successful attachment and execution of the code?
I am still getting deployment errors - I am not sure if there were two causes the errors and this fixed part of it or if it did nothing. On iteration 3 it said “Attaching debugger…” then timed out and failed. I get failures consisting of it going all the way up past iteration 50 then failing but also making it past the iteration step and failing after “attaching…”
Tomorrow I will resume debugging with a fresh brain and make sure these observations are correct.
The framework has a debugging engine - this is part of the netmf firmware. You can’t influence it except by starving it from CPU cycles and using the debug calls it exposes.
The VS deployment tools and debugger utilise the debugging engine on the uC to do the deployment and then establish a debugging session. If you have your code open in VS and hit deploy&debug, the debugger wants to attach to the debugging engine and send it the code and then reset the device and reattach the debugger so you can do your debugging.
Consider the complete powered-down scenario. The framework goes through initial startup and then starts your application. If your app doesn’t release the processor (with thread.sleep) then when you come along some time later and attempt to attach the debugger to the debugging engine, it’ll try and eventually time out because the engine never gets the chance to respond. You should be able to show the same behaviour with mfdeploy and attaching the debugger there to the running device/code.
Consider the restarting hardware scenario if you manage to get deployment to work and it’s attempting to reattach the debugger after restart. Again, it’ll try and it will time out.
So here’s what I would do. If your app has no downtime and can’t have thread.sleep when it’s running, you have to adjust your debugging expectations. Add a wait at the start of the app (the 10 sec wait we added is fine, or have it wait for a button press), and then when you want to deploy a new version of your code, simply hit deploy and hit reset on your device; that means the debugging engine will get it’s chance to respond when it’s in the 10 sec wait, it’ll do a deployment and then restart the device again, wait again for 10 secs, debugger will attach and you can continue on your merry debugging way - but beware that your code may not let the debugging session actually do it’s thing.
If you want it to behave differently you’re likely going to need to relinquish the processor more often. thread.sleep(10) sprinkled thru your code. Then, you should find less issues when you are attempting to deploy new code irrespective of the state of the debugging session. But as a quick and simple workaround, a simple reset often does the business when you see attaching debugger iterations and timeouts…
When I get this problem, I tend to put a debugger attach check in a while loop with a 1 second sleep. This will wait for the debugger to attach before executing any of the code base.
my comment is that this is a great option as long as you only want to debug things. This isn’t a general approach that allows your code to run without the debugger attached; an arbitrary delay or button press are both options that can be used as-is on deployment and won’t stop the app from functioning when the debugger doesn’t get attached (eg when you’re testing with external power only, or when you just hit reset and don’t reattach the debugger)
@Mr_John_Smith Can you explain how to do this or does GHI have anything on it? Everything that comes up on Google is for .NET in VS2015.
@Brett Thank you, I have a decent amount of Thread.Sleeps in my code already but will put more at the beginning. It is definitely getting past the deployment stage and failing at attaching the debugger.
But what would cause USB device not to be recognized randomly with Windows? I still get a fair amount of intermittent connection, on both boards I have, but one is definitely worse. I want to avoid having to reset every time I deploy code as I did not have to do this on the development board - the only times I reset it were on accident and I broke a number of things as a result but it loaded and ran good 99% of the time even with my ignorance of the debug attachment process.
if it truly is different between a development board and code and your production board and code, then you should investigate more - probably hardware issues first.
The answer about debugger being active is to use System.Diagnostics.Debugger.IsAttached and wait for that to be true.
Sometimes reflashing the firmware, down to the loader helps. Just this afternoon I was having problems with a cobra 3. Putting it into boot loader mode and flashing it over seems to have sorted its bad behavior out.
@Mr_John_Smith So far so good since I added the deploy loop at the beginning as well as moved most of my code out of main. Just stuck on my I2C displacy still let me know if you have any advice