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\$
2
  • \$\begingroup\$ What processor? What debugging/programming tools do you have? \$\endgroup\$
    – Tut
    Commented Oct 8, 2013 at 20:34
  • \$\begingroup\$ STM32F4 processor /ST link JTAG probe \$\endgroup\$
    – Jack John
    Commented Oct 8, 2013 at 20:38

1 Answer 1

Reset to default
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\$
5
  • \$\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
    Commented Oct 9, 2013 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
    Commented Oct 10, 2013 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
    Commented Oct 10, 2013 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
    Commented Oct 11, 2013 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
    Commented Oct 11, 2013 at 14:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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