> Those Luminary parts have errata sheets that are a mile long -- and
> clearly not all of the problems are benign.
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.
> Fortunately, I'm only using this part in a 1-off prototype (for the real
> deal I'm switching to an ST part).
Yeah, you'll be wanting to read the erratas of those parts very
carefully as well.
-a
Reply by Tim Wescott●April 27, 20122012-04-27
On Thu, 26 Apr 2012 12:35:44 -0500, Tim Wescott wrote:
> 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 -- www.chipquik.com), 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.
>
> @#$%
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 by Ulf Samuelsson●April 27, 20122012-04-27
On 2012-04-26 19:35, Tim Wescott wrote:
> 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 -- www.chipquik.com), 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
>
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.
> and all is well. And, I have a spare processor in case I do anything
> more stupid.
>
> @#$%
>
BR
Ulf Samuelsson
Reply by David Brown●April 27, 20122012-04-27
On 26/04/2012 20:13, linnix wrote:
> On Apr 26, 10:35 am, Tim Wescott<t...@seemywebsite.com> wrote:
>> 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 --www.chipquik.com), 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.
>
> 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.
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 by scrts●April 27, 20122012-04-27
> and all is well. And, I have a spare processor in case I do anything
> more stupid.
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 by David T. Ashley●April 26, 20122012-04-26
On Thu, 26 Apr 2012 12:35:44 -0500, Tim Wescott <tim@seemywebsite.com>
wrote:
>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 -- www.chipquik.com), 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.
>
>@#$%
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:
http://www.mail-archive.com/openocd-development@lists.berlios.de/msg12451.html
<QUOTE>
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.
</QUOTE>
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 by John Devereux●April 26, 20122012-04-26
linnix <me@linnix.info-for.us> writes:
> On Apr 26, 10:35 am, Tim Wescott <t...@seemywebsite.com> wrote:
>> 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 --www.chipquik.com), 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.
>
> 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.
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
>On Apr 26, 10:35�am, Tim Wescott <t...@seemywebsite.com> wrote:
>> 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 --www.chipquik.com), 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.
>
>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.
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 by linnix●April 26, 20122012-04-26
On Apr 26, 10:35=A0am, Tim Wescott <t...@seemywebsite.com> wrote:
> 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. =A0It 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! =A0No JTAG.
>
> Totally f'ing great. =A0Oh 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. =A0Will 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 --www.chipquik.com), 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. =A0Of
> course, *TRST goes to port B, so when I execute this line:
>
> =A0 GPIOB.DEN =A0 =A0=3D MASK_BIT_3; =A0 =A0 // 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
>
> =A0 GPIOB.DEN =A0 |=3D MASK_BIT_3; =A0 =A0 // Digital enable
>
> and all is well. =A0And, I have a spare processor in case I do anything
> more stupid.
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 by Tim Wescott●April 26, 20122012-04-26
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 -- www.chipquik.com), 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