openocd-user

[OpenOCD-user] LPC1857 reset problem

[Dominic R. <Dom...@gm...>]

Dear List,

I'm currently trying to get OpenOCD (git master) to work with a
LPC1857 on a Keil MCB1800 using a Olimex ARM-USB-OCD-H.

I'm using a config file based on the lpc1850_spifi_generic.cfg
example, with additional flash banks for the internal flash.

Basic debugging works (halt, resume etc.), including flashing,
but unfortunately I'm unable to reset the board via OpenOCD.

I've attached two -d3 logs and the config file I'm using,
OpenOCD is started like this:

openocd -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -f 
mcb1800_lpc1857.cfg -d3

Basically the board is unusable after I tried to reset until I
use the reset button on the board

Let me know if some information about my setup is missing.

Regards,

Dominic

Re: [OpenOCD-user] LPC1857 reset problem

[Dominic R. <Dom...@gm...>]

Hi List,

Paul Ferster recommended I try without commit 
20a077eadbeea77ed3f4d75fbe23b6f2db891dd8.

With that commit reverted I'm able to reset the board with srst, but I 
still get some errors.

I've attached a log that shows (not working) sysresetreq reset followed 
by a change to
tsrt_and_srst and a successful (although with errors) reset afterwards.

Regards,

Dominic

Re: [OpenOCD-user] LPC1857 reset problem

[Dominic R. <Dom...@gm...>]

Hi List,

On 19.04.2015 13:36, Dominic Rath wrote:
> Paul Ferster recommended I try without commit 
> 20a077eadbeea77ed3f4d75fbe23b6f2db891dd8.
>
> With that commit reverted I'm able to reset the board with srst, but I 
> still get some errors.

After playing around with reset_config for a while, I found out that
reset_config trst_and_srst srst_pulls_trst allows me to reliably reset
the board, even if I reenable above commit.

Regards,

Dominic

Re: [OpenOCD-user] LPC1857 reset problem

[Tomas V. <to...@us...>]

Hi Dominic,

can you please attach a -d3 log of successful try with srst_pulls_trst
I'm trying to understand why changes 2697 and 2601 have so different 
influence
when using SWD and JTAG.

BTW Any idea why halt does not work after sysresetreq?

Thanks
     Tom

On 19.4.2015 14:33, Dominic Rath wrote:
> Hi List,
>
> On 19.04.2015 13:36, Dominic Rath wrote:
>> Paul Ferster recommended I try without commit
>> 20a077eadbeea77ed3f4d75fbe23b6f2db891dd8.
>>
>> With that commit reverted I'm able to reset the board with srst, but I
>> still get some errors.
> After playing around with reset_config for a while, I found out that
> reset_config trst_and_srst srst_pulls_trst allows me to reliably reset
> the board, even if I reenable above commit.
>
> Regards,
>
> Dominic
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> OpenOCD-user mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openocd-user
>
>

Re: [OpenOCD-user] LPC1857 reset problem

[Dominic R. <Dom...@gm...>]

Hi Tomas,

On 19.04.2015 16:57, Tomas Vanek wrote:
> Hi Dominic,
>
> can you please attach a -d3 log of successful try with srst_pulls_trst
> I'm trying to understand why changes 2697 and 2601 have so different
> influence
> when using SWD and JTAG.

I've attached the log you've asked for, this is with commit
20a07... included.

Are you saying that what I'm trying to do should work
(better) with SWD?

I've also got an Olimex JTAG->SWD adapter for the
ARM-USB-OCD-H - I could give that a try.

> BTW Any idea why halt does not work after sysresetreq?
>
If you're talking about my problem it really looks like
the target is unusable after calling 'reset' with
'reset_config sysresetreq', it's not just halt that is
not working.

If I poll->halt->resume->reset (the halt/resume is just
to verify that everything was good before), the target
is unusable, even if I shutdown OpenOCD and restart.
Polling eventually tells me that the target state is
"unknown".

Regards,

