Re: [Openocd-development] OpenOCD vs. Colibri PXA320 v2.0b
On Tue, Sep 13, 2011 at 9:28 AM, Oliver Döring wrote: > Hi, > > I'm having lots of problems with this Toradex board. > > I use a custom carrier board without JTAG buffers, so I connected my > JTAG-USB directly to the Colibri FFC JTAG connector. My JTAG adapter is > FT2232 based and uses the OOCDLink layout, which means it has NTRST and > NSRST buffers with OE. I traced all the signals from the Colibri board to > the JTAG adapters, everything looks ok. I looked at the signals with an > (analogue) oscilloscope and saw the reset signals and pulses on TMS, TCK, > TDI and TDO. > > However, here is what I get: > > OpenOCD startup: >> >> Open On-Chip Debugger 0.6.0-dev-00079-g4017af8-dirty (2011-09-11-23:08) >> Licensed under GNU GPL v2 >> For bug reports, read >> http://openocd.berlios.de/doc/doxygen/bugs.html >> Info : only one transport option; autoselect 'jtag' >> 100 kHz >> adapter_nsrst_delay: 260 >> jtag_ntrst_delay: 250 >> Info : colibri_pxa320.cpu: hardware has 2 breakpoints and 2 watchpoints >> trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain >> adapter_nsrst_delay: 800 >> Info : clock speed 100 kHz >> Info : JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg: >> 0x009, part: 0xe642, ver: 0x7) > > Trying to halt the CPU: >>> >>> reset halt >> >> JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg: 0x009, >> part: 0xe642, ver: 0x7) >> Bad value '00' captured during DR or IR scan: >> check_value: 0x02 >> check_mask: 0x07 >> JTAG error while writing DCSR >> Bad value '00' captured during DR or IR scan: >> check_value: 0x02 >> check_mask: 0x06 >> JTAG error while reading TX >> error while polling TX register, reset CPU >> target state: halted >> target halted in ARM state due to undefined, current mode: User >> cpsr: 0x pc: 0x >> MMU: disabled, D-Cache: disabled, I-Cache: disabled >>> > > When I try to resume, I get lots of those "Bad value '00' captured..." > messages and eventually a "time out writing RX register". Is it a bug that xscale_read_dcsr() exits with the TAP in state TAP_DRPAUSE? The attached patch seems to make the "Bad value '00'" messages go away. If this patch looks correct I'll submit a proper patch to commit. Matt ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD vs. Colibri PXA320 v2.0b
On Mon, Sep 19, 2011 at 10:13 AM, Matt Reimer wrote: > On Tue, Sep 13, 2011 at 9:28 AM, Oliver Döring wrote: >> Hi, >> >> I'm having lots of problems with this Toradex board. >> >> I use a custom carrier board without JTAG buffers, so I connected my >> JTAG-USB directly to the Colibri FFC JTAG connector. My JTAG adapter is >> FT2232 based and uses the OOCDLink layout, which means it has NTRST and >> NSRST buffers with OE. I traced all the signals from the Colibri board to >> the JTAG adapters, everything looks ok. I looked at the signals with an >> (analogue) oscilloscope and saw the reset signals and pulses on TMS, TCK, >> TDI and TDO. >> >> However, here is what I get: >> >> OpenOCD startup: >>> >>> Open On-Chip Debugger 0.6.0-dev-00079-g4017af8-dirty (2011-09-11-23:08) >>> Licensed under GNU GPL v2 >>> For bug reports, read >>> http://openocd.berlios.de/doc/doxygen/bugs.html >>> Info : only one transport option; autoselect 'jtag' >>> 100 kHz >>> adapter_nsrst_delay: 260 >>> jtag_ntrst_delay: 250 >>> Info : colibri_pxa320.cpu: hardware has 2 breakpoints and 2 watchpoints >>> trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain >>> adapter_nsrst_delay: 800 >>> Info : clock speed 100 kHz >>> Info : JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg: >>> 0x009, part: 0xe642, ver: 0x7) >> >> Trying to halt the CPU: reset halt >>> >>> JTAG tap: colibri_pxa320.cpu tap/device found: 0x7e642013 (mfg: 0x009, >>> part: 0xe642, ver: 0x7) >>> Bad value '00' captured during DR or IR scan: >>> check_value: 0x02 >>> check_mask: 0x07 >>> JTAG error while writing DCSR >>> Bad value '00' captured during DR or IR scan: >>> check_value: 0x02 >>> check_mask: 0x06 >>> JTAG error while reading TX >>> error while polling TX register, reset CPU >>> target state: halted >>> target halted in ARM state due to undefined, current mode: User >>> cpsr: 0x pc: 0x >>> MMU: disabled, D-Cache: disabled, I-Cache: disabled >> >> When I try to resume, I get lots of those "Bad value '00' captured..." >> messages and eventually a "time out writing RX register". > > Is it a bug that xscale_read_dcsr() exits with the TAP in state > TAP_DRPAUSE? The attached patch seems to make the "Bad value '00'" > messages go away. > > If this patch looks correct I'll submit a proper patch to commit. > > Matt Oops, forgot the patch. Matt read_dcsr.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Possible bug in xscale_receive()
The code in xscale_receive() that tries to skip invalid reads (i.e. reads that don't have the DBG_SR[0] 'valid' bit set) seems to be wrong, as it only looks at the first word's valid flag rather than each word's own valid flag. Am I reading the code correctly? If so, the attached patch should fix it. If this looks correct, I'll generate a proper patch and commit message. Matt xscale_receive.c.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32L microcontroller support
Please merge the two patches into one: git rebase -i origin/master => squash your patches together read HACKING for further tips. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32L microcontroller support
Commits (and patches) squashed together.
Regards,
Clément
On 09/19/2011 04:49 PM, Øyvind Harboe wrote:
Please merge the two patches into one:
git rebase -i origin/master
=> squash your patches together
read HACKING for further tips.
--
Clément Burin des Roziers
HiKoB
http://openlab.hikob.com
>From 2550e17565eba022f6cf1e9a3e9061eaef78a778 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Burin=20des=20Roziers?=
Date: Fri, 16 Sep 2011 15:55:54 +0200
Subject: [PATCH] STM32L: Added flash driver and target
Added the flash driver for the STM32L family, which highly differ from the STM32F family.
Added the TCL target file for JTAG access.
---
contrib/loaders/flash/stm32lx.S | 63 +++
src/flash/nor/Makefile.am |1 +
src/flash/nor/drivers.c |2 +
src/flash/nor/stm32lx.c | 1044 +++
tcl/target/stm32l.cfg | 81 +++
5 files changed, 1191 insertions(+), 0 deletions(-)
create mode 100644 contrib/loaders/flash/stm32lx.S
create mode 100644 src/flash/nor/stm32lx.c
create mode 100644 tcl/target/stm32l.cfg
diff --git a/contrib/loaders/flash/stm32lx.S b/contrib/loaders/flash/stm32lx.S
new file mode 100644
index 000..6e8ccb0
--- /dev/null
+++ b/contrib/loaders/flash/stm32lx.S
@@ -0,0 +1,63 @@
+/***
+ * Copyright (C) 2010 by Spencer Oliver *
+ * s...@spen-soft.co.uk *
+ * *
+ * Copyright (C) 2011 Ãyvind Harboe *
+ * oyvind.har...@zylin.com *
+ * *
+ * Copyright (C) 2011 Clement Burin des Roziers *
+ * clement.burin-des-rozi...@hikob.com *
+ * *
+ * This program is free software; you can redistribute it and/or modify *
+ * it under the terms of the GNU General Public License as published by *
+ * the Free Software Foundation; either version 2 of the License, or *
+ * (at your option) any later version. *
+ * *
+ * This program is distributed in the hope that it will be useful, *
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of*
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
+ * GNU General Public License for more details. *
+ * *
+ * You should have received a copy of the GNU General Public License *
+ * along with this program; if not, write to the *
+ * Free Software Foundation, Inc., *
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *
+ ***/
+
+
+// Build : arm-eabi-gcc -c stm32lx.S
+ .text
+ .syntax unified
+ .cpu cortex-m3
+ .thumb
+ .thumb_func
+ .global write
+
+/*
+ r0 - destination address
+ r1 - source address
+ r2 - count
+*/
+
+ // Set 0 to r3
+ movs r3, #0
+ // Go to compare
+ b.n test_done
+
+write_word:
+ // Load one word from address in r0, increment by 4
+ ldr.w ip, [r1], #4
+ // Store the word to address in r1, increment by 4
+ str.w ip, [r0], #4
+ // Increment r3
+ adds r3, #1
+
+test_done:
+ // Compare r3 and r2
+ cmp r3, r2
+ // Loop if not zero
+ bcc.n write_word
+
+ // Set breakpoint to exit
+ bkpt #0x00
+
diff --git a/src/flash/nor/Makefile.am b/src/flash/nor/Makefile.am
index a966826..d5832ca 100644
--- a/src/flash/nor/Makefile.am
+++ b/src/flash/nor/Makefile.am
@@ -26,6 +26,7 @@ NOR_DRIVERS = \
stellaris.c \
stm32f1x.c \
stm32f2x.c \
+ stm32lx.c \
str7x.c \
str9x.c \
str9xpec.c \
diff --git a/src/flash/nor/drivers.c b/src/flash/nor/drivers.c
index a437d84..6b0cc36 100644
--- a/src/flash/nor/drivers.c
+++ b/src/flash/nor/drivers.c
@@ -34,6 +34,7 @@ extern struct flash_driver stellaris_flash;
extern struct flash_driver str9xpec_flash;
extern struct flash_driver stm32f1x_flash;
extern struct flash_driver stm32f2x_flash;
+extern struct flash_driver stm32lx_flash;
extern struct flash_driver tms470_flash;
extern struct flash_driver ecosflash_flash;
extern struct flash_driver ocl_flash;
@@ -65,6 +66,7 @@ static struct flash_driver *flash_drivers[] = {
&str9xpec_flash,
&stm32f1x_flash,
&stm32f2x_flash,
+ &stm32lx_flash,
&tms470_flash,
&ecosflash_flash,
&ocl_flash,
diff --git a/src/flash/nor/stm32lx.c b/src/flash/nor/stm32lx.c
new file mode 100644
index 000..c592a8e
--- /dev/null
+++ b/src/flash/nor/stm3
Re: [Openocd-development] STM32L microcontroller support
Some more nit-picking:
1. Switch more LOG_INFO() to LOG_DEBUG(). LOG_INFO() is intended for
'users'
+ LOG_INFO("allocating working area for algo (%u bytes)", reg32);
2. Purge unused prototypes and reorder fn's to avoid unecessary ones:
+/* Private prototypes */
+static int stm32lx_unlock_pecr(struct flash_bank *bank);
+static int stm32lx_lock_pecr(struct flash_bank *bank);
+static int stm32lx_unlock_program_memory(struct flash_bank *bank);
+static int stm32lx_lock_program_memory(struct flash_bank *bank);
+static int stm32lx_unlock_option_byte(struct flash_bank *bank);
+static int stm32lx_erase_sector(struct flash_bank *bank, int sector);
+static int stm32lx_wait_until_bsy_clear(struct flash_bank *bank);
3. Remove warning or change to LOG_DEBUG()
+ if (target_alloc_working_area(target, reg32,
&stm32lx_info->write_algorithm)
+ != ERROR_OK)
+ {
+ LOG_WARNING("no working area available, can't do block memory
writes");
+ return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
+ };
4. Add missing error propagation:
+ // Lock back program memory
+ stm32lx_lock_program_memory(bank);
+
5. Change to LOG_DEBUG() or remove.
+ retval = stm32lx_write_rdp(bank, 0xAA);
+ if (retval != ERROR_OK)
+ {
+ LOG_ERROR("failed to write RDP byte");
+ return retval;
+ }
+ }
6.
--
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434
http://www.zylin.com/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] kinetis cpu flash driver
Hello, I noticed a deadlock on tap initialized with hashidcode to false. Here is the attached patch. Best regards -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: Saturday, September 17, 2011 2:25 PM To: Mathias K. Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] [PATCH] kinetis cpu flash driver Merged. Thanks! -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development 0001-kinetis-correction-of-deadlock-on-device-having-hasi.patch Description: 0001-kinetis-correction-of-deadlock-on-device-having-hasi.patch ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] kinetis cpu flash driver
I'll let it cool off for a few days. Please give word if further work is required and we should submit an updated patch. -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] kinetis cpu flash driver
Hello, i prefer something like this (i don't want to start a goto discussion): if ( tap->hasidcode && (dap_syssec_filter_data[i].idcode == tap->idcode) ) but we should be sure that idcode is initialized with an invalid value like zero but independent of the hasidcode flag. Regards, Mathias Am 19.09.2011 18:50, schrieb Øyvind Harboe: > I'll let it cool off for a few days. Please give word if further work > is required and > we should submit an updated patch. > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] AM3517 Craneboard support
On 9/6/11 5:31 PM, Eric Sandeen wrote: > Matt Hsu writes: > >> >> Hi all,I tried to use AM3517evm's config on AM3517 Craneboard. But it seems > that no luck to get openOCD work.sudo openocd -f interface/flyswatter.cfg -f > board/am3517evm.cfgOpen On-Chip Debugger 0.5.0 (2011-08-31-15:54) >> Licensed under GNU GPL v2For bug reports, read > http://openocd.berlios.de/doc/doxygen/bugs.htmlInfo : only one transport > option; > autoselect 'jtag' >> 10 kHztrst_only separate trst_push_pullInfo : clock speed 10 kHzInfo : JTAG > tap: am35x.jrc tap/device found: 0x0b86802f (mfg: 0x017, part: 0xb868, ver: > 0x0)Warn : JTAG tap: am35x.jrc UNEXPECTED: 0x0b86802f (mfg: 0x017, part: > 0xb868, ver: 0x0) >> Error: JTAG tap: am35x.jrc expected 1 of 1: 0x0b7ae02f (mfg: 0x017, part: > 0xb7ae, ver: 0x0)Error: Trying to use configured scan chain anyway...Warn : > Bypassing JTAG setup events due to errors >> I'm curious that anyone try to get openOCD work on craneboard?Thanks,-- - >> Matt > > I have an embedded board which behaves similarly... also, Øyvind started out > about the same way with an AM3517 board, see for example > > http://lists.berlios.de/pipermail/openocd-development/2010-June/015867.html > >> Info : JTAG tap: am3517.jrc tap/device found: 0x0b86802f (mfg: 0x017, part: > 0xb868, ver: 0x0) > > But that ID doesn't exist in the cfg files later checked into openocd. I'm > not > quite sure how he got from point A to point B ... :) (BTW sorry for the horrendous formatting of the original fwd'd message, not sure how that happened) I did get a config working with my board, with that tapid. It seems that something got lost in commit 60501bb0fb0cb69f66ebb3ce3b64b69f3cadf4ff AM/DM37x: Unify configuration scripts and add support for TI Beagleboard xM. # git show 60501bb0fb0cb69f66ebb3ce3b64b69f3cadf4ff | grep 0x0b86802f -set DAP_TAPID 0x0b86802f That tapid was removed, and not moved elsewhere. I'll try to look over that commit and my working config file, and see how this should have gone... -Eric ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
