0
\$\begingroup\$

The software app being developed runs on the embedded hardware and spits the debug output through a serial port during various functionality of the app. Following are the questions.

  1. Can I use the JTAG interface to the MCU in testing the app flashed on to it ?

  2. Is there a way to automate testing especially for regression testing?

I am currently thinking of creating an app that looks for the debug output over the serial and scans for various sentences spitted out? Is this a good idea.

Any ideas pertaining to this topic will be appreciated.

\$\endgroup\$
  • \$\begingroup\$ What processor? What debugging/programming tools do you have? \$\endgroup\$ – Tut Oct 8 '13 at 20:34
  • \$\begingroup\$ STM32F4 processor /ST link JTAG probe \$\endgroup\$ – Jack John Oct 8 '13 at 20:38
1
\$\begingroup\$

Using JTAG allow you to take full control over the MCU. Depending on MCU hardware settings (see pin BOOT0 description for STM32F4), the MCU will decide if

  1. It will read the content of the application stored in flash into MCU's RAM. Then execute jumps to the beginning of the RAM address. This is the normal bootloading process, for final application.
  2. It will receive the content of the application through the JTAG into MCU's RAM. Then execute jumps to the beginning of the RAM address. This is the debugging/hacking process.

So, my answer to your question

Can I use the JTAG interface to the MCU in testing the app flashed on to it ?

is No. You can't. But you can test the app that will be finally flashed to it with JTAG, and then flash it once you're happy with it.

Is there a way to automate testing especially for regression testing?

Sure, many ways but it really depends on your application. Consider a simple APP that will take INPUT data (from sensors for example) to produce OUTPUT data (LED lighting for example).

For non-regression testing it is a good idea to have a library of INPUT test data, for which you know the expected OUTPUT results. The main challenge there is how you could send the INPUT test data in place of the sensors. And this will depends on you application.

I suggest you to take the non-regression testing as a requirement of your embedded application, and consider an architecture where you could easily switch the INPUT data receiver from JTAG input to actual sensors.

\$\endgroup\$
  • \$\begingroup\$ You are mistaken - JTAG/SWD gives you the ability to interact with code stored in flash as well as that stored in RAM. It's also often possibly to construct a scheme for recovering debug messages using mailboxes. \$\endgroup\$ – Chris Stratton Oct 9 '13 at 17:21
  • \$\begingroup\$ @Chris Thanks for your comment. Yes JTAG gives you the ability to interact with flash content. But the question was: Can I use the JTAG interface to the MCU in testing the app flashed on to it ? and not Can I use JTAG to interact with code stored in flash, which makes a bit difference INMHO. \$\endgroup\$ – RawBean Oct 10 '13 at 6:26
  • \$\begingroup\$ The answer would be Yes, because they are basically the same question. If you still think they are not, then define what specifically you mean by "testing" which you doubt that jtag debug extensions can do. \$\endgroup\$ – Chris Stratton Oct 10 '13 at 11:51
  • \$\begingroup\$ According to me "testing" the app flashed into it using JTAG means booting on the Flash, and then taking control on the MCU thanks to JTAG. If I'm missing something please tell me, but I think that once the MCU is running, you could not take control with JTAG without resetting it. And once you reset it so as to make it boot on JTAG, the app in the flash is gone away. \$\endgroup\$ – RawBean Oct 11 '13 at 8:27
  • \$\begingroup\$ You ordinarily can take control of it without resetting it - in order to do breakpoint debugging, examine the state it has gotten into, recover messages from a known memory buffer, etc. This could be used to read the result of tests, or with a bit more effort, change state to trigger tests. Often software remote debug tools by default command a reset as soon as they connect, but the hardware doesn't typically require that and there are ways to change that behavior. \$\endgroup\$ – Chris Stratton Oct 11 '13 at 14:30

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.