openocd-development-boun...@lists.berlios.de wrote on 2009-09-21 06:38:16:
> While doing a regression binary search on OpenOCD revisions, I noticed
> only by chance that ./configure was issuing a warning about my libftdi
> version (I had 0.12, it wants 0.16). I then upgraded the version,
> eli
On Sunday 20 September 2009, Michel Catudal wrote:
> > Nexus sits on top of JTAG..
>
> I know that but that doesn't change the fact that it is a different
> protocol than the Atmel JTAGII.
For the JTAG signals, it's the same protocol. Same state
machine, etc.
For the "auxiliary port" it's wh
This turned out to be a red herring:
https://lists.berlios.de/pipermail/openocd-development/2009-September/010692.html
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openoc
> As for other types of processor Atmel would be nice if they would release
> the specs for their proprietary debug module.
> They do publish the specs for the JTAG programming but an engineer at Atmel
> told me that they intend to keep the debug stuff secret.
I would expect that Atmel made a sane
> Well I just priced at DigiKey, and I saw Q-1000 prices
> are higher than that. Full speed, $US 3.85; high speed
> is a bit cheaper (yay!) at $US 3.70 ...
The cost of a beer rather than a few sips then. Same
thing really :-)
If it was free it wouldn't make a difference.
--
Øyvind Harboe
Em
Hi Rolf,
The device is a Spansion S29GL512P11TFI01.
flash info 0 says:
> flash info 0
#0 : cfi at 0x4800, size 0x0400, buswidth 2, chipwidth 2
# 0: 0x (0x2 128kB) protection state unknown
# 1: 0x0002 (0x2 128kB) protection state unknown
#
Thanks for testing! :-)
Could you post your config script once you're done
so we can include it in the OpenOCD target library?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Hi Stephan,
What is the exact type number of the flash device?
Regards,
Rolf
--- Stephan Winokur schrieb am Mo, 21.9.2009:
> Von: Stephan Winokur
> Betreff: [Openocd-development] problems with FASTDATA bulk write and spansion
> flash
> An: openocd-development@lists.berlios.de
> Datum: Montag
David Brownell a écrit :
> On Sunday 20 September 2009, Michel Catudal wrote:
>
>> They have the two protocols, they are not the same. The nexus part
>> involves a very expensive emulator style device while
>> the other one is just the Atmel version of JTAG debugging.
>>
>
> Nexus sits on
With the following reset config:
reset_config srst_only srst_pulls_trst
...revisions beyond 2620 could not load code to the i.MX35. Revision
2621 fixes the logic for srst/trst, so I tried messing around with that
part.
Changing my config to:
reset_config trst_and_srst combined
...makes every
On Sunday 20 September 2009, Michel Catudal wrote:
> They have the two protocols, they are not the same. The nexus part
> involves a very expensive emulator style device while
> the other one is just the Atmel version of JTAG debugging.
Nexus sits on top of JTAG..
___
David Brownell a écrit :
> On Sunday 20 September 2009, Michel Catudal wrote:
>
>> As for other types of processor Atmel would be nice if they would
>> release the specs for their proprietary debug module.
>> They do publish the specs for the JTAG programming but an engineer at
>> Atmel told m
While doing a regression binary search on OpenOCD revisions, I noticed
only by chance that ./configure was issuing a warning about my libftdi
version (I had 0.12, it wants 0.16). I then upgraded the version,
eliminating the warning.
What are the consequences of the version mismatch? Should th
On Sunday 20 September 2009, Michel Catudal wrote:
> As for other types of processor Atmel would be nice if they would
> release the specs for their proprietary debug module.
> They do publish the specs for the JTAG programming but an engineer at
> Atmel told me that they intend to keep the debug
Hi all,
I'm trying to make faster flash writes happen on a mips based
platform -- because this is crazy: wrote 524288 byte from file
/root/flashme.bin in 45807.718750s (0.011177 kb/s).
I've downloaded the svn snapshot (2734), applied the "FASTDATA" bulk
write optimization, and made the necessa
On Sunday 20 September 2009, Øyvind Harboe wrote:
>
> Short term(a year or so), I'd like to see robustness for
> the ARM target *much* improved
"The" ARM? :)
There are a lot of them ...
- ARMv4 chips other than ARM7TDMI ("Mr Embedded ARM")
aren't big growth targets;
- ARMv5 has many curr
Øyvind Harboe a écrit :
> In terms of getting levarage with smaller chip vendors,
> I believe http://www.vinchip.com is a case in point, but
> I have no idea if their 32 bit risc is just another ARM
> or whether it's something proprietary(didn't really look).
>
From what I read on the site it
On Sunday 20 September 2009, Johnny Halfmoon wrote:
> Anyway, how's this then:
Committed; thanks.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Sunday 20 September 2009, David Brownell wrote:
> Behaved for me in light testing; but I'll wait for feedback,
> in case there's something I missed.
No feedback; but I committed this version anyway. On the
theory a Certain Person has repeated -- that testing won't
happen until code hits mainli
On Sunday 20 September 2009, Johnny Halfmoon wrote:
> + if ((retval = flash_check_sector_parameters(cmd_ctx, first,
> last, p->num_sectors)) !
I had in mind more like
uint32_t value;
retval = parse_u32(argv[X], &value);
if (retval != ERROR_OK)
Fair enough. Try this then (with some added parameter checking)...
= = =
doc/openocd.texi |6 --
src/flash/flash.c | 47 ---
2 files changed, 48 insertions(+), 5 deletions(-)
Index: src/flash/flash.c
===
On Sun, Sep 20, 2009 at 10:23 PM, Michael Schwingen
wrote:
> David Brownell wrote:
>> Good point; Øyvind's suggestion (keyword "last") seems
>> to be the best overall solution then.
>>
>
> That would be my favourite, unless it needs ridiculous amounts of code
> to implement.
Agree 100%. What abou
David Brownell wrote:
>>
>
> Doesn't build:
> stm32x.c: In function ‘stm32x_protect’:
> stm32x.c:413: warning: too few arguments for format
>
> You need to compute that multiple. :)
>
> Suggest you avoid such a LONG message in any case.
> Better: "Invalid sector start/end; must b
On Saturday 19 September 2009, David Brownell wrote:
> However that is not the cause of the new reset problems
> I'm seeing on an arm926. Still chasing those down.
Seems like it was just a JTAG clock rate issue ... now
that I'm trying to use OpenOCD to debug some bootloader
code, such issues beco
David Brownell wrote:
> Good point; Øyvind's suggestion (keyword "last") seems
> to be the best overall solution then.
>
That would be my favourite, unless it needs ridiculous amounts of code
to implement.
cu
Michael
___
Openocd-development mailing
On Sunday 20 September 2009, Michael Schwingen wrote:
> > This relies on the lack of error checking for testing "first"
> > and "last" ... better to add error checking, and then use zero
> > as the magic number.
> >
> Hm - would'nt that trigger when trying to erase only sector 0?
Good point; Øy
One of my goals w/OpenOCD is that it becomes yet another
thing that hardware vendors have to "check off" on the
GCC toolchain list. Not having OpenOCD support should
be like not having GDB support.
This is a long way off, but it's something to aspire to.
Short term(a year or so), I'd like to see
Could you use a keyword like "last", rather than try to
overload the meaning of integers?
Using -1 is quicker, easier and more seductive
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-developme
David Brownell wrote:
>>
>> +if (last < 0)
>> +last = p->num_sectors - 1;
>> +
>>
>
> This relies on the lack of error checking for testing "first"
> and "last" ... better to add error checking, and then use zero
> as the magic number.
>
Hm - would'nt that
On Sunday 20 September 2009, Johnny Halfmoon wrote:
> --- trunk/src/flash/stm32x.c(revision 2736)
> +++ trunk/src/flash/stm32x.c(working copy)
> @@ -410,7 +410,7 @@
>
> if ((first && (first % stm32x_info->ppage_size)) || ((last + 1) &&
> (last + 1) % stm32x_info->ppage_size))
>
On Friday 18 September 2009, Alain Mouette wrote:
> This is a bit old, but better then never...
>
> David Brownell escreveu:
> > On Friday 04 September 2009, Alain Mouette wrote:
> >> Error: failed erasing sectors 0 to 255 (-901)
> >
> > flash.h:#define ERROR_FLASH_SECTOR_INVALID
On Sunday 20 September 2009, Johnny Halfmoon wrote:
> This patch slightly enhances the behaviour of the standard erase and protect
> functions. After applying this patch, defining -1 as the last sector tells
> OpenOCD to protect or erase the entire flash bank. The relevant part in the
> OpenOCD
This patch modifies an error message which, in its original state, I find
somewhat unhelpful. So a small hint was added.
Signed-off-by: Johnny Halfmoon
---
stm32x.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: trunk/src/flash/stm32x.c
==
This patch slightly enhances the behaviour of the standard erase and protect
functions. After applying this patch, defining -1 as the last sector tells
OpenOCD to protect or erase the entire flash bank. The relevant part in the
OpenOCD has been updated.
Signed-off-by: Johnny Halfmoon
---
d
Update the jtag-examine_chain() logic to verify that there's
no garbage after the expected (from the TAPs' BYPASS or IDCODE
registers). Such garbage normally indicates a TAP that wasn't
configured; although this also handles the case observed with
some AVR8 cores, where instead of shifting TDI the
Debug message updates:
- Shrink messaging during resets, primarily by getting rid of
"nothing happened" noise that hides *useful* information.
- Improve: the "no IDCODE" message by identifying which tap only
supports BYPASS; and the TAP event strings.
Related minor code updates:
- Rem
Minor regression bugfix for the jtag_tap_handle_event() case
for disabling TAPs. We don't actually know how to make any
JRCs do that yet; but when we do, this will matter.
---
src/jtag/tcl.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/src/jtag/tcl.c
+++ b/src/jtag/tc
37 matches
Mail list logo