Dominic

Re: [OpenOCD-user] LPC1857 reset problem

[Tomas V. <to...@us...>]

Hi Dominic,

Thanks for the log.
I'm also interested in -d3 log of SWD trial.

BTW You added adapter_nsrst_delay 250 to the config only in version with 
srst_pulls_trst.
I wonder if LPC1857 really needs srst_pulls_trst or srst_gates_jtag with 
and proper adapter_nsrst_delay
and maybe jtag_ntrst_delay would be sufficient.

On 19.4.2015 21:01, Dominic Rath wrote:
> BTW Any idea why halt does not work after sysresetreq?
>>
> If you're talking about my problem it really looks like
> the target is unusable after calling 'reset' with
> 'reset_config sysresetreq', it's not just halt that is
> not working.
>
> If I poll->halt->resume->reset (the halt/resume is just
> to verify that everything was good before), the target
> is unusable, even if I shutdown OpenOCD and restart.
> Polling eventually tells me that the target state is
> "unknown".

It really reminds me PSoC4. It also blocks when OpenOCD sets VC_CORERESET.
And it is also due to "security of intellectual property".

At least the change http://openocd.zylin.com/2606
could avoid annoying restarts of OpenOCD and use of reset button
to get OpenOCD from "unknown" target state.

Tom

Re: [OpenOCD-user] LPC1857 reset problem

[Dominic R. <Dom...@gm...>]

Hi List,

On 20.04.2015 22:47, Dominic Rath wrote:
> An "external" (SRST) reset apparently doesn't have that problem, but
> without "srst_pulls_trst", the OpenOCD can't talk to the target after a
> reset, no matter how I configure the n[st]rst_delays:
>
> Debug: 954 338859 adi_v5_jtag.c:271 jtagdp_transaction_endcheck():
> jtag-dp: CTRL/STAT error, 0x20
>

As suggested by Paul on IRC I gave
http://openocd.zylin.com/#/c/2721/1
a try.

With that change, OpenOCD "resyncs" after a reset with "reset_config 
srst_only", but neither "reset halt" nor "reset init" work. After a 
reset the target is left running, halt etc. then work as normal.

I've attached a -d3 log just in case, and another one with additional 
"adapter_nsrst_delay 500".

Regards,

Dominic

Re: [OpenOCD-user] LPC1857 reset problem

[Dominic R. <Dom...@gm...>]

Hi List,

I made some more progress with regard to LPC18xx reset handling.

I asked NXP, and they provided instructions how to handle the reset
within 12 hours - great support!

I'm still having some doubts how user expectations could be matched 
best, which is why I'm writing down some thoughts about LPC18xx reset 
handling, maybe some of you have some recommendations.

I originally started with git master at commit
3d0b46b2c4029ba98f08ff55e57e611df25549ee, using the sample configuration
from tcl/board/lpc1850_spifi_generic.cfg for a MCB1800 with a LPC1857 on 
a ARM-USB-OCD-H. I added two flash bank lines for the internal flash of 
the LPC1857 (LPC18x0 are flashless parts, LPC18x2|3|5|7 have internal 
flash). Currently the SPIFI flash bank works only if the processor tried 
to boot from SPIFI - presumably there's some initialization missing, 
I'll look into that later.

Reset is rather complicated on the LPC18xx, because it features various 
boot sources, contains a ROM that runs on every boot, and has some 
quirks if reset via SYSRESETREQ or SRST.

With the default setup, OpenOCD tries to reset your processor using 
SYSRESETREQ. That actually works, if you have a valid image in the 
internal flash ("valid" is determined by having a checksum in offset 
0x1c of the vector table).
It fails however if you have no valid image in internal flash, or if you 
wanted to boot from external flash, or if the processor is configured to 
run its ISP protocol on a UART. In all these cases, a simple "reset" 
will leave the processor in a state where you can't even halt anymore. 
"reset halt" will work, unless the processor is configured to boot from 
external flash, but if you let it run from there in the boot ROM, the 
processor will lock up again.

