I just replaced the "-O0" in my makefile with "-O3", and as soon as the code ran the JTAG debugger stopped working -- it reports "all ones" on the JTAG chain when it tries to connect. Gnu tool chain. Has anyone had this happen? Any clues on how to get functionality back? I suspect that I just need to replace the chip -- but that's a pain in the backside, and I don't want to do it too many times!! I'm going to put an escape hatch in the software, probably to come on before anything else at all is alive, but better ideas are welcome. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Luminary JTAG disabled by optimizations? WTF??
Started by ●July 6, 2011
Reply by ●July 6, 20112011-07-06
On 7/6/2011 2:32 PM, Tim Wescott wrote:> I just replaced the "-O0" in my makefile with "-O3", and as soon as the > code ran the JTAG debugger stopped working -- it reports "all ones" on > the JTAG chain when it tries to connect. > > Gnu tool chain. > > Has anyone had this happen? Any clues on how to get functionality back? > I suspect that I just need to replace the chip -- but that's a pain in > the backside, and I don't want to do it too many times!! I'm going to > put an escape hatch in the software, probably to come on before anything > else at all is alive, but better ideas are welcome. >Haven't played any with the Luminary chips, but I know that on the NXP Cortex M3s there's a problem where if you get the PLL misconfigured it would break the JTAG link. Meaning if you flashed in code that broke the PLL, you can't get it back. It's possible (?) that the Luminary parts have a similar flaw, and that optimization broke your PLL init code, maybe. On the NXPs, one of the pins doubles as a service boot mode pin that could be used in a pinch to get you out of that particular jam. No idea whether any of this correlates to the Luminary. -- Rob Gaddi, Highland Technology Email address is currently out of order
Reply by ●July 6, 20112011-07-06
On 07/06/2011 02:55 PM, Rob Gaddi wrote:> On 7/6/2011 2:32 PM, Tim Wescott wrote: >> I just replaced the "-O0" in my makefile with "-O3", and as soon as the >> code ran the JTAG debugger stopped working -- it reports "all ones" on >> the JTAG chain when it tries to connect. >> >> Gnu tool chain. >> >> Has anyone had this happen? Any clues on how to get functionality back? >> I suspect that I just need to replace the chip -- but that's a pain in >> the backside, and I don't want to do it too many times!! I'm going to >> put an escape hatch in the software, probably to come on before anything >> else at all is alive, but better ideas are welcome. >> > > Haven't played any with the Luminary chips, but I know that on the NXP > Cortex M3s there's a problem where if you get the PLL misconfigured it > would break the JTAG link. Meaning if you flashed in code that broke the > PLL, you can't get it back. > > It's possible (?) that the Luminary parts have a similar flaw, and that > optimization broke your PLL init code, maybe. On the NXPs, one of the > pins doubles as a service boot mode pin that could be used in a pinch to > get you out of that particular jam. No idea whether any of this > correlates to the Luminary. >I've been down that particular road before, but it's not happening -- my last software load is in there and talking on the serial ports. So not only is the PLL not broken, but it's going the right speed. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●July 6, 20112011-07-06
On Jul 6, 2:56=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:> On 07/06/2011 02:55 PM, Rob Gaddi wrote: > > > > > > > > > On 7/6/2011 2:32 PM, Tim Wescott wrote: > >> I just replaced the "-O0" in my makefile with "-O3", and as soon as th=e> >> code ran the JTAG debugger stopped working -- it reports "all ones" on > >> the JTAG chain when it tries to connect. > > >> Gnu tool chain. > > >> Has anyone had this happen? Any clues on how to get functionality back=?> >> I suspect that I just need to replace the chip -- but that's a pain in > >> the backside, and I don't want to do it too many times!! I'm going to > >> put an escape hatch in the software, probably to come on before anythi=ng> >> else at all is alive, but better ideas are welcome. > > > Haven't played any with the Luminary chips, but I know that on the NXP > > Cortex M3s there's a problem where if you get the PLL misconfigured it > > would break the JTAG link. Meaning if you flashed in code that broke th=e> > PLL, you can't get it back. > > > It's possible (?) that the Luminary parts have a similar flaw, and that > > optimization broke your PLL init code, maybe. On the NXPs, one of the > > pins doubles as a service boot mode pin that could be used in a pinch t=o> > get you out of that particular jam. No idea whether any of this > > correlates to the Luminary. > > I've been down that particular road before, but it's not happening -- my > last software load is in there and talking on the serial ports. =A0So not > only is the PLL not broken, but it's going the right speed. >Check to make sure you are not accidentally re-assigning the JTAG pins to GPIO. Port B & C are shared with JTAG/SWD. Yes, escape pin (skip init if grounded) is a good idea, if you have to use port B & C.
Reply by ●July 6, 20112011-07-06
On 07/06/2011 03:12 PM, linnix wrote:> On Jul 6, 2:56 pm, Tim Wescott<t...@seemywebsite.com> wrote: >> On 07/06/2011 02:55 PM, Rob Gaddi wrote: >> >> >> >> >> >> >> >>> On 7/6/2011 2:32 PM, Tim Wescott wrote: >>>> I just replaced the "-O0" in my makefile with "-O3", and as soon as the >>>> code ran the JTAG debugger stopped working -- it reports "all ones" on >>>> the JTAG chain when it tries to connect. >> >>>> Gnu tool chain. >> >>>> Has anyone had this happen? Any clues on how to get functionality back? >>>> I suspect that I just need to replace the chip -- but that's a pain in >>>> the backside, and I don't want to do it too many times!! I'm going to >>>> put an escape hatch in the software, probably to come on before anything >>>> else at all is alive, but better ideas are welcome. >> >>> Haven't played any with the Luminary chips, but I know that on the NXP >>> Cortex M3s there's a problem where if you get the PLL misconfigured it >>> would break the JTAG link. Meaning if you flashed in code that broke the >>> PLL, you can't get it back. >> >>> It's possible (?) that the Luminary parts have a similar flaw, and that >>> optimization broke your PLL init code, maybe. On the NXPs, one of the >>> pins doubles as a service boot mode pin that could be used in a pinch to >>> get you out of that particular jam. No idea whether any of this >>> correlates to the Luminary. >> >> I've been down that particular road before, but it's not happening -- my >> last software load is in there and talking on the serial ports. So not >> only is the PLL not broken, but it's going the right speed. >> > > Check to make sure you are not accidentally re-assigning the JTAG pins > to GPIO. Port B& C are shared with JTAG/SWD. Yes, escape pin (skip > init if grounded) is a good idea, if you have to use port B& C. >The weird thing is that this happened after I changed the optimization flag on the compiler -- I didn't touch the code. Granted, I _was_ half expecting to break something, or at least make debugging difficult. I _wasn't_ expecting to mess up with JTAG!! -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●July 6, 20112011-07-06
In article <T-udnXVh9cL8d4nTnZ2dnUVZ_rKdnZ2d@web-ster.com>, Tim Wescott <tim@seemywebsite.com> wrote:>The weird thing is that this happened after I changed the optimization >flag on the compiler -- I didn't touch the code. > >Granted, I _was_ half expecting to break something, or at least make >debugging difficult. I _wasn't_ expecting to mess up with JTAG!!If I had to guess, I'd guess that maybe there's a variable declaration somewhere (e.g. for a memory-mapped register) which is missing a "volatile" clause, or there are some accesses to the JTAG registers which need explicit memory-barrier instructions/calls in place. In this situation, turning on code optimization might have caused the compiler to either optimize away certain stores or reads which it considered to be redundant, or might have caused stores or reads to be re-ordered in a way which breaks the logic. Dump out the generated machine code for your JTAG setup and access logic, for the non-optimized and fully-optimized cases. I think you'll find a smoking absence-of-a-gun in the optimized case (i.e. "missing" or reorganized instructions or accesses, which would have no ill effect on the semantics if the variables were normal memory locations, but foul things up badly for memory-mapped I/O registers). -- Dave Platt <dplatt@radagast.org> AE6EO Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior I do _not_ wish to receive unsolicited commercial email, and I will boycott any company which has the gall to send me such ads!
Reply by ●July 7, 20112011-07-07
On Wed, 06 Jul 2011 16:17:04 -0700, Dave Platt wrote:> In article <T-udnXVh9cL8d4nTnZ2dnUVZ_rKdnZ2d@web-ster.com>, Tim Wescott > <tim@seemywebsite.com> wrote: > >>The weird thing is that this happened after I changed the optimization >>flag on the compiler -- I didn't touch the code. >> >>Granted, I _was_ half expecting to break something, or at least make >>debugging difficult. I _wasn't_ expecting to mess up with JTAG!! > > If I had to guess, I'd guess that maybe there's a variable declaration > somewhere (e.g. for a memory-mapped register) which is missing a > "volatile" clause, or there are some accesses to the JTAG registers > which need explicit memory-barrier instructions/calls in place. > > In this situation, turning on code optimization might have caused the > compiler to either optimize away certain stores or reads which it > considered to be redundant, or might have caused stores or reads to be > re-ordered in a way which breaks the logic. > > Dump out the generated machine code for your JTAG setup and access > logic, for the non-optimized and fully-optimized cases. I think you'll > find a smoking absence-of-a-gun in the optimized case (i.e. "missing" or > reorganized instructions or accesses, which would have no ill effect on > the semantics if the variables were normal memory locations, but foul > things up badly for memory-mapped I/O registers).The problem is that the software can't do anything with JTAG (except break it). JTAG is a hardware function that can have its pins stolen by software, but which software cannot otherwise touch. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●July 7, 20112011-07-07
On 07/07/2011 01:05, Tim Wescott wrote:> On 07/06/2011 03:12 PM, linnix wrote: >> On Jul 6, 2:56 pm, Tim Wescott<t...@seemywebsite.com> wrote: >>> On 07/06/2011 02:55 PM, Rob Gaddi wrote: >>> >>> >>> >>> >>> >>> >>> >>>> On 7/6/2011 2:32 PM, Tim Wescott wrote: >>>>> I just replaced the "-O0" in my makefile with "-O3", and as soon as >>>>> the >>>>> code ran the JTAG debugger stopped working -- it reports "all ones" on >>>>> the JTAG chain when it tries to connect. >>> >>>>> Gnu tool chain. >>> >>>>> Has anyone had this happen? Any clues on how to get functionality >>>>> back? >>>>> I suspect that I just need to replace the chip -- but that's a pain in >>>>> the backside, and I don't want to do it too many times!! I'm going to >>>>> put an escape hatch in the software, probably to come on before >>>>> anything >>>>> else at all is alive, but better ideas are welcome. >>> >>>> Haven't played any with the Luminary chips, but I know that on the NXP >>>> Cortex M3s there's a problem where if you get the PLL misconfigured it >>>> would break the JTAG link. Meaning if you flashed in code that broke >>>> the >>>> PLL, you can't get it back. >>> >>>> It's possible (?) that the Luminary parts have a similar flaw, and that >>>> optimization broke your PLL init code, maybe. On the NXPs, one of the >>>> pins doubles as a service boot mode pin that could be used in a >>>> pinch to >>>> get you out of that particular jam. No idea whether any of this >>>> correlates to the Luminary. >>> >>> I've been down that particular road before, but it's not happening -- my >>> last software load is in there and talking on the serial ports. So not >>> only is the PLL not broken, but it's going the right speed. >>> >> >> Check to make sure you are not accidentally re-assigning the JTAG pins >> to GPIO. Port B& C are shared with JTAG/SWD. Yes, escape pin (skip >> init if grounded) is a good idea, if you have to use port B& C. >> > The weird thing is that this happened after I changed the optimization > flag on the compiler -- I didn't touch the code. > > Granted, I _was_ half expecting to break something, or at least make > debugging difficult. I _wasn't_ expecting to mess up with JTAG!! >It would be worth taking a step back and treating the compiler flag changes as a coincidence. What then could have caused the JTAG to stop working? Go through the usual suspects (power spikes, static, bits of wire under the board, Windows playing silly buggers with USB drivers, etc.).
Reply by ●July 7, 20112011-07-07
Tim Wescott <tim@seemywebsite.com> writes:> I just replaced the "-O0" in my makefile with "-O3", and as soon as > the code ran the JTAG debugger stopped working -- it reports "all > ones" on the JTAG chain when it tries to connect. > > Gnu tool chain. > > Has anyone had this happen? Any clues on how to get functionality > back?I have had similar things happen on other chips - usually it's because I broke the PLL setup or, last time, assigned the JTAG pins to other functions by mistake :) You may be able to tell the CPU to enter a different boot mode by pulling a pin low etc. It will then typically crash or wait in some loop, but at least it won't execute the code of death you have put there somehow :)> I suspect that I just need to replace the chip -- but that's a > pain in the backside, and I don't want to do it too many times!! I'm > going to put an escape hatch in the software, probably to come on > before anything else at all is alive, but better ideas are welcome.I don't know if you are using openocd? On NXP parts it is in fact possible to stop at the internal (boot code) reset vector, although the standard config files assume you cannot so they instead always run your code for some programmed time. You might want to look into this aspect with your own parts. -- John Devereux
Reply by ●July 7, 20112011-07-07
On Thu, 07 Jul 2011 13:21:00 +0100, John Devereux <john@devereux.me.uk> wrote:>Tim Wescott <tim@seemywebsite.com> writes: > >> I just replaced the "-O0" in my makefile with "-O3", and as soon as >> the code ran the JTAG debugger stopped working -- it reports "all >> ones" on the JTAG chain when it tries to connect. >> >> Gnu tool chain. >> >> Has anyone had this happen? Any clues on how to get functionality >> back? > >I have had similar things happen on other chips - usually it's because I >broke the PLL setup or, last time, assigned the JTAG pins to other >functions by mistake :) > >You may be able to tell the CPU to enter a different boot mode by >pulling a pin low etc. It will then typically crash or wait in some >loop, but at least it won't execute the code of death you have put there >somehow :) > >> I suspect that I just need to replace the chip -- but that's a >> pain in the backside, and I don't want to do it too many times!! I'm >> going to put an escape hatch in the software, probably to come on >> before anything else at all is alive, but better ideas are welcome. > >I don't know if you are using openocd? On NXP parts it is in fact >possible to stop at the internal (boot code) reset vector, although the >standard config files assume you cannot so they instead always run your >code for some programmed time. You might want to look into this aspect >with your own parts.It may also help to try a different burner environment. I had one LPC2k-series chip where I neglected to check whether a JTAG adapter was plugged in before enabling the watchdog. The watchdog reset time was faster than some cycle time under JTAG so it would always reset before I could get new code onto it. Bummer. But, I also had a Scarabeus JTAG dongle (from Kristech.eu, old, no longer available) and it was able to get in and get control fast enough to save the day. Something to try there's a different debugger/loader or JTAG dongle available. -- Rich Webb Norfolk, VA
