2
\$\begingroup\$

I'm rather unexperienced on the field of microcontrollers, I come from a Java background so the question might seem a bit noob but I didn't find much information on this.

So is it possible to debug an STM32F4 board via bluetooth (using eclipse or some othe IDE)? And if so could you send me some links that might help? We're building a robotic car controlled by a discovery board and debugging using an USB cable is not really an option if we don't want to disassemble the whole stuff every time something goes wrong. Hence this would really come in handy. So any help is appreciated

\$\endgroup\$
3
\$\begingroup\$

I highly recommend printf debugging for these sorts of applications. It takes a while to get the hang of, but it is a very powerful tool as all you need is a serial port and it doesn't interrupt the flow of the program. I did breakpoint debugging for a while on a robotics project and it was a real pain. The way the motor drive code was written, when you hit a breakpoint, the motors didn't stop so someobody would have to go grab the robot so it didn't crash. You don't have this issue with printf debugging. A pair of XBee modules was sufficient to get the serial data to a computer for review. It should be possible with bluetooth as well, but that also involves more overhead in terms of getting the modules configured correctly and paired with your computer.

\$\endgroup\$
  • 2
    \$\begingroup\$ I never got the hang of breakpoint-style debugging, and I can't imagine it beging much use for any time-critical or event-interaction type of process. In my experience printf (or rather std::cout, because I prefer C++) is THE way to go for those type of systems. \$\endgroup\$ – Wouter van Ooijen Nov 10 '13 at 20:10
  • \$\begingroup\$ Wow, I didn't really think about things like what stops the motors... Hm, your right I guess it's just not the right tool for the job. Thanks for the heads-up. \$\endgroup\$ – Peter Nov 10 '13 at 21:21
  • 2
    \$\begingroup\$ Breakpoint style debugging requires a debugger, compiler support for the debugger, the correct interface cable to the target, lots of configuration, etc. etc. And it's highly intrusive and can cause strange issues with peripherals. It's not too bad for high level code running on a PC, but for real time stuff it's crap. For real time stuff, passive instrumentation is the way to go. I have even used a logic analyzer to trace code execution before because it's less intrusive than a debugger. \$\endgroup\$ – alex.forencich Nov 11 '13 at 0:42
  • \$\begingroup\$ A good exampe is, if your MCU has USB and you hit a breakpoint, it'll break the USB comms (USB has regular keepalives). There are actually a bunch of Atmel app-notes about how interactive debugging cannot be used on devices with USB interfaces. \$\endgroup\$ – Connor Wolf Nov 11 '13 at 11:26
  • \$\begingroup\$ @Wouter van Ooijen: It really depends, I worked on some event based stuff and inserting printf was just slowing the system too much. With breakpoints you have the option to continue the program immediately after the breakpoint was reached and just get notified it was reached. \$\endgroup\$ – Étienne Nov 23 '13 at 11:11
2
\$\begingroup\$

I guess the iSYSTEM iONE.BT could be something you could use. It supports debugging in Eclipse.

I would put some of these in comments but my reputation is not high enough.

I never (very rarely) use printf debugging. By my experience it has quite an impact on performance and design. E.g. values formatting and serialization over communication interface take their toll. Also you need standard libs and minimal system calls implementation (-lnosys won't do in GCC) which you might not need in your firmware. Additionally the context with debugger is so much richer than with printf.

There is of course the fear of unpredictable peripherals behavior on stop. However, STM has configurable peripherals behavior when CPU is stopped. Each peripheral can be stopped with CPU or left running. iSYSTEM tools support the common configuration of these. I used iSYSTEM's free iTAG debugger with my STM USB reference project and had no problems with USB while stopping the CPU.

Additionally professional tools support scripting which can be used to configure your peripherals when CPU is stopped. E.g. Python script poling run status and apply changes (with memory writes, short monitor executions etc.) on stop and run.

One more thing - you might need to test and/or verify your code. This can't be done with instrumentation. Instrumentation basically means changing your code for debug purposes. But release FW without printfs is not the same as tested debug version with them. Or you could leave printfs in release FW :).

I recommend C over C++ for embedded projects. C++ needs more resources than C. Compilers need not to know anything about the debugger. It’s the other way around. You won’t be able to trace over wireless because there is not enough bandwidth. Although, I’d leave trace pins (if available on your package) free in case you'd want to connect trace port analyzer tool sometime in the future.

\$\endgroup\$
1
\$\begingroup\$

There is a bluetooth debugger available for Cortex-M. There was an article published about it on embedded.com a short while ago : http://www.embedded.com/electronics-products/electronic-product-reviews/debug-and-optimization/4422586/iSYSTEM-introduces-wireless-debugger

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.