Using reset with "srst_only" reliably resets the processor, but you need 
change #2721 for OpenOCD to resync, and you can't "reset halt" or "reset 
init". As far as I can tell "srst_only" will always be limited, because 
it seems to reset some/all of the debug logic, but that's a different topic.

The SYSRESETREQ resets most of the processor peripherals (which is 
good), but doesn't reset some control registers. Because the boot ROM 
runs on every POR I believe it should run on a debugger-reset as well. 
That means prior to triggering SYSRESETREQ, you should write 0x10400000 
to M3MEMMAP, to map the boot ROM to 0x0. With that mapping a SYSRESETREQ 
with reset vector-catch works and reliably halts the processor at the 
first instruction of the boot ROM. If you let it run from there (which 
is what also happens on a normal "reset" without halt), the processor 
quickly locks up because it accesses some undocumented peripheral that 
had been locked-down by the previous run of the boot code (control 
registers weren't reset, and that lock down is handled by control 
registers).

You can reenable that locked down register, but then the ROM hard-faults 
when accessing yet another undocumented peripheral address. According to 
NXP one should skip over that access (using a breakpoint) and reset the 
control register again. If you did all that, you get past the boot ROM 
and it jumps to your user code. If you wanted to halt at the entry of 
your user code, you need to know where the ROM decides the processor 
should boot from. For that I've used a watchpoint on a write to the 
M3MEMMAP register. At that point you can halt the processor at the reset 
entry point, no matter if it's in internal or external flash.

I've attached a WIP configuration that implements above procedure.

This has a few shortcomings:
- it depends on the ROM version. I got the necessary addresses for other 
versions from NXP, and I think I could locate the sequence that needs 
skipping on a different ROM version as well, but that needs manual work.
- it requires the use of hardware breakpoints and watchpoints. might be 
problematic if the user set too many already on the telnet interface for 
example. GDB shouldn't be much of a problem, because GDB removes 
breakpoints when halted.
- reset halt/init need to know where to stop, and that's difficult to 
decide:
   - user expectation might be to halt at the first instruction of the 
ROM, but if you continued from there, the processor would lock up
   - if the processor enters ISP mode (because of an "force ISP" signal) 
or because there's no valid image in internal flash, and the ISP is 
configured for UART or USB boot, there is no "user reset entry point", 
because the processor remains in the boot code

Questions:

