>
> Strange, i have checked another two boards here, IAR and Keil and they are
> both working aswell.
The interesting part of this problem is that reset is not always failing.
For example, I cannot reproduce anymore any of the reset problems I had
30 minutes ago, with the same firmware and configu
Edgar Grimberg wrote:
>> Have you another board to try, Hitex like to externally connect SRST and
>> TRST. This causes issues with openocd and the str7.
>
> I've checked the schematics and the behavior of the HITEX board.
> The schematics shows that SRST pulls TRST.
> I modified the configuration
>
> Have you another board to try, Hitex like to externally connect SRST and
> TRST. This causes issues with openocd and the str7.
I've checked the schematics and the behavior of the HITEX board.
The schematics shows that SRST pulls TRST.
I modified the configuration file to:
reset_config trst_an
Edgar Grimberg wrote:
> Hi Spen,
>
>
>>> I have tested two other vendor's boards that do not do this connection and
>>> get no problems.
>
> Another details is that I have an empty flash. The test case is "reset
> init on an empty flash".
>
just erased flash and performed full power cycle.
sti
Hi Spen,
>> I have tested two other vendor's boards that do not do this connection and
>> get no problems.
Another details is that I have an empty flash. The test case is "reset
init on an empty flash".
Edgar
--
Edgar Grimberg
System Developer
Zylin AS
ZY1000 JTAG Debugger http://www.zylin.c
Edgar Grimberg wrote:
> Hi Spen,
>
>> Have you another board to try, Hitex like to externally connect SRST and
>> TRST. This causes issues with openocd and the str7.
>
> I have only the HITEX STR710 EVALBOARD with a STR710FZ2T6 on it.
> Donations are always welcomed, of course :)
>
>> I have fou
Hi Spen,
>
> Have you another board to try, Hitex like to externally connect SRST and
> TRST. This causes issues with openocd and the str7.
I have only the HITEX STR710 EVALBOARD with a STR710FZ2T6 on it.
Donations are always welcomed, of course :)
> I have found with the str7 that even though t
Edgar Grimberg wrote:
> On Fri, Jan 29, 2010 at 10:50 AM, Edgar Grimberg
> wrote:
>> On Tue, Jan 26, 2010 at 5:38 AM, David Brownell wrote:
>>> On Tuesday 19 January 2010, Øyvind Harboe wrote:
Run the following and it will fail to halt occasionally. This is not a
regression,
but I
On Friday 29 January 2010, Edgar Grimberg wrote:
> JTAG tap: str710.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part:
> 0xf0f0, ver: 0x3)
> srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> Jazelle debug entry -- BROKEN!
> Jazelle state handling is BROKEN!
> target sta
On Fri, Jan 29, 2010 at 10:50 AM, Edgar Grimberg
wrote:
> On Tue, Jan 26, 2010 at 5:38 AM, David Brownell wrote:
>> On Tuesday 19 January 2010, Øyvind Harboe wrote:
>>> Run the following and it will fail to halt occasionally. This is not a
>>> regression,
>>> but I thought I'd post this tip on ho
On Tue, Jan 26, 2010 at 5:38 AM, David Brownell wrote:
> On Tuesday 19 January 2010, Øyvind Harboe wrote:
>> Run the following and it will fail to halt occasionally. This is not a
>> regression,
>> but I thought I'd post this tip on how to reproduce flaky reset problems...
>
> Got any more info on
On Tuesday 19 January 2010, Øyvind Harboe wrote:
> Run the following and it will fail to halt occasionally. This is not a
> regression,
> but I thought I'd post this tip on how to reproduce flaky reset problems...
Got any more info on this? Just curious.
Another STR7 issue is with the flash prot
Run the following and it will fail to halt occasionally. This is not a
regression,
but I thought I'd post this tip on how to reproduce flaky reset problems...
for {set i 0} {$i < 1000} {set i [expr $i+1]} {echo "Reset $i"; reset
halt}
10 kHz
JTAG tap: str710.cpu tap/device found: 0x3f0f0f0f (mf
13 matches
Mail list logo
