Re: [Openocd-development] PXA question
Dne Po 6. září 2010 08:50:09 Takács Áron napsal(a): Hello, Hi, keep the CC please thanks for the answers of Wookey and Marek! You are right, marek, there are buffers on the board. I have tried to increase the reset delays (jtag_nsrst_delay, jtag_ntrst_delay 250) and also the timeout value in xscale.c:409 and :499, but the situation remained the same. Any ideas what to try now? Thank you! You use colibri board, right? Either try a different JTAG adapter or connect yours directly to the CPU card (there's that white strap connecting the JTAG on the card to the board ... you can use that to tap directly on the CPU JTAG pins). Cheers Áron 2010-09-03 21:44 keltezéssel, Marek Vasut írta: Dne Pá 3. září 2010 16:46:59 Wookey napsal(a): +++ Takács Áron [2010-09-03 16:15 +0200]: Hi, I want to use openocd to reflash PXA270 board (Colibri by Toradex). I am using JTAGKey-Tiny interface (by Amontec). I can connect the board but I always get the error message: 'time out writing RX register'. Here is the output for 'reset' and 'flash info 0': We've used openocd with amontec jtagkey-tiny and pxa270 (balloonboard) successfully for some time now. It works since 0.3.1 and is also fine with 0.4. You might find it useful to compare your config with ours: http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd we have at least one extra pxa CPUID which should be upstreamed: http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd/target/ pxa 270updated.cfg but that's not going to make any difference, assuming you are seeing the device. The rest of the config looks OK to me, but I only checked quickly It might be the colibri board buffer logic that causes trouble. There are additional buffers on the baseboard. I use a custom FT2232 based dongle compatible with amontec jtagkey, but I heard people had trouble with original amontec dongles and colibri boards. reset JTAG tap: pxa270.cpu tap/device found: 0x79265013 (mfg: 0x009, part: 0x9265, ver: 0x7) Failed to receiving data from debug handler after 1000 attempts time out writing RX register # set jtag_nsrst_delay to the delay introduced by your reset circuit # the rest of the needed delays are built into the openocd program jtag_nsrst_delay 260 # set the jtag_ntrst_delay to the delay introduced by a reset circuit # the rest of the needed delays are built into the openocd program jtag_ntrst_delay 250 Try upping these numbers? I know that Marvell parts have different timing to Intel parts in reset. Bit of a long short but worth a try. Wookey ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PXA question
Dne Po 6. září 2010 08:59:21 Takács Áron napsal(a): Thanky you, Marek! Yes I use a Colibri board. Bypassing the buffers needs some HW hacking but I'll try it. Thank you! Keep the DAMNED CC !! You don't need any hardware hacking, you can just connect the jtag to the CPU card directly, check the Toradex datasheets and schematics for more details. Áron 2010-09-06 08:53 keltezéssel, Marek Vasut írta: Dne Po 6. září 2010 08:50:09 Takács Áron napsal(a): Hello, Hi, keep the CC please thanks for the answers of Wookey and Marek! You are right, marek, there are buffers on the board. I have tried to increase the reset delays (jtag_nsrst_delay, jtag_ntrst_delay 250) and also the timeout value in xscale.c:409 and :499, but the situation remained the same. Any ideas what to try now? Thank you! You use colibri board, right? Either try a different JTAG adapter or connect yours directly to the CPU card (there's that white strap connecting the JTAG on the card to the board ... you can use that to tap directly on the CPU JTAG pins). Cheers Áron 2010-09-03 21:44 keltezéssel, Marek Vasut írta: Dne Pá 3. září 2010 16:46:59 Wookey napsal(a): +++ Takács Áron [2010-09-03 16:15 +0200]: Hi, I want to use openocd to reflash PXA270 board (Colibri by Toradex). I am using JTAGKey-Tiny interface (by Amontec). I can connect the board but I always get the error message: 'time out writing RX register'. Here is the output for 'reset' and 'flash info 0': We've used openocd with amontec jtagkey-tiny and pxa270 (balloonboard) successfully for some time now. It works since 0.3.1 and is also fine with 0.4. You might find it useful to compare your config with ours: http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd we have at least one extra pxa CPUID which should be upstreamed: http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd/targe t/ pxa 270updated.cfg but that's not going to make any difference, assuming you are seeing the device. The rest of the config looks OK to me, but I only checked quickly It might be the colibri board buffer logic that causes trouble. There are additional buffers on the baseboard. I use a custom FT2232 based dongle compatible with amontec jtagkey, but I heard people had trouble with original amontec dongles and colibri boards. reset JTAG tap: pxa270.cpu tap/device found: 0x79265013 (mfg: 0x009, part: 0x9265, ver: 0x7) Failed to receiving data from debug handler after 1000 attempts time out writing RX register # set jtag_nsrst_delay to the delay introduced by your reset circuit # the rest of the needed delays are built into the openocd program jtag_nsrst_delay 260 # set the jtag_ntrst_delay to the delay introduced by a reset circuit # the rest of the needed delays are built into the openocd program jtag_ntrst_delay 250 Try upping these numbers? I know that Marvell parts have different timing to Intel parts in reset. Bit of a long short but worth a try. Wookey ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PXA question
2010-09-06 10:33 keltezéssel, Marek Vasut írta: Dne Po 6. září 2010 08:59:21 Takács Áron napsal(a): Thanky you, Marek! Yes I use a Colibri board. Bypassing the buffers needs some HW hacking but I'll try it. Thank you! Keep the DAMNED CC !! Sorry, I simply pushed Reply... You don't need any hardware hacking, you can just connect the jtag to the CPU card directly, check the Toradex datasheets and schematics for more details. OK, I understand, but I have to connect a 2,5mm pin header (JTAGKey) to a 0,5mm pitch ffc (Colibri)... But I will solve it. Thank you for your help! Áron Áron 2010-09-06 08:53 keltezéssel, Marek Vasut írta: Dne Po 6. září 2010 08:50:09 Takács Áron napsal(a): Hello, Hi, keep the CC please thanks for the answers of Wookey and Marek! You are right, marek, there are buffers on the board. I have tried to increase the reset delays (jtag_nsrst_delay, jtag_ntrst_delay 250) and also the timeout value in xscale.c:409 and :499, but the situation remained the same. Any ideas what to try now? Thank you! You use colibri board, right? Either try a different JTAG adapter or connect yours directly to the CPU card (there's that white strap connecting the JTAG on the card to the board ... you can use that to tap directly on the CPU JTAG pins). Cheers Áron 2010-09-03 21:44 keltezéssel, Marek Vasut írta: Dne Pá 3. září 2010 16:46:59 Wookey napsal(a): +++ Takács Áron [2010-09-03 16:15 +0200]: Hi, I want to use openocd to reflash PXA270 board (Colibri by Toradex). I am using JTAGKey-Tiny interface (by Amontec). I can connect the board but I always get the error message: 'time out writing RX register'. Here is the output for 'reset' and 'flash info 0': We've used openocd with amontec jtagkey-tiny and pxa270 (balloonboard) successfully for some time now. It works since 0.3.1 and is also fine with 0.4. You might find it useful to compare your config with ours: http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd we have at least one extra pxa CPUID which should be upstreamed: http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd/targe t/ pxa 270updated.cfg but that's not going to make any difference, assuming you are seeing the device. The rest of the config looks OK to me, but I only checked quickly It might be the colibri board buffer logic that causes trouble. There are additional buffers on the baseboard. I use a custom FT2232 based dongle compatible with amontec jtagkey, but I heard people had trouble with original amontec dongles and colibri boards. reset JTAG tap: pxa270.cpu tap/device found: 0x79265013 (mfg: 0x009, part: 0x9265, ver: 0x7) Failed to receiving data from debug handler after 1000 attempts time out writing RX register # set jtag_nsrst_delay to the delay introduced by your reset circuit # the rest of the needed delays are built into the openocd program jtag_nsrst_delay 260 # set the jtag_ntrst_delay to the delay introduced by a reset circuit # the rest of the needed delays are built into the openocd program jtag_ntrst_delay 250 Try upping these numbers? I know that Marvell parts have different timing to Intel parts in reset. Bit of a long short but worth a try. Wookey ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PXA question
/ I want to use openocd to reflash PXA270 board (Colibri by Toradex). I am // using JTAGKey-Tiny interface (by Amontec). I can connect the board but I // always get the error message: // 'time out writing RX register'. Here is the output for 'reset' and // // 'flash info 0': // We've used openocd with amontec jtagkey-tiny and pxa270 (balloonboard) // successfully for some time now. It works since 0.3.1 and is also fine // with 0.4. You might find it useful to compare your config with ours: // http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd // // we have at least one extra pxa CPUID which should be upstreamed: // http://balloonboard.org/trac/browser/balloon/trunk/utils/openocd/target/pxa // 270updated.cfg / Toradex use the Amontec JTAGkey Tiny, and since 2005 for programming their Colibri platfroms!, see their wiki Your trouble is not related to JTAGkey but related to timing issue, especially regarding SRST. If you use the same schematic as the Toradex Evaluation board, see their wiki, you should use SRST as push-pull from your JTAGkey since Toradex only provide a 100k pull-up on SRST line before an on-board buffer. If you use Open-Drain for SRST from JTAGkey, (as by defualt) please make sure to check the timing on the final SRST, close to the processor, and make sure you do not generate any JTAG before SRST close to the processor is stable again to a high level . The 100k pull-up will add a lot of delay for getting the SRST deasserted !!! The great advantage of the Amontec JTAGkey is the possibility to control the SRST signal as push-pull or as open-drain. Laurent http://www.amontec.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
At 01:32 PM 9/5/10, Spencer Oliver wrote: On 03/09/2010 20:29, John Hartman (NoICE) wrote: The STM32 parts have Flash beginning at 0x800, and OpenOCD's stm32x.c places the Flash there regardless of the address used in the flash command in the cfg file. The chips have two pins that can be jumpered to specify what appears at address 0: Flash, RAM, or the boot loader. For embedded work, I think Flash will be the most common case. But if I link my program at zero, it is a pain to burn my program, because OpenOCD tells gdb there is only RAM at 0, with Flash at 800. (material deleted for brevity) Just use the virtual bank cmd, that's what it there for flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME flash bank vbank0 virtual 0x 0 0 0 $_TARGETNAME $_FLASHNAME This is EXACTLY what I need. No changes to OpenOCD (aside from my cfg file), and no need to modify the configuration of other tools. Thank you. Best regards, John Hartman NoICE Debugging Tools http://www.noicedebugger.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Stellaris: disable JTAG interface
I'm using LM3S6911 chip and would like to protect the firmware by disabling debugging interface. I have found a discussion about this on TI forum http://e2e.ti.com/f/471/p/45944/159065.aspx#159065%22 Unfortunately issuing these commands via openocd didn't disable JTAG: mww 0x400fd004 0xFFFD (also tried 0xFFFC and 0x0) mww 0x400fd000 0x7510 mww 0x400fd008 0xA4420008 All the examples in the thread were for programs running on the device. Am I missing something? Regards, Yegor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] problem using the jtag interface on linux ...
Sorry for double posting but I just didn't get an answer the last time. If I still get no reply I'll have to keep searching for other answers ... Hi ... I'm trying to use a self made JTag wiggler cable that on one end has a DB25 ( parallel port ) interface and on the other a 20-Pin JTag socket. The main cause of the errors I get when using openocd could be from a faulty cable issue but I want to discard any possible configuration problems with the application. I'm using openocd-0.4 with this configuration file: telnet_port gdb_port tcl_port source [find interface/parport.cfg] source [find target/stm32.cfg] init reset halt flash write_image erase /root/TETSCADA.bin 0x800 bin resume shutdown logfile My host is a normal PC running Ubuntu GNU/Linux 10.04 and my target is an ARM MCU. As you can see in the configuration file I'm using the parport.cfg config file that comes with openocd: interface parport parport_port 0 parport_cable wiggler When I run my program: # openocd -f openocd.cfg I get the following error: Open On-Chip Debugger 0.4.0 (2010-08-31-15:56) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html parport port = 0x0 1000 kHz jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 Info : clock speed 500 kHz Error: JTAG scan chain interrogation failed: all zeroes Error: Check JTAG interface, timings, target power, etc. Error: JTAG scan chain interrogation failed: all zeroes Error: Check JTAG interface, timings, target power, etc. Command handler execution failed Warn : jtag initialization failed; try 'jtag init' again. Error: JTAG scan chain interrogation failed: all zeroes Error: Check JTAG interface, timings, target power, etc. error: -100 Command handler execution failed I tried searching on the web and on your forums and mailing lists about error -100 but couldn't find any info about it. Could someone help ? Thanks in advance ... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] warnings: fix alignment warnings
These warnings are for architectures that do not
support non-aligned word access.
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
src/flash/mflash.c |4 ++--
src/flash/nand/lpc3180.c |4 ++--
src/flash/nor/at91sam3.c |4 ++--
src/helper/types.h |2 +-
src/pld/virtex2.c|2 +-
src/target/arm11.c |4 ++--
src/target/arm_adi_v5.c |2 +-
src/target/arm_jtag.h|4 ++--
src/target/avr32_ap7k.c |8
src/target/avr32_mem.c |6 +++---
src/target/etb.c |2 +-
src/target/mips_m4k.c|2 +-
src/target/xscale.c |2 +-
13 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/src/flash/mflash.c b/src/flash/mflash.c
index 4372128..26b85b1 100644
--- a/src/flash/mflash.c
+++ b/src/flash/mflash.c
@@ -1121,7 +1121,7 @@ static int mg_storage_config(void)
!= ERROR_OK)
return ret;
- mg_gen_ataid((mg_io_type_drv_info *)buff);
+ mg_gen_ataid((mg_io_type_drv_info *)(void *)buff);
if ((ret = mg_mflash_do_write_sects(buff, 0, 1,
mg_vcmd_update_stgdrvinfo))
!= ERROR_OK)
@@ -1149,7 +1149,7 @@ static int mg_boot_config(void)
buff[0] = mg_op_mode_snd; /* operation mode */
buff[1] = MG_UNLOCK_OTP_AREA;
buff[2] = 4;/* boot size */
- *((uint32_t *)(buff + 4)) = 0; /* XIP size */
+ *((uint32_t *)(void *)(buff + 4)) = 0; /* XIP size */
if ((ret = mg_mflash_do_write_sects(buff, 0, 1, mg_vcmd_update_xipinfo))
!= ERROR_OK)
diff --git a/src/flash/nand/lpc3180.c b/src/flash/nand/lpc3180.c
index 93d00d5..d81443d 100644
--- a/src/flash/nand/lpc3180.c
+++ b/src/flash/nand/lpc3180.c
@@ -1119,9 +1119,9 @@ static int lpc3180_read_page(struct nand_device *nand,
uint32_t page, uint8_t *d
target_read_memory(target, target_mem_base+SPARE_OFFS, 4,
16, ecc_flash_buffer);
target_read_memory(target, target_mem_base+ECC_OFFS, 4, 8,
ecc_hw_buffer);
for(i=0;iidx;i++){
-if( (0x00ff*(uint32_t *)(ecc_hw_buffer+i*8)) !=
(0x00ff*(uint32_t *)(ecc_flash_buffer+8+i*16)) )
+if( (0x00ff*(uint32_t *)(void
*)(ecc_hw_buffer+i*8)) != (0x00ff*(uint32_t *)(void
*)(ecc_flash_buffer+8+i*16)) )
LOG_WARNING(ECC mismatch at 256 bytes size block=
%d at page= 0x% PRIx32,i*2+1,page);
-if( (0x00ff*(uint32_t *)(ecc_hw_buffer+4+i*8)) !=
(0x00ff*(uint32_t *)(ecc_flash_buffer+12+i*16)) )
+if( (0x00ff*(uint32_t *)(void
*)(ecc_hw_buffer+4+i*8)) != (0x00ff*(uint32_t *)(void
*)(ecc_flash_buffer+12+i*16)) )
LOG_WARNING(ECC mismatch at 256 bytes size block=
%d at page= 0x% PRIx32,i*2+2,page);
}
}
diff --git a/src/flash/nor/at91sam3.c b/src/flash/nor/at91sam3.c
index 221832c..8005fe0 100644
--- a/src/flash/nor/at91sam3.c
+++ b/src/flash/nor/at91sam3.c
@@ -1702,7 +1702,7 @@ sam3_get_reg_ptr(struct sam3_cfg *pCfg, const struct
sam3_reg_list *pList)
// By using prototypes - we can detect what would
// be casting errors.
- return ((uint32_t *)(((char *)(pCfg)) + pList-struct_offset));
+ return ((uint32_t *)(void *)(((char *)(pCfg)) + pList-struct_offset));
}
@@ -1756,7 +1756,7 @@ sam3_GetReg(struct sam3_chip *pChip, uint32_t *goes_here)
// calculate where this one go..
// it is possibly this register.
- pPossible = ((uint32_t *)(((char *)((pChip-cfg))) +
pReg-struct_offset));
+ pPossible = ((uint32_t *)(void *)(((char *)((pChip-cfg))) +
pReg-struct_offset));
// well? Is it this register
if (pPossible == goes_here) {
diff --git a/src/helper/types.h b/src/helper/types.h
index 1010dcd..04b0059 100644
--- a/src/helper/types.h
+++ b/src/helper/types.h
@@ -80,7 +80,7 @@ typedef bool _Bool;
*/
#define container_of(ptr, type, member) ({ \
const typeof( ((type *)0)-member ) *__mptr = (ptr);\
- (type *)( (char *)__mptr - offsetof(type,member) );})
+ (type *)( (void *) ( (char *)__mptr - offsetof(type,member) ) );})
/**
diff --git a/src/pld/virtex2.c b/src/pld/virtex2.c
index 1963736..f4657bc 100644
--- a/src/pld/virtex2.c
+++ b/src/pld/virtex2.c
@@ -78,7 +78,7 @@ static int virtex2_send_32(struct pld_device *pld_device,
static __inline__ void virtexflip32(jtag_callback_data_t arg)
{
uint8_t *in = (uint8_t *)arg;
- *((uint32_t *)in) = flip_u32(le_to_h_u32(in), 32);
+ *((uint32_t *)arg) = flip_u32(le_to_h_u32(in), 32);
}
static int virtex2_receive_32(struct pld_device *pld_device,
diff --git a/src/target/arm11.c b/src/target/arm11.c
index 85d45b0..9955143 100644
Re: [Openocd-development] problem using the jtag interface on linux ...
On 09/06/2010 09:20 AM, Teratux wrote: I get the following error: Open On-Chip Debugger 0.4.0 (2010-08-31-15:56) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html parport port = 0x0 1000 kHz jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 Info : clock speed 500 kHz Error: JTAG scan chain interrogation failed: all zeroes One suggestion for a starting point: use a slow clock, e.g., adapter_khz 50 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
