cancel
Showing results for 
Search instead for 
Did you mean: 

Can JTAG be broken by SW ?

krk
Associate II
Posted on December 22, 2009 at 11:32

Can JTAG be broken by SW ?

6 REPLIES 6
krk
Associate II
Posted on May 17, 2011 at 13:33

Hi all,

I am new within the STM32 so forgive me my question 😉 I am using the Olimex STM32-P103 board ( STM32F103RBT6 ) with an ARM-USB-TINY JTAG adapter and the Rowley CrossWorks IDE.

My ''Hello World'' programs work well when I start them using JTAG. But they do not start after a power/off/on reset.

Now I found the following comment within STM32_Startup.s asm file delivered with the CrossWorks IDE:

snip

* STARTUP_FROM_RESET

*

* If defined, the program will startup from power-on/reset. If not defined

* the program will just loop endlessly from power-on/reset.

*

* This definition is not defined by default on this target because the

* debugger is unable to reset this target and maintain control of it over the

* JTAG interface. The advantage of doing this is that it allows the debugger

* to reset the CPU and run programs from a known reset CPU state on each run.

* It also acts as a safety net if you accidently download a program in FLASH

* that crashes and prevents the debugger from taking control over JTAG

* rendering the target unusable over JTAG. The obvious disadvantage of doing

* this is that your application will not startup without the debugger.

*

* We advise that on this target you keep STARTUP_FROM_RESET undefined whilst

* you are developing and only define STARTUP_FROM_RESET when development is

* complete.

snip

To make it short. If I set the macro everything works like expected and the controller does start after power/off/on reset without JTAG needed. But I am unsure:

- Is it really possible to break JTAG connectivity to the device if the flashed program is buggy ?

- When I design a board with STM32F103RBT6 is it sufficient to have the JTAG interface available for programming AND / OR do I need access to usart bootloader ?

tomas23
Associate II
Posted on May 17, 2011 at 13:33

The comment, in short, warns you that the debugger cannot stop the program immediately at the point, where it wants, after reset - that's why, for debug purposes, the CPU waits in a loop, that can be ''jumped over'' by debugger (and you can remove this wait loop by publishing the macro)

Concerning JTAG disable, it's possible in SW (see AFIO->MAPR register) or by entering STOP mode. But Cortex-M3 is equipped with feature ''debug under reset'' (don't know if your tool knows it), and this can stop the CPU BEFORE jumping to first instruction, so you can avoid dead-locking. I know Keil uLink2 knows this method of driving breakpoints.

Concerning programming, any option is possible. Be aware that implementing UART programming requires access to BOOT0 and BOOT1 pin logic levels.

akaiser9
Associate II
Posted on May 17, 2011 at 13:33

To be able to start a flashed program without control of the debugger, STARTUP_FROM_RESET must be defined.

Since this text in the startup file was written by Rowley, it is likely that the mentioned ''debug under reset'' feature is not known to Rowley.

To be able to both debug a program right from reset and run it without debugger, it should be sufficient to replace the infinite loop right after reset by a finite delay loop.

If your board makes JTAG available, you do not need a connection for a bootloader. However I'd recommend to make the RX/TX pins of the primary UART, BOOT0 and RESET available on a connector, to be able to use a bootloader later.

[ This message was edited by: prx on 11-12-2009 17:38 ]

krk
Associate II
Posted on May 17, 2011 at 13:33

Thanks for your answers. I now looked around for a while but did not find any information if Rowley does support the ''debug under reset'' feature. Is this feature only part of the debugger or also a feature from the used JTAG adapter ?

picguy
Associate II
Posted on May 17, 2011 at 13:33

Yes, it is possible to break JTAG connectivity to the device if the flashed program is buggy. The JTAG pins can be taken over under software control. If you have enough pins you are better off not using these pins in your application.

Read The Fine Manual. This is especially important to one who is new to the product. RM0008 is still under 1K pages. I found the details of injected channel ADC to be an excellent soporific. But try to read all 995 pages through once anyway. Then pay special attention to GPIO in general and specific attention to JTAG pins and alternate GPIO pin functions. A few months debugging will save you a few days reading the manual.

The following personal story shows a related problem and its solution.

Due to my error I ended up with a stopped CPU clock shortly after reset. (It was on another company’s Cortex-M3 demo board.) Without CPU clocking the debugger on the demo board could not proceed. I had to spend another $49+s/h to recover. I then wrote a bit of code that waited for the push button on the demo board to be UNpressed before messing around with clocking. I.e. no matter how badly I messed up the clock I could still get to the debugger by resetting with the button depressed.

mcuisp
Associate II
Posted on May 17, 2011 at 13:33

if you had connect NRST PIN out, then nothing will lock your chip.