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