- what state should the processor be in after "reset halt" (or before 
the reset-init script? Is it okay to stop at the user's reset entry 
point, with all of the ROM already executed?
- should that be made configurable, e.g. provide the 
ROM-workaround-handler, but don't enable it by default, or allow it to 
be disabled?
- would a "reset halt" or "reset init" while the processor is forced to 
remain in ISP mode (no valid flash image) that takes ~1 second to 
time-out be ok? that way we could simply wait for the ROM to write 
M3MEMMAP, and if the processor doesn't halt at that watchpoint after ~1s 
we halt where ever we are
a user could instead disable the workaround handler, use reset 
halt/init, and manually put the processor in any state he likes, without 
running the ROM
- the reset procedure is quite "noisy" - are there commands available to 
the reset handler that are more quiet?

Best Regards,

Dominic

Re: [OpenOCD-user] LPC1857 reset problem

[Tomas V. <to...@us...>]

Hi Dominic,

Just an idea for avoiding access to a locked peripheral:
I wonder if it would be more effective to set hard-fault (or what kind 
of exception is raised) vector catch
instead of setting a breakpoint at ROM version dependent address.
It requires more work to resume (increment return address on the stack).
The positive is you don't need to know problematic instruction address 
before run.

Tom


On 26.4.2015 13:52, Dominic Rath wrote:
> Hi List,
>
> I made some more progress with regard to LPC18xx reset handling.
>
> I asked NXP, and they provided instructions how to handle the reset
> within 12 hours - great support!
>
> I'm still having some doubts how user expectations could be matched 
> best, which is why I'm writing down some thoughts about LPC18xx reset 
> handling, maybe some of you have some recommendations.
>
> I originally started with git master at commit
> 3d0b46b2c4029ba98f08ff55e57e611df25549ee, using the sample configuration
> from tcl/board/lpc1850_spifi_generic.cfg for a MCB1800 with a LPC1857 
> on a ARM-USB-OCD-H. I added two flash bank lines for the internal 
> flash of the LPC1857 (LPC18x0 are flashless parts, LPC18x2|3|5|7 have 
> internal flash). Currently the SPIFI flash bank works only if the 
> processor tried to boot from SPIFI - presumably there's some 
> initialization missing, I'll look into that later.
>
> Reset is rather complicated on the LPC18xx, because it features 
> various boot sources, contains a ROM that runs on every boot, and has 
> some quirks if reset via SYSRESETREQ or SRST.
>
> With the default setup, OpenOCD tries to reset your processor using 
> SYSRESETREQ. That actually works, if you have a valid image in the 
> internal flash ("valid" is determined by having a checksum in offset 
> 0x1c of the vector table).
> It fails however if you have no valid image in internal flash, or if 
> you wanted to boot from external flash, or if the processor is 
> configured to run its ISP protocol on a UART. In all these cases, a 
> simple "reset" will leave the processor in a state where you can't 
> even halt anymore. "reset halt" will work, unless the processor is 
> configured to boot from external flash, but if you let it run from 
> there in the boot ROM, the processor will lock up again.
>
> Using reset with "srst_only" reliably resets the processor, but you 
> need change #2721 for OpenOCD to resync, and you can't "reset halt" or 
> "reset init". As far as I can tell "srst_only" will always be limited, 
> because it seems to reset some/all of the debug logic, but that's a 
> different topic.
>
> The SYSRESETREQ resets most of the processor peripherals (which is 
> good), but doesn't reset some control registers. Because the boot ROM 
> runs on every POR I believe it should run on a debugger-reset as well. 
> That means prior to triggering SYSRESETREQ, you should write 
> 0x10400000 to M3MEMMAP, to map the boot ROM to 0x0. With that mapping 
> a SYSRESETREQ with reset vector-catch works and reliably halts the 
> processor at the first instruction of the boot ROM. If you let it run 
> from there (which is what also happens on a normal "reset" without 
> halt), the processor quickly locks up because it accesses some 
> undocumented peripheral that had been locked-down by the previous run 
> of the boot code (control registers weren't reset, and that lock down 
> is handled by control registers).
>
> You can reenable that locked down register, but then the ROM 
> hard-faults when accessing yet another undocumented peripheral 
> address. According to NXP one should skip over that access (using a 
> breakpoint) and reset the control register again. If you did all that, 
> you get past the boot ROM and it jumps to your user code. If you 
> wanted to halt at the entry of your user code, you need to know where 
> the ROM decides the processor should boot from. For that I've used a 
> watchpoint on a write to the M3MEMMAP register. At that point you can 
> halt the processor at the reset entry point, no matter if it's in 
> internal or external flash.
>
> I've attached a WIP configuration that implements above procedure.
>
> This has a few shortcomings:
> - it depends on the ROM version. I got the necessary addresses for 
> other versions from NXP, and I think I could locate the sequence that 
> needs skipping on a different ROM version as well, but that needs 
> manual work.
> - it requires the use of hardware breakpoints and watchpoints. might 
> be problematic if the user set too many already on the telnet 
> interface for example. GDB shouldn't be much of a problem, because GDB 
> removes breakpoints when halted.
> - reset halt/init need to know where to stop, and that's difficult to 
> decide:
>   - user expectation might be to halt at the first instruction of the 
> ROM, but if you continued from there, the processor would lock up
>   - if the processor enters ISP mode (because of an "force ISP" 
> signal) or because there's no valid image in internal flash, and the 
> ISP is configured for UART or USB boot, there is no "user reset entry 
> point", because the processor remains in the boot code
>
> Questions:
>
> - what state should the processor be in after "reset halt" (or before 
> the reset-init script? Is it okay to stop at the user's reset entry 
> point, with all of the ROM already executed?
> - should that be made configurable, e.g. provide the 
> ROM-workaround-handler, but don't enable it by default, or allow it to 
> be disabled?
> - would a "reset halt" or "reset init" while the processor is forced 
> to remain in ISP mode (no valid flash image) that takes ~1 second to 
> time-out be ok? that way we could simply wait for the ROM to write 
> M3MEMMAP, and if the processor doesn't halt at that watchpoint after 
> ~1s we halt where ever we are
> a user could instead disable the workaround handler, use reset 
> halt/init, and manually put the processor in any state he likes, 
> without running the ROM
> - the reset procedure is quite "noisy" - are there commands available 
> to the reset handler that are more quiet?
>
> Best Regards,
>
> Dominic
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
> _______________________________________________
> OpenOCD-user mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openocd-user

Re: [OpenOCD-user] LPC1857 reset problem

[Dominic R. <Dom...@gm...>]

Hi Tom,

On 20.04.2015 11:38, Tomas Vanek wrote:
> Hi Dominic,
>
> Thanks for the log.
> I'm also interested in -d3 log of SWD trial.

I left the ARM-USB-OCD-H with the SWD adapter at work, but I'll take 
them with me tomorrow, so I'll be able to get you the log.

> BTW You added adapter_nsrst_delay 250 to the config only in version with
> srst_pulls_trst.
> I wonder if LPC1857 really needs srst_pulls_trst or srst_gates_jtag with
> and proper adapter_nsrst_delay
> and maybe jtag_ntrst_delay would be sufficient.

I'm really not sure anymore what the LPC1857 needs.

I found out that with SYSRESETREQ (that is no reset_mode, no 
n[st]rst_delays) i'm able to "reset halt" the processor, and step a few 
instructions. It is only at some point down the ROM code that the 
processor becomes inaccessible.

That is probably what I've seen originally:

SYSRESETREQ resets the processor, then at some point the debugger can't 
talk to it anymore.

An "external" (SRST) reset apparently doesn't have that problem, but 
without "srst_pulls_trst", the OpenOCD can't talk to the target after a 
reset, no matter how I configure the n[st]rst_delays:

Debug: 954 338859 adi_v5_jtag.c:271 jtagdp_transaction_endcheck(): 
jtag-dp: CTRL/STAT error, 0x20

Unfortunately with "srst_pulls_trst" I'm unable to use "reset init" or 
"reset halt", and it looks like some parts of OpenOCD assume "reset 
init" is available - I've seen a failed assertion when trying to flash 
an executable from GDB, and it looks like the OpenOCD wanted to "reset 
init" the target before flashing.

Best Regards,

Dominic

Re: [OpenOCD-user] LPC1857 reset problem

[Paul F. <fer...@gm...>]

On Mon, Apr 20, 2015 at 10:47:09PM +0200, Dominic Rath wrote:
> Unfortunately with "srst_pulls_trst" I'm unable to use "reset init" or 
> "reset halt", and it looks like some parts of OpenOCD assume "reset 
> init" is available - I've seen a failed assertion when trying to flash 
> an executable from GDB, and it looks like the OpenOCD wanted to "reset 
> init" the target before flashing.

Yes, default gdb-flash-erase-start target event hook calls reset-init
but you can override it for testing purposes. Of course, the original
issue should better be investigated and fixed, for that all the
sensible debug logs should be gathered and analised. This reset area
went through some sort of redesign lately because the previous
handling was clearly contradicting the standard and hence not working
with several targets (e.g. SAM4L and PSoC4).

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] LPC1857 reset problem

[Paul F. <fer...@gm...>]

On Sun, Apr 19, 2015 at 02:33:15PM +0200, Dominic Rath wrote:
> On 19.04.2015 13:36, Dominic Rath wrote:
> > Paul Ferster recommended I try without commit 
> > 20a077eadbeea77ed3f4d75fbe23b6f2db891dd8.
> >
> > With that commit reverted I'm able to reset the board with srst, but I 
> > still get some errors.
> 
> After playing around with reset_config for a while, I found out that
> reset_config trst_and_srst srst_pulls_trst allows me to reliably reset
> the board, even if I reenable above commit.

Can you check if it's a board's limitation or rather a target's and
hence the upstream LPC1850 config should be modified accordingly?

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] LPC1857 reset problem

