Hi all,
I am new to NetBurner, but not to Eclipse or GDB (mostly using JTAG).
We are evaluating NetBurner to replace an existing solution.
Vitals:
NNDK version 3.5.0
MOD5441X
NNDK-MOD54415LC-KIT
Since we are in early stages I have been importing and running the simple examples.
What I find is that after running the debugger and terminating the debug session the debugger fails to reattach on the next launch (though not always).
The message is: "Failed to send application to device. Aborting debug session"
The examples I have run are: SImpleHtml, TcpSimpleServer, TcpToSerial
I see this problem on all of them
As I said this does not happen every time and I have been trying to narrow down a pattern that both make it fail and the ones that don't fail; with no clear procedural steps to mitigate the issue found.
My nearest guess is that the program is still running when I terminate and it is stuck in a blocking call, but this is just a wild guess.
If I press the reset button it always recovers, normally I would be fine with this but I want to work remotely as well and obviously I cannot press reset in this case.
I tried putting in a thread that just reads stdin and if it gets an 'r' it reboots, however I found this does not solve the issue.
Has anyone experienced this, and is there a work-around?
Thanks in advance.
Regards,
A.A.L.
Reattach debugger after terminate fails
Re: Reattach debugger after terminate fails
Hello,
Thank you for considering our products for your design. There are some options in eclipse in regard to restarting the debugger, and I will get you some information on that once I take a look. I will also check for any errata on 3.5.0 for the debugger. I usually do release builds since a debug build on anyone's platform requires that optimization and processor cache be turned off, so the a debug build from the gcc compiler isn't the same (slower for example).
When the issue occurs, have you stopped execution of the application, or are at a breakpoint or single step? It sounds like the program may not be running and that would cause a download to fail. Maybe you have breakpoints set and even if you hit run the program stops execution for some reason?
Also related, I would like to put in a plug for our new feature, a web console. A web socket is used so you can utilize a web browser like a serial port to get status messages or add release build debug features such a debug options in a menu.
Just to make sure there is no confusion with development requirements, I would like to point out that the debugger is not required at all to use the tools. Just as a data point I can give to engineering, have you ever had any issues with release builds? I realize that some people prefer to only develop in a debugger, but that information would help to identify if there are any issues with the tools installation or the network environment. Release is an easier test case, since debugging involves different network connectivity to talk to GDB. So worse case should there be any issues with an application behaving badly in the network debugger (different than a hardware jtag debugger), release builds would still work any time you are working remotely.
How was remote debugging handled with your jtag setup? Were you running something like remote desktop? If that is how you previously developed, then you may be able to reset the device through a serial terminal if need be.
Lots of questions, but if you can please address each of those it would help me understand you development environment so we can resolve any issues and hopefully provide an environment you are used to.
Thank you for considering our products for your design. There are some options in eclipse in regard to restarting the debugger, and I will get you some information on that once I take a look. I will also check for any errata on 3.5.0 for the debugger. I usually do release builds since a debug build on anyone's platform requires that optimization and processor cache be turned off, so the a debug build from the gcc compiler isn't the same (slower for example).
When the issue occurs, have you stopped execution of the application, or are at a breakpoint or single step? It sounds like the program may not be running and that would cause a download to fail. Maybe you have breakpoints set and even if you hit run the program stops execution for some reason?
Also related, I would like to put in a plug for our new feature, a web console. A web socket is used so you can utilize a web browser like a serial port to get status messages or add release build debug features such a debug options in a menu.
Just to make sure there is no confusion with development requirements, I would like to point out that the debugger is not required at all to use the tools. Just as a data point I can give to engineering, have you ever had any issues with release builds? I realize that some people prefer to only develop in a debugger, but that information would help to identify if there are any issues with the tools installation or the network environment. Release is an easier test case, since debugging involves different network connectivity to talk to GDB. So worse case should there be any issues with an application behaving badly in the network debugger (different than a hardware jtag debugger), release builds would still work any time you are working remotely.
How was remote debugging handled with your jtag setup? Were you running something like remote desktop? If that is how you previously developed, then you may be able to reset the device through a serial terminal if need be.
Lots of questions, but if you can please address each of those it would help me understand you development environment so we can resolve any issues and hopefully provide an environment you are used to.
Re: Reattach debugger after terminate fails
TomNB,
Thanks for the quick response.
That was a lot to digest for a newbie, however I'll give it a go:
For now what I have done is attached a wire from the reset switch to another platform that allows me to reset the NB remotely.
I have been pausing the debugger, then stopping it, then terminating all running processes, mainly because this is how I do it on other projects that I've used eclipse on, both on Linux PC's and Embedded SOM's. Yes there are break points in the code.
Do you suggest I just terminate the debugger session without first stopping?
I'll eventually take look at the new web console feature you mentioned, for now I'm simply getting used the platform.
I am well far away from a release build.
I understand that a debugger may not be required for development. However, for the work we do it is essential for efficient development. Perhaps if I were a better programmer or maybe I've become too reliant on breakpoints/single steps etc.
. The NB will be working as part of a multiprocessor system so it helps a great deal to be able to break, examine variables, you know the usual debugging tasks. One of our current modules does not have this capability so it will be a great relief to get away from udp printf debug messages. Anyway for me it is sort of a hard requirement during development for any new platform we consider; and in this initial evaluation your network debugger seems more than adequate.
Maybe my terminology was not exact regarding remote debugging. What I meant is I VPN / VNC into my work desktop from home and work from there. So essentially it is the same as working at my desk with the exception I cannot physically press the reset button. That is why I wired a reset line across from another platform. This will continue do the trick as I get more familiar with the entire system/tools.
Once again, thank you for your response.
Anymore information is always appreciated.
Looking forward to continued progress with this platform.
Regards,
A.A.L.
Thanks for the quick response.
That was a lot to digest for a newbie, however I'll give it a go:
For now what I have done is attached a wire from the reset switch to another platform that allows me to reset the NB remotely.
I have been pausing the debugger, then stopping it, then terminating all running processes, mainly because this is how I do it on other projects that I've used eclipse on, both on Linux PC's and Embedded SOM's. Yes there are break points in the code.
Do you suggest I just terminate the debugger session without first stopping?
I'll eventually take look at the new web console feature you mentioned, for now I'm simply getting used the platform.
I am well far away from a release build.
I understand that a debugger may not be required for development. However, for the work we do it is essential for efficient development. Perhaps if I were a better programmer or maybe I've become too reliant on breakpoints/single steps etc.
. The NB will be working as part of a multiprocessor system so it helps a great deal to be able to break, examine variables, you know the usual debugging tasks. One of our current modules does not have this capability so it will be a great relief to get away from udp printf debug messages. Anyway for me it is sort of a hard requirement during development for any new platform we consider; and in this initial evaluation your network debugger seems more than adequate.Maybe my terminology was not exact regarding remote debugging. What I meant is I VPN / VNC into my work desktop from home and work from there. So essentially it is the same as working at my desk with the exception I cannot physically press the reset button. That is why I wired a reset line across from another platform. This will continue do the trick as I get more familiar with the entire system/tools.
Once again, thank you for your response.
Anymore information is always appreciated.
Looking forward to continued progress with this platform.
Regards,
A.A.L.
Re: Reattach debugger after terminate fails
Hello again,
Thank you for sharing all that. It is always interesting to me to learn how developers work. I think we do things similar in developing remote. I have the h/w set up at work, and use remote desktop. That way I don't have to maintain work/home configurations for eclipse, git, etc. I rely heavily on the serial port for status messages, so I have that connected as well.
Every developer has their preferred method, and I'm not trying to convince you of anything, just thought I would throw a few things out there in case its useful. Within our own company our developers run the range: windows, osx, linux, eclipse, vscode, VIM, and one guy with an editor so old I don't know the name of it. I think it used to be called brief at one point.
Regarding debugger stop, terminate, breakpoint, etc., unlike with your jtag debugger, a network debugger needs a running target to perform an application download. So if the target is not running for any reason (halted, repeated system crashes, ...) the download will fail. There are methods to work around that (getchar() or delay at the app start), but I don't want to put too much in one post. Being able to reset is the best.
I do not know your experience on network applications, but I'll share the reasons I use release in case there is anything useful.
This will apply to all platforms as far as my experience goes, not specific to NetBurner. First off, the difference between debug and release is mainly code optimization, onboard SRAM usage, and processor instruction/data cache. The reason is that a debugger needs to know all the symbols, and cant work with instructions or data in the cache or fast SRAM. So the application will run much slower. Depending on the application, and what fits in cache and SRAM, dramatically so. The important point is that even doing everything in release mode isn't a big deal. Debug builds do not need to come first. I use the debugger from time to time to troubleshoot a specific problem; I don't use it otherwise. But I know many do. Again, not trying to persuade anyone. As we all know, that does not work on developers anyway
The reason I have landed in my mode of development is that:
- I was tracking down problems I created by halting my application. For a network device, the outside world goes on no matter if I halt my device or not. There are many many timing and timeout issues that occur when I stop or single step my system. More on that later.
- The slower execution speed without optimization created timing problems with peripheral devices when I switched to release mode.
- Memory issues such as buffer overruns or stack overflows seemed to be hidden in debug builds. I have to admit I do not know exactly why on this one, but it has been consistent. I'm guessing this is another optimization related thing. I do know that if I have a memory access error part of my debug procedure is to do a debug build and see if it goes away. If so, I start looking at buffers and auto variables.
- Personally, I think of developing in release mode as additional test time to some extent. Especially with peripheral device and network timing.
If anyone is still with me on this long post, on to the interaction with using any debugger on any network system. The network my device is connected to is alive and well the whole time I am stopped, and networking loves timeouts and retransmissions. Stopping my target at the wrong time can cause it to miss very important things that will interfere with it continuing to run.
- Missing a DHCP renewal, IP address will no longer be valid, and there is the remote possibility your IP address could be reassigned. You now have two devices with the same IP.
- Stopping while TCP sockets are communicating. The other host will retransmit, timeout, or reset. When you start back up, the application now steps through a TCP error condition that I myself created.
- Missing UDP or Multicast packets
- Missing ARP requests so a host that you may be using as part of the test errors out thinking the device IP address does not exist.
- Web browser trying to access the device will generate retries.
All the above happened to me and made it seem my app was flaky, when in fact it was the way I was halting things. I know a lot of developers frown on the serial port, but I use it. There are many important things to me like leaving some in place that can be enabled/disabled at run time so if a unit fails in the field at one particular location I can turn it on and see what is going on. If its a space issue, you can use a #define to include them or not. I think a lot of us were exposed to semiconductor manufacturer development systems that used a jtag to program the device, and things were just left in debug mode by default.
A lot longer than I intended. Sorry about that !
Thank you for sharing all that. It is always interesting to me to learn how developers work. I think we do things similar in developing remote. I have the h/w set up at work, and use remote desktop. That way I don't have to maintain work/home configurations for eclipse, git, etc. I rely heavily on the serial port for status messages, so I have that connected as well.
Every developer has their preferred method, and I'm not trying to convince you of anything, just thought I would throw a few things out there in case its useful. Within our own company our developers run the range: windows, osx, linux, eclipse, vscode, VIM, and one guy with an editor so old I don't know the name of it. I think it used to be called brief at one point.
Regarding debugger stop, terminate, breakpoint, etc., unlike with your jtag debugger, a network debugger needs a running target to perform an application download. So if the target is not running for any reason (halted, repeated system crashes, ...) the download will fail. There are methods to work around that (getchar() or delay at the app start), but I don't want to put too much in one post. Being able to reset is the best.
I do not know your experience on network applications, but I'll share the reasons I use release in case there is anything useful.
This will apply to all platforms as far as my experience goes, not specific to NetBurner. First off, the difference between debug and release is mainly code optimization, onboard SRAM usage, and processor instruction/data cache. The reason is that a debugger needs to know all the symbols, and cant work with instructions or data in the cache or fast SRAM. So the application will run much slower. Depending on the application, and what fits in cache and SRAM, dramatically so. The important point is that even doing everything in release mode isn't a big deal. Debug builds do not need to come first. I use the debugger from time to time to troubleshoot a specific problem; I don't use it otherwise. But I know many do. Again, not trying to persuade anyone. As we all know, that does not work on developers anyway
The reason I have landed in my mode of development is that:
- I was tracking down problems I created by halting my application. For a network device, the outside world goes on no matter if I halt my device or not. There are many many timing and timeout issues that occur when I stop or single step my system. More on that later.
- The slower execution speed without optimization created timing problems with peripheral devices when I switched to release mode.
- Memory issues such as buffer overruns or stack overflows seemed to be hidden in debug builds. I have to admit I do not know exactly why on this one, but it has been consistent. I'm guessing this is another optimization related thing. I do know that if I have a memory access error part of my debug procedure is to do a debug build and see if it goes away. If so, I start looking at buffers and auto variables.
- Personally, I think of developing in release mode as additional test time to some extent. Especially with peripheral device and network timing.
If anyone is still with me on this long post, on to the interaction with using any debugger on any network system. The network my device is connected to is alive and well the whole time I am stopped, and networking loves timeouts and retransmissions. Stopping my target at the wrong time can cause it to miss very important things that will interfere with it continuing to run.
- Missing a DHCP renewal, IP address will no longer be valid, and there is the remote possibility your IP address could be reassigned. You now have two devices with the same IP.
- Stopping while TCP sockets are communicating. The other host will retransmit, timeout, or reset. When you start back up, the application now steps through a TCP error condition that I myself created.
- Missing UDP or Multicast packets
- Missing ARP requests so a host that you may be using as part of the test errors out thinking the device IP address does not exist.
- Web browser trying to access the device will generate retries.
All the above happened to me and made it seem my app was flaky, when in fact it was the way I was halting things. I know a lot of developers frown on the serial port, but I use it. There are many important things to me like leaving some in place that can be enabled/disabled at run time so if a unit fails in the field at one particular location I can turn it on and see what is going on. If its a space issue, you can use a #define to include them or not. I think a lot of us were exposed to semiconductor manufacturer development systems that used a jtag to program the device, and things were just left in debug mode by default.
A lot longer than I intended. Sorry about that !
Re: Reattach debugger after terminate fails
Thanks for all that, not too long I appreciate the responsiveness. I familiar with most of what you said. Not to tip my age but brief was an excellent editor I did use back in a day. I do try to keep up, as impossible as that is, which is one reason why I try and insist on good debugger.
Back to the main topic though. I think what you said about pause program may be the main issue. I have been making sure it is running and then I do a Terminate/Disconnect All. This seems more repeatable/reliable but will keep the reset connected.
Thanks again, I'm sure we will interact again on other threads/topics as I progress.
Back to the main topic though. I think what you said about pause program may be the main issue. I have been making sure it is running and then I do a Terminate/Disconnect All. This seems more repeatable/reliable but will keep the reset connected.
Thanks again, I'm sure we will interact again on other threads/topics as I progress.