Gawd I love ARM JTAG

TI/Luminary LM3S8971.

Went to do some upgrades in my startup code, in the function called -- ironically enough -- "escape_hatch", which is the VERY FIRST THING that gets run. It spins on a pressed button so if something downstream like PLL setup or I/O port stuff messes up JTAG, I can still get in with the JTAG debugger and figure out what's happening and program flash and whatnot.

The first time it runs, I step through the code up to what I thought would be a totally safe statement, and -- BAM! No JTAG.

Totally f'ing great. Oh loverly.

It's a proto board from DigiKey for a project that's going to use a different processor, so I don't even have spares. Will joy never cease.

Order parts.

Wait.

Get parts, then when the need for the board comes around on the guitar, unhook the board from all the umbilici connecting it into the breadboarded project, remove the chip (ChipQuik is great stuff, by the way --

formatting link
put on the new one, PUT AN INFINITE LOOP INTO MY F'ING ESCAPE HATCH FUNCTION, and debug.

All of the lines from the JTAG header on this board goes to port C. Of course, *TRST goes to port B, so when I execute this line:

GPIOB.DEN = MASK_BIT_3; // Digital enable

it TURNS OFF THE F'ING JTAG TRST PIN, which disables the whole shebang. It just makes me feel so good I want to throw tools through the walls.

But, I only consumed one processor finding my bug, and now the line reads

GPIOB.DEN |= MASK_BIT_3; // Digital enable

and all is well. And, I have a spare processor in case I do anything more stupid.

@#$%

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
Reply to
Tim Wescott
Loading thread data ...

.

Yes, i always wonder why ARM has only one program/debug port (JTAG, SWD version of JTAG) and it can be disabled. AVR (SPI, JTAG, etc) and PIC (multiple ICSPs) have multiple ports. I guess ARM expect prefect codes in first trial.

Reply to
linnix

I don't know about all ARMs but the NXP2000-series certainly has a built-in serial bootloader that I've used a couple of times. Pretty sure it's also on their NXP1000 CM3s. Also, ST's STM32F chips have one, although I've never had occasion to use it.

JTAG (and SWD) is (are) just so danged handy that it's easy to neglect to take the time to set up for a serial bootloader session. I'm guilty, myself. Never bothered to install NXP's serial loader application on this box and I'd have to search out (or write?!) an app to talk to ST's.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

The ARMs I have used have multiple ports too. Which one gets used depends on the power-up state of a pin (or two). I have done exactly what Tim did (write a whole port instead of one bit, losing JTAG). The solution was to pull the BOOT pin high and reset, which makes the processor wait in a loop looking for UART characters. You can then regain control with JTAG.

--

John Devereux
Reply to
John Devereux

If I'm understanding the scenario correctly, several ARM parts provide a sequence for you to save yourself if you disable JTAG.

From this URL:

formatting link
snipped-for-privacy@lists.berlios.de/msg12451.html

Stellaris chips have a procedure for restoring the chip to what's effectively the "as-manufactured" state, with all the non-volatile memory erased. That includes all flash memory, plus things like the flash protection bits and various control words which can for example disable debugger access. clearly, this can be useful during development.

Luminary/TI provides an MS-Windows utility to perform this procedure along with its Stellaris developer kits. Now OpenOCD users will no longer need to use that MS-Windows utility.

This probably applies to your part as well. It is likely in the manufacturer's data sheet.

Please let me know if the information I've provided is on target.

I'm just getting started using the TI Stellaris parts myself, so I've never locked up JTAG but I may in the future.

Any info you provide will be carefully scrutinized for anything that can help me ...

DTA

Reply to
David T. Ashley

TI offers special software, which takes the CPU back to life. It was created in case of the problem, when JTAG pins are turned to GPIO pins.

Reply to
scrts

In theory, the AVR has SPI and JTAG - and using the SPI interface you can disable JTAG, and using the JTAG interface you can disable SPI. In practice, however, it /is/ possible to use the SPI interface to completely incapacitate the chip. All you need to do is send the SPI programming commands bit-reversed (a minor bug in some automated programming software I wrote...).

Reply to
David Brown

There are ARM parts there which does not multiplex the debug I/O ports with I/O, and some people think this is a disadvantage since they lose the pins.

BR Ulf Samuelsson

Reply to
Ulf Samuelsson

Postscript:

After getting my processor in, I started having all sorts of really strange behavior. At first I thought it was me, because I'd been doing a bunch of changes to the code without going back to the well for testing.

But, nooooooo.

It turns out that the TI/Luminary part that I'm using has a PLL that doesn't work right if you use the 2.5V supply at 2.5V -- you have to amp it up to 2.75V (in software). Those Luminary parts have errata sheets that are a mile long -- and clearly not all of the problems are benign.

Fortunately, I'm only using this part in a 1-off prototype (for the real deal I'm switching to an ST part). Also fortunately, I have a quite vocal customer who, in conversation, mentioned the length and seriousness of the Luminary errata, which both made me change to the ST in the first place, and made me think of looking there to find this problem.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
Reply to
Tim Wescott

They can be sneaky about it too. At least in the past they've periodically updated the datasheets to integrate the items, which isn't bad in and of itself, but they've then removed those items from the errata lists which is a right pain when you go grab a new version and suddenly notice the list has been cut in half.

Yeah, you'll be wanting to read the erratas of those parts very carefully as well.

-a

Reply to
Anders.Montonen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.