[Dominic R. <Dom...@gm...>]

Hello Paul,

On 19.04.2015 20:01, Paul Fertser wrote:
> still get some errors.
>> After playing around with reset_config for a while, I found out that
>> reset_config trst_and_srst srst_pulls_trst allows me to reliably reset
>> the board, even if I reenable above commit.
> Can you check if it's a board's limitation or rather a target's and
> hence the upstream LPC1850 config should be modified accordingly?
>
The board connects SRST straight to the processor's /RESET,
and TRST goes right to the processor's /TRST, no connection
between the two lines.

The LPCs always used to be special with regard to reset, because
of their "Code Read Protection" - you write a certain signature to
a location in the internal flash, and that disables JTAG and removes
some features from the ISP bootloader (e.g. only full erase possible).
 From what I found out back then is that JTAG really comes up disabled,
and only gets enabled by the ROM code if the CRP signature isn't set.
I think it was for the LPCs that we first implemented srst_pulls_trst.

I'm really not sure any more if this is a restrictions that affects
all LPCs, since I found this thread
http://sourceforge.net/p/openocd/mailman/message/28345948/
where Peter Stuge posted a patch to remove srst_pulls_trst from his
LPC2148, because he didn't find it necessary. He even wrote that he
was able to 'reset halt', which is something I always thought
impossible with the LPCs.

Regards,

Dominic

Re: [OpenOCD-user] LPC1857 reset problem

[Paul F. <fer...@gm...>]

On Sun, Apr 19, 2015 at 09:01:27PM +0200, Dominic Rath wrote:
> Are you saying that what I'm trying to do should work
> (better) with SWD?

It happened so that SWD got more testing lately so probably yes. Tomas
did plenty of fine work on different quirky targets to get them
function reliable.

> I've also got an Olimex JTAG->SWD adapter for the
> ARM-USB-OCD-H - I could give that a try.

Yes, that should work out of the box, just source
interface/ftdi/olimex-arm-jtag-swd.cfg after the interface
config. Even if you didn't have that adapter, you could have used the
trivial "resistor hack" to get it working.

> If I poll->halt->resume->reset (the halt/resume is just
> to verify that everything was good before), the target
> is unusable, even if I shutdown OpenOCD and restart.
> Polling eventually tells me that the target state is
> "unknown".

BTW, if poll succeeded once on startup (and an attempt is made
automatically), OpenOCD keeps polling the target no matter what,
unless you do explicit "poll off".

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] LPC1857 reset problem

[Dominic R. <Dom...@gm...>]

Hi Paul,

On 19.04.2015 21:11, Paul Fertser wrote:
> On Sun, Apr 19, 2015 at 09:01:27PM +0200, Dominic Rath wrote:
>> Are you saying that what I'm trying to do should work
>> (better) with SWD?
>
> It happened so that SWD got more testing lately so probably yes. Tomas
> did plenty of fine work on different quirky targets to get them
> function reliable.
>
>> I've also got an Olimex JTAG->SWD adapter for the
>> ARM-USB-OCD-H - I could give that a try.
>
> Yes, that should work out of the box, just source
> interface/ftdi/olimex-arm-jtag-swd.cfg after the interface
> config. Even if you didn't have that adapter, you could have used the
> trivial "resistor hack" to get it working.

I gave it a quick test, but it looks like debugging via SWD
is affected by the same problem.

Regards,

Dominic