[Openocd-development] Mailing list?
Hi! From what I've read berlios has found some funding so it's going to operate, but will the mailing lists be kept online? Sourceforge deleted the list, there is an archive available, so what's so hard in undeleting it? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] pointers modification within functions
On 2011-11-03 17:38, Tomek CEDRO wrote: The problem is that C (or GCC) can only change variable out of function using *variable=value construct. That's how C works - everything is passed to the function by value, so when you pass a pointer, you just pass a value which is an address. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building OpenOCD for Windows
New package for Windows is available for download on my website www.freddiechopin.info 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jenkins changes
So that's normal that all patchsets now are marked as not verified (X) because the build fails at a file completely unaffected by that patch and unchanged for a long time (buspirate.c for example)? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command-line paths problem in Windows
The change that Steve Bennett suggested me in email is now posted to Gerrit and it solves the problem. uplevel #0 [list source [find $filename]] 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jenkins changes
On 2011-10-22 10:50, Øyvind Harboe wrote: all you have to do, is to rebase your fix on top of the other fix that's in the queue and push. Then your patch will go green. Hmm... Something not working on the server probably... $ git fetch http://openocd.zylin.com/p/openocd refs/changes/43/43/3 git checkout FETCH_HEAD error: RPC failed; result=22, HTTP code = 503 fatal: The remote end hung up unexpectedly Anyway - I see that my patch depends now on buspirate fix, so I guess that is't done. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command-line paths problem in Windows
Just as Peter suspected the problem is caused by commit a62d8f2271312ba955e839509590f5a5975b1b49. I've verified that with bisecting. I've also build version with that single commit reverted which worked as expected and as before. I've pushed revert-patch for Gerrit review. I believe it should be reverted for now but the general idea it introduced (easing use of global variables) is worth implementing but in some other way. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New patch to review for openocd: 7067428 Revert Evaluate 'script' in the global scope
On 2011-10-21 19:09, Øyvind Harboe (Code Review) wrote: Please look up the discussion of why this code was modified to use uplevel and amend the commit with an explanation of why we should use the proposed behaviour instead. I cannot comment on Gerrit... The discussion - https://lists.berlios.de/pipermail/openocd-development/2011-August/020462.html - not easy to find (links to list are links to NEW and EMPTY sourceforge forum) so I had to google that up. There is absolutely no discussion or reasoning there, this change was introduced just because and based on why not?. Or maybe there's another discussion I cannot find. The commit message I've made has an explanation of why the change was reverted. Or maybe a change in behavior for Windows users is not a reason to revert a patch that introduced it by mistake? To reiterate - now OpenOCD does NOT work as manual says. This is a change in behavior that did not ever change and never was intended to change. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command-line paths problem in Windows
On 2011-10-21 19:39, Peter Stuge wrote: Not so easy. I disagree with reverting the patch without having a clear plan for the real fix. Not easy because it is not neccessarily possible to implement the same functionality in any other way. The proper solution requries Jim expertise which I have none, or possibly Tcl expertise which I have very very little. If pressed for a solution, I would look into a workaround for the double evaluation, such as a way to escape any \ in $filename. But I disagree with reverting the commit. Fix the problem instead. What? So you don't know how to fix that, I don't know how to fix that, but we cannot revert a one-line change that introduced A BUG just because it (supposedly - I did not check) adds some functionality that was not actually discussed in detail EVER? Why can't we revert a change, fixing a bug and wait for a real jimtcl-expert (Steve) to discuss other alternatives while in the meantime OpenOCD would work as expected for Windows users? The problem is that Windows paths now cannot be used normally and OpenOCD cannot be used as before. Global variables thing which this patch (supposedly) improves is just an improvement, because you could use globals before anyway, just had to add global NAME before. Please revert to fix a real problem (removing backslashes from Windows paths). We can deal with improvement while at the same time OpenOCD works as it should. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] commit a62d8f22 causes double evaluation of $filename in src/helper/startup.tcl proc script
On 2011-10-21 20:13, Peter Stuge wrote: Meanwhile, the workaround is quite trivial. Yeah, right... Tell that to thousands of OpenOCD users who do NOT build their binary. How can they change startup.tcl when it's hardcoded into openocd.exe? I'm more interested in knowing if not using uplevel also changes which directory relative paths are relative to? It doesn't - it's a side effect of some kind. That's the one and only change that caused problems described before. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Command-line paths problem in Windows
Hi! The most recent OpenOCD behaves differently on Windows than 0.5.0 (and before) and in my opinion the direction of change is to worse. OpenOCD 0.5.0 could be run this way: openocd -f interface/jtagkey.cfg -f target/stm32.cfg And it worked fine. Current OpenOCD when trying this gives: Runtime Error: embedded:startup.tcl:58: couldn't read file D:openocd-devopenocd -0.6.0-dev-11102001452in../interface/jtagkey.cfg: No such file or directory in procedure 'script' at file embedded:startup.tcl, line 58 The only working version that I've found is: openocd -f ../interface/jtagkey.cfg -f ../target/stm32.cfg But that's not all. Other differences: 1. In 0.5.0 you could use slash or backslash (which is more correct in Windows) - no difference. Now only slash works, backslash is ommited and replaced with... nothing... 2. When running OpenOCD as External Tool from Eclipse I always left Working Dir empty and it worked fine, now I have to specify this directory for OpenOCD to work - probably because backslashes in Windows paths are replaced with nothing... I think that the root cause for the problem is because backslashes are now treated differently. Can that be fixed? Is that a problem of OpenOCD or JimTCL or maybe you don't consider this a problem at all? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building OpenOCD for Windows
Hi! I've prepared a package but I've found an inconvenience in handling paths in new version (see other thread) so I'll see whether there's a will and possibility to fix/change that before publishing. If you need it now I can send you the package. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building OpenOCD for Windows
On 2011-10-20 01:42, Peter Stuge wrote: Maybe you can also describe how you build them? No magic here - it's just much simpler to do crosscompilation on Linux than fighting natively in Windows. The cause of problems in Windows is that OpenOCD needs many tools to be compiled. libftdi needs even more (cmake). Setting them all under MinGW or Cygwin seems to me like too much work because in any Linux distro most of them are present by default or can be installed with a few clicks. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Unused variables
Nothing to comment here - pretty straightforward.
4\/3!!
From 39cb927737d653db8610fce8001aa98e8b256451 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Wed, 19 Oct 2011 17:55:33 +0200
Subject: [PATCH] Unused variables
Fix a few errors with set and unused variables detected by GCC 4.7.0
---
src/target/armv7a.c | 10 +-
src/target/cortex_a.c |2 +-
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/src/target/armv7a.c b/src/target/armv7a.c
index e0d0882..0bac27f 100644
--- a/src/target/armv7a.c
+++ b/src/target/armv7a.c
@@ -129,7 +129,6 @@ int armv7a_mmu_translate_va(struct target *target,
uint32_t va, uint32_t *val)
uint32_t first_lvl_descriptor = 0x0;
uint32_t second_lvl_descriptor = 0x0;
int retval;
- uint32_t cb;
struct armv7a_common *armv7a = target_to_armv7a(target);
struct arm_dpm *dpm = armv7a-armv4_5_common.dpm;
uint32_t ttb = 0; /* default ttb0 */
@@ -168,7 +167,6 @@ int armv7a_mmu_translate_va(struct target *target,
uint32_t va, uint32_t *val)
if ((first_lvl_descriptor 0x3) == 2)
{
/* section descriptor */
- cb = (first_lvl_descriptor 0xc) 2;
*val = (first_lvl_descriptor 0xfff0) | (va 0x000f);
return ERROR_OK;
}
@@ -203,9 +201,6 @@ int armv7a_mmu_translate_va(struct target *target,
uint32_t va, uint32_t *val)
return ERROR_TARGET_TRANSLATION_FAULT;
}
- /* cacheable/bufferable is always specified in bits 3-2 */
- cb = (second_lvl_descriptor 0xc) 2;
-
if ((second_lvl_descriptor 0x3) == 1)
{
/* large page descriptor */
@@ -243,7 +238,7 @@ int armv7a_mmu_translate_va_pa(struct target *target,
uint32_t va,
struct armv7a_common *armv7a = target_to_armv7a(target);
struct arm_dpm *dpm = armv7a-armv4_5_common.dpm;
uint32_t virt = va ~0xfff;
- uint32_t NOS,NS,SH,INNER,OUTER;
+ uint32_t NOS,NS,INNER,OUTER;
*val = 0xdeadbeef;
retval = dpm-prepare(dpm);
if (retval != ERROR_OK)
@@ -260,7 +255,6 @@ int armv7a_mmu_translate_va_pa(struct target *target,
uint32_t va,
/* decode memory attribute */
NOS = (*val 10) 1; /* Not Outer shareable */
NS = (*val 9) 1; /* Non secure */
- SH = (*val 7 ) 1; /* shareable */
INNER = (*val 4) 0x7;
OUTER = (*val 2) 0x3;
@@ -726,7 +720,6 @@ done:
int armv7a_init_arch_info(struct target *target, struct armv7a_common *armv7a)
{
- struct armv7a_common *again;
struct arm *armv4_5 = armv7a-armv4_5_common;
armv4_5-arch_info = armv7a;
target-arch_info = armv7a-armv4_5_common;
@@ -738,7 +731,6 @@ int armv7a_init_arch_info(struct target *target, struct
armv7a_common *armv7a)
armv7a-armv7a_mmu.armv7a_cache.ctype = -1;
armv7a-armv7a_mmu.armv7a_cache.flush_all_data_cache = NULL;
armv7a-armv7a_mmu.armv7a_cache.display_cache_info = NULL;
-again =target_to_armv7a(target);
return ERROR_OK;
}
diff --git a/src/target/cortex_a.c b/src/target/cortex_a.c
index 7547f17..2370d95 100755
--- a/src/target/cortex_a.c
+++ b/src/target/cortex_a.c
@@ -92,7 +92,7 @@ static int cortex_a8_restore_cp15_control_reg(struct target*
target)
1, 0, /* CRn, CRm */
cortex_a8-cp15_control_reg);
}
- return ERROR_OK;
+ return retval;
}
/* check address before cortex_a8_apb read write access with mmu on
--
1.7.4.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Unused variables
On 2011-10-19 19:50, Øyvind Harboe wrote: Please read HACKING and post to Gerrit. Sorry, I don't have time to do so because: 1. The patch is trivial 2. I use git in Linux hosted in VitualBox, where emailing patches kinda does not work 3. My knowledge of Linux and Git is minimal So basically I can say that Gerrit posting would NOT work in my environment without some serious effort, while you can just accept that trivial patch or post it there in two seconds. I have got a lot on my head now and no time to spare. Make Gerrit accept patches via web interface (I see no reason why it shouldn't allow to do so as it's web based) and I'll be happy to post anything there - now it's just like a stone wall for me with milions of steps required to send a patch once a year. For me - a user who sometimes patches simple stuff or adds config files - Gerrit is an obstacle, nothing more. Sorry for the inconvenience. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD 0.5.0 for Windows
Hi! I've just posted Windows packages with OpenOCD 0.5.0 on my website - http://www.freddiechopin.info/ - enjoy (; Below I post the news article associated with this files OpenOCD 0.5.0 finally published! Almost one and a half year passed since last stable OpenOCD release... During this time 0.4.0 Windows installer was downloaded from this website over 16000 times and packages with development versions from this period - over 5000 times. This time Windows version of the application was published - just as development versions - as a compressed .zip archive, not as .msi installer - I hope this won't be a problem for you, it's easier and faster to create such package instead of playing with installers (; . In Download Software OpenOCD you can download 32- and 64-bit version. Extract anywhere and you are ready to go (; You can find highlights of major changes in NEWS file associated with this release in OpenOCD repository. There are not many of them, because this release should be treated as a stable update, without any revolutionary changes. What next? The most anticipated feature - SWD (Serial Wire Debug) interface support, two-wire interface used in most recent Cortex chips - is in advanced stage. While you could use both classic JTAG and modern SWD in bigger chips like STM32 or LPC17xx, the smallest chips - like LPC11xx - can be debugged only via SWD. You can find more details on OpenOCD mailing list. Let's hope that test versions will be available soon! Stay tuned! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
On 2011-08-10 18:13, Manuel Borchers wrote: The point he was trying to make is, that one _may_ need (or want to stick to) the native FTDI drivers. This may be because one wants to use the other channel as a normal UART (speak use the virtual com port) You can use normal UART on the second channel without any problems! This myth is going on forever! You can install two completely separate drivers for two channels of FT2232 - libusb-win32 for JTAG channel and ftd2xx for UART channel. OpenOCD does not care about second channel (yet). or some other closed source tools or there may even be no possibility to install libftdi drivers to the machines (due to firm policies) and one _must_ stick to the FTDI drivers. Such policies are usually made as a protection from proprietary illegal (cracked) software. I don't know whether an IT admin would refuse to install completely free driver in the system. (; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
On 2011-08-10 20:04, Freddie Chopin wrote: I don't know whether an IT admin would refuse to install completely free driver in the system. I meant: I don't know any reason why IT admin would refuse to install completely free driver in the system. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Release?
Is the idea to make a release already dead? rc2 was the last (3 weeks ago) and there were huge plans to have six of such release candidates. There were not many new patches in the repository, maybe not enough to mandate another release candidate, but there are not many patches because people are probably holding back in the release phase... I think that next week another rc should be published (this time as a proper tarball to check for any distribution problems) which would be final rc in this release, we could wait for a week or two and if there are no bug reports a release should be made. The sooner the better. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem with OpenOCD 0.5.0-rc1 and STM32 verify_image
On 2011-07-22 17:30, Andreas Fritiofson wrote: According to objdump, the completely different hex file is located in RAM: Oops (; Indeed it is - I forgot that it's from a project I recently experimented on... Sorry for the mess (; So - I cannot confirm the issue, it works for me with 0.4.0 - 0.5.0-rc1. Magnus - could you explain your issue in greater detail? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem with OpenOCD 0.5.0-rc1 and STM32 verify_image
I can partially confirm... Tested with 0.5.0-rc1 Comparing with right image works fine: verify_image c://stm32_blink_led.bin 0x800 verified 29888 bytes in 0.468750s (62.267 KiB/s) verify_image c://stm32_blink_led.bin verified 29888 bytes in 0.484375s (60.258 KiB/s) verify_image c://stm32_blink_led.hex verified 29888 bytes in 0.50s (58.375 KiB/s) verify_image c://stm32_blink_led.elf verified 29888 bytes in 0.921875s (31.661 KiB/s) Comparing with almost right image (compilation date inside has changed) works fine too: verify_image c://stm32_blink_led.elf checksum mismatch - attempting binary compare diff 0 address 0x08006d26. Was 0x32 instead of 0x31 diff 1 address 0x08006d27. Was 0x31 instead of 0x38 diff 2 address 0x08006d29. Was 0x34 instead of 0x32 diff 3 address 0x08006d2c. Was 0x35 instead of 0x34 diff 4 address 0x08006d2d. Was 0x34 instead of 0x36 diff 5 address 0x08006d34. Was 0x31 instead of 0x32 No more differences found. in procedure 'verify_image' verify_image c://stm32_blink_led.hex checksum mismatch - attempting binary compare diff 0 address 0x08006d26. Was 0x32 instead of 0x31 diff 1 address 0x08006d27. Was 0x31 instead of 0x38 diff 2 address 0x08006d29. Was 0x34 instead of 0x32 diff 3 address 0x08006d2c. Was 0x35 instead of 0x34 diff 4 address 0x08006d2d. Was 0x34 instead of 0x36 diff 5 address 0x08006d34. Was 0x31 instead of 0x32 No more differences found. in procedure 'verify_image' verify_image c://stm32_blink_led.bin checksum mismatch - attempting binary compare diff 0 address 0x6d26. Was 0x32 instead of 0x31 diff 1 address 0x6d27. Was 0x31 instead of 0x38 diff 2 address 0x6d29. Was 0x34 instead of 0x32 diff 3 address 0x6d2c. Was 0x35 instead of 0x34 diff 4 address 0x6d2d. Was 0x34 instead of 0x36 diff 5 address 0x6d34. Was 0x31 instead of 0x32 No more differences found. in procedure 'verify_image' verify_image c://stm32_blink_led.bin 0x800 checksum mismatch - attempting binary compare diff 0 address 0x08006d26. Was 0x32 instead of 0x31 diff 1 address 0x08006d27. Was 0x31 instead of 0x38 diff 2 address 0x08006d29. Was 0x34 instead of 0x32 diff 3 address 0x08006d2c. Was 0x35 instead of 0x34 diff 4 address 0x08006d2d. Was 0x34 instead of 0x36 diff 5 address 0x08006d34. Was 0x31 instead of 0x32 No more differences found. in procedure 'verify_image' However... when checking against something completely wrong (almost completely different code) strange things happen. When checking against bin, everything is as expected, but when checking against hex or elf: verify_image c://stm32_blink_led.hex checksum mismatch - attempting binary compare diff 0 address 0x2000. Was 0x02 instead of 0x28 diff 1 address 0x2001. Was 0x46 instead of 0x03 ... diff 126 address 0x2097. Was 0x00 instead of 0x20 diff 127 address 0x2098. Was 0x00 instead of 0x15 More than 128 errors, the rest are not printed. in procedure 'verify_image' verify_image c://stm32_blink_led.elf checksum mismatch - attempting binary compare diff 0 address 0x2000. Was 0x02 instead of 0x28 diff 1 address 0x2001. Was 0x46 instead of 0x03 ... diff 126 address 0x2097. Was 0x00 instead of 0x20 diff 127 address 0x2098. Was 0x00 instead of 0x15 More than 128 errors, the rest are not printed. in procedure 'verify_image' If you specify address it is treated as an offset from beginning of RAM... verify_image c://stm32_blink_led.hex 0x2000 checksum mismatch - attempting binary compare diff 0 address 0x20002000. Was 0x02 instead of 0x28 diff 1 address 0x20002001. Was 0x02 instead of 0x03 ... diff 126 address 0x2000207f. Was 0x37 instead of 0x20 diff 127 address 0x20002080. Was 0x10 instead of 0x15 More than 128 errors, the rest are not printed. in procedure 'verify_image' verify_image c://stm32_blink_led.hex 0x4000 checksum mismatch - attempting binary compare diff 0 address 0x20004000. Was 0x8a instead of 0x28 diff 1 address 0x20004001. Was 0xb9 instead of 0x03 ... diff 126 address 0x2000407e. Was 0x52 instead of 0x00 diff 127 address 0x2000407f. Was 0x96 instead of 0x20 More than 128 errors, the rest are not printed. in procedure 'verify_image' verify_image c://stm32_blink_led.hex 0x8000 stm32.cpu -- clearing lockup after double fault error executing cortex_m3 crc algorithm JTAG-DP STICKY ERROR MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20008004 JTAG-DP STICKY ERROR MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20008004 Block read error address 0x20008000 in procedure 'verify_image' (it's the same for elf). So sometimes OpenOCD starts the check in completely wrong location... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On 2011-07-15 10:29, Xiaofan Chen wrote: Interestingly increasing the jtag_khz value does not help too much. This is with a different PC and with Freddie Chopin's binary but the result is similar. Most probably you reached the limit with flash programming. To test just the throughput you could try uploads to RAM. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.5.0-rc2 release
Tarballs available for 0.4.0-rcs allowed me to build executables which would show correct version on startup as well as PDF User's Guide with correct tag. Now all people can see is 0.5.0-dev. Real release tarballs would be really appreciated... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Please welcome Jean-Christophe as release manager
On 2011-07-04 16:11, Jean-Christophe PLAGNIOL-VILLARD wrote: I'll prepare the tarball on sf.net A tarball would be highly appreciated (; Drop us a line on the list when it will be available! (; Regards! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.5.0-rc1 release
I restate some previous question - on which revision from master is this RC based. My big request - could we have this RC in the official OpenOCD repositiory (the one on sourceforge)? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Status of building using Mingw64?
OpenOCD versions from my website ( www.freddiechopin.info ) - 32- and 64-bit, the most recent one is a week old - are built with this compiler, but with the most recent version (GCC 4.7.0) and on Linux, as I found that easier than using Cygwin or MSYS directly in Windows. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New development version of OpenOCD available at last!
On 2011-06-10 22:02, Peter Stuge wrote: Finally, I would be fine with a release only after Tomek's work on SWD is done. Sure, but it's been 18 months (1.5 year!) since a release and waiting for some more non-tivial changes can postpone a release by unknown amount of time. Maybe two weeks, maybe two months, maybe another year. SWD will probably don't get much testing, as - IMO - not many people have SWD-capable interfaces and SWD-capable targets. This way we can wait forever... A bugfix release would allow people to use official release that is recent, not 18 months old. I can help as much as I can, but I don't really know what skills are required so I don't know whether I'm able to do it by myself. And - again - I don't expect that release to be some milestone - just bugfix, that's why 0.4.1 number would be appropriate. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New development version of OpenOCD available at last!
On 2011-06-11 04:07, Xiaofan Chen wrote: On the other hand, I can understand what Freddie Chopin's point -- Windows users need a binary release and now many of the OpenOCD Windows users get the binaries from Freddie. And having a release version is important here. Maybe it is less important for Linux OpenOCD users since they can probably build from source by themselves. On the other hand, a release will still help -- so that distros can take it and package it. Exactly what I had in mind! Figure out what outstanding problems there are, work with the list to get them sorted out, etc. There are always outstanding problems out there. So there needs to be a cut off somewhere. In my opinion (my own tests and current messages on the list) currently there are no big problems, but with SWD implementation these will most likely appear soon. I think a release should be cut at either of these two points for a project like OpenOCD which is still very active and not reaching mature state. 1) Enough patches have been accumulated. 1) A certain time has been passed, say 6-months or one-year. And now both points are satisfied more than enough (; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
On 2011-06-10 22:29, Tomek CEDRO wrote: Michael, in this situation you probably simply don't want to shut down the OpenOCD and leave things as-is with your session active controlling the target. What is the point of leaving target in some specific state when OpenOCD is not running? It sounds crazy! When program quits target should behave as nothing was connected, this is so obvious that I don't really understand the point of this discussion. Full support here - for me after shutting down OpenOCD I'd like it to restore interface to initial state (in most cases - transparent). Sometimes - when the interface is placed inside some device it's difficult to physically disconnect it from the board - shutting down OpenOCD is much easier. I also don't understand why would you want interface and target to freeze in some specific state at OpenOCD exit - why don't just leave OpenOCD running then? We - who want it to soft-disconnect - have no alternative, as it's impossible to force initial state of interface with OpenOCD commands. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Outstanding patches = Fix: Correctly exit function: ft2232_init when an error occurred
On 2011-06-10 22:06, Peter Stuge wrote: And that just because the code does not have information, it should not make guesses. Restoring initial state of FT2232 interface is just like pulling a plug - disconnecting JTAG from board. I really see no danger in such operation... Physical disconnection can be even more random (some signals get disconnected sooner than other etc.) and noone sees that as a hazardous situation. Most probably some of you are trying to be uber-correct without any reason. The target will handle such SINGLE transient state without any problems - no risk of erasing flash or firing a nuke. It will most probably start running after reset and that's what we want. If you want it in some specific state, just leave OpenOCD running - what's the problem with that approach? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New development version of OpenOCD available at last!
On 2011-06-11 10:45, Michael Schwingen wrote: Nothing fancy - just declare the current master as -RC, and see if any critical bugs pop up during the next 2 weeks or so. I don't think this really requires fancy release management - if noone steps up as release manager, any release is better than none at all for1 year. You read my mind - I don't think we should create a list of things that are broken and need to be fixed ASAP before release. One of reasons for such stance - from what I see on the list, nothing is seriously broken right now. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New development version of OpenOCD available at last!
On 2011-06-07 23:04, Øyvind Harboe wrote: Nobody has stepped up to do the work of being a release manager. Please - cut a simple release now - nothing fancy, one or two RC, two weeks for feedback and voila. Reasons: 1. More or less - everything works, no fatal problems etc. 2. When SWD patches arrive, OpenOCD won't be stable/tested for some time probably, and release would be postponed for a LONG time. This way, now we would have 0.5.0 (call that bugfix release), and SWD will be in 0.6.0. Or maybe the release could be called 0.4.1 or whatever. It's been 18 months since release... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] Fix unused variable warnings (errors) detected with GCC 4.7.0 - dubious fixes
Hi!
I've investigated the remaining files a bit and... found nothing that
could still be unused inside them...
I post the patch with remaining changes, tell me what the errors are in
your build environment.
4\/3!!
From dcabbc362e50ce9c13acf71eb3516128b25d10fe Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Fri, 3 Jun 2011 22:10:03 +0200
Subject: [PATCH] Fix unused variable warnings (errors) detected with GCC
4.7.0 - leftover changes
---
src/jtag/drivers/usbprog.c |6 --
src/target/arm_simulator.c |9 -
src/target/etb.c | 10 --
3 files changed, 0 insertions(+), 25 deletions(-)
diff --git a/src/jtag/drivers/usbprog.c b/src/jtag/drivers/usbprog.c
index 17b0116..3b8a613 100644
--- a/src/jtag/drivers/usbprog.c
+++ b/src/jtag/drivers/usbprog.c
@@ -214,15 +214,9 @@ static void usbprog_end_state(tap_state_t state)
static void usbprog_state_move(void)
{
- int i = 0, tms = 0;
uint8_t tms_scan = tap_get_tms_path(tap_get_state(),
tap_get_end_state());
- int tms_count = tap_get_tms_path_len(tap_get_state(),
tap_get_end_state());
usbprog_jtag_write_tms(usbprog_jtag_handle, (char)tms_scan);
- for (i = 0; i tms_count; i++)
- {
- tms = (tms_scan i) 1;
- }
tap_set_state(tap_get_end_state());
}
diff --git a/src/target/arm_simulator.c b/src/target/arm_simulator.c
index 0f6fe3f..0a34cfc 100644
--- a/src/target/arm_simulator.c
+++ b/src/target/arm_simulator.c
@@ -666,15 +666,12 @@ static int arm_simulate_step_core(struct target *target,
}
else
{
- enum arm_mode mode = sim-get_mode(sim);
int update_cpsr = 0;
if (instruction.info.load_store_multiple.S)
{
if
(instruction.info.load_store_multiple.register_list 0x8000)
update_cpsr = 1;
- else
- mode = ARM_MODE_USR;
}
for (i = 0; i 16; i++)
@@ -722,7 +719,6 @@ static int arm_simulate_step_core(struct target *target,
uint32_t Rn = sim-get_reg_mode(sim,
instruction.info.load_store_multiple.Rn);
int bits_set = 0;
- enum arm_mode mode = sim-get_mode(sim);
for (i = 0; i 16; i++)
{
@@ -730,11 +726,6 @@ static int arm_simulate_step_core(struct target *target,
bits_set++;
}
- if (instruction.info.load_store_multiple.S)
- {
- mode = ARM_MODE_USR;
- }
-
switch
(instruction.info.load_store_multiple.addressing_mode)
{
case 0: /* Increment after */
diff --git a/src/target/etb.c b/src/target/etb.c
index 489b9ed..3cb2254 100644
--- a/src/target/etb.c
+++ b/src/target/etb.c
@@ -304,31 +304,21 @@ static int etb_write_reg(struct reg *reg, uint32_t value)
{
struct etb_reg *etb_reg = reg-arch_info;
uint8_t reg_addr = etb_reg-addr 0x7f;
- struct scan_field fields[3];
LOG_DEBUG(%i: 0x%8.8 PRIx32 , (int)(etb_reg-addr), value);
etb_scann(etb_reg-etb, 0x0);
etb_set_instr(etb_reg-etb, 0xc);
- fields[0].num_bits = 32;
uint8_t temp0[4];
- fields[0].out_value = temp0;
buf_set_u32(temp0, 0, 32, value);
- fields[0].in_value = NULL;
- fields[1].num_bits = 7;
uint8_t temp1;
- fields[1].out_value = temp1;
buf_set_u32(temp1, 0, 7, reg_addr);
- fields[1].in_value = NULL;
- fields[2].num_bits = 1;
uint8_t temp2;
- fields[2].out_value = temp2;
buf_set_u32(temp2, 0, 1, 1);
- fields[2].in_value = NULL;
return ERROR_OK;
}
--
1.7.4.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New development version of OpenOCD available at last!
I've just posted new compilation od OpenOCD on my website http://www.freddiechopin.info/index.php/en/articles/34-news/75-dostepna-nowa-rozwojowa-wersja-openocd-wreszcie I hope to keep up the recent schedule (new compilation every two months). BTW - is any release planed? 0.4.0 was downloaded almost 15k times from my website and it is almost 1.5 year old... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and PIC32MX795F512H- how?
Hi! New version of OpenOCD should be available on my website soon - we just have to get rid of some compilation errors... https://lists.berlios.de/pipermail/openocd-development/2011-June/019260.html 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cortex-M0 support ?
On 2011-06-06 14:17, Jonathan Dumaresq wrote: I wonder if openOCD have support for Cortex-M0 ? We just started working with NXP devices and I don’t see any support for the M0 in the Openocd script file… OpenOCD currently does not support SWD (only JTAG), thus it cannot support Cortex-M0. I don't know the status of SWD work - I haven't followed it for some time. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] Fix unused variable warnings (errors) detected with GCC 4.7.0 - dubious fixes
On 2011-06-04 09:48, Øyvind Harboe wrote: usbprog.c is clearly broken, I don't think this warning should be fixed as that would be shuffling a bug under the carpet. Maybe, but it compiles this way (; To me it seems that there was some old way of making things, then new way come and somebody forgot to remove old methods while introducing new methods. The code is broken anyway and nobody complained for a long long time - there was no functional change to usbprog.c for 1.5 year so either it works (and with my patch it will work the same way for 99%) or it does not and nobody cares (; Same goes for etb.c - no change in over a year. I've pushed most of the other fixes Some changes you did not merge look to me just like leftover helper-code. All changes from first patch just cannot change OpenOCD behavior. , but you'll need to run through two versions of GCC or try -O3 to get the residual warnings I think. Try: CFLAGS=-O3 -g ./configure make clean make Nothing more pops up. What next with the fragments that still cause warnings/errors? I was going to publish a new version on my website, but now I don't know whether I should wait a while for a better fix or maybe disable Werror and proceed... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] Fix unused variable warnings (errors) detected with GCC 4.7.0 - dubious fixes
On 2011-06-04 10:30, Øyvind Harboe wrote: I just wanted to merge those changes that were ready to go in as that was all I have time for this morning. Some of your changes broke compiling on gcc 4.4.3(generated more warnings), so I didn't want to put them in there yet. I think gcc 4.4.3 discovered more unused code once you removed some of that unused code. Ok, I'll wait then. Maybe I'll investigate on my own - just 4 files so maybe I'll find something. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/2] Fix unused variable warnings (errors) detected with GCC 4.7.0 - trivial fixes
From 4ddfcfae08c7413de09b8f08eb079a63fe609596 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Fri, 3 Jun 2011 22:10:03 +0200
Subject: [PATCH 1/2] Fix unused variable warnings (errors) detected with GCC
4.7.0 - trivial fixes
---
src/flash/nor/core.c |2 --
src/flash/nor/em357.c |3 ---
src/flash/nor/pic32mx.c |3 ---
src/flash/nor/stm32x.c|3 ---
src/flash/nor/str9x.c |3 ---
src/pld/virtex2.c |3 ---
src/rtos/rtos.c |5 ++---
src/server/gdb_server.c |3 +--
src/svf/svf.c |8 +++-
src/target/arm720t.c |5 -
src/target/arm920t.c | 10 --
src/target/arm926ejs.c|3 ---
src/target/arm946e.c |2 --
src/target/arm_adi_v5.c |6 ++
src/target/arm_disassembler.c |3 +--
src/target/arm_simulator.c|7 ---
src/target/armv4_5.c |2 --
src/target/breakpoints.c |4
src/target/dsp563xx.c | 14 +++---
src/target/embeddedice.c |5 ++---
src/target/etb.c | 10 --
src/target/mips32.c |4
src/target/mips32_pracc.c |8
src/target/smp.c |4 ++--
24 files changed, 16 insertions(+), 104 deletions(-)
diff --git a/src/flash/nor/core.c b/src/flash/nor/core.c
index ab1bf03..4b5fe7d 100644
--- a/src/flash/nor/core.c
+++ b/src/flash/nor/core.c
@@ -621,7 +621,6 @@ int flash_write_unlock(struct target *target, struct image
*image,
{
uint32_t buffer_size;
uint8_t *buffer;
- int section_first;
int section_last;
uint32_t run_address = sections[section]-base_address +
section_offset;
uint32_t run_size = sections[section]-size - section_offset;
@@ -649,7 +648,6 @@ int flash_write_unlock(struct target *target, struct image
*image,
}
/* collect consecutive sections which fall into the same bank */
- section_first = section;
section_last = section;
padding[section] = 0;
while ((run_address + run_size - 1 c-base + c-size - 1)
diff --git a/src/flash/nor/em357.c b/src/flash/nor/em357.c
index 8a3cf4c..a62be6a 100644
--- a/src/flash/nor/em357.c
+++ b/src/flash/nor/em357.c
@@ -813,7 +813,6 @@ COMMAND_HANDLER(em357_handle_lock_command)
COMMAND_HANDLER(em357_handle_unlock_command)
{
struct target *target = NULL;
- struct em357_flash_bank *em357_info = NULL;
if (CMD_ARGC 1)
{
@@ -826,8 +825,6 @@ COMMAND_HANDLER(em357_handle_unlock_command)
if (ERROR_OK != retval)
return retval;
- em357_info = bank-driver_priv;
-
target = bank-target;
if (target-state != TARGET_HALTED)
diff --git a/src/flash/nor/pic32mx.c b/src/flash/nor/pic32mx.c
index a8392eb..69321ac 100644
--- a/src/flash/nor/pic32mx.c
+++ b/src/flash/nor/pic32mx.c
@@ -313,11 +313,8 @@ static int pic32mx_erase(struct flash_bank *bank, int
first, int last)
static int pic32mx_protect(struct flash_bank *bank, int set, int first, int
last)
{
- struct pic32mx_flash_bank *pic32mx_info = NULL;
struct target *target = bank-target;
- pic32mx_info = bank-driver_priv;
-
if (target-state != TARGET_HALTED)
{
LOG_ERROR(Target not halted);
diff --git a/src/flash/nor/stm32x.c b/src/flash/nor/stm32x.c
index 3914d25..b4300be 100644
--- a/src/flash/nor/stm32x.c
+++ b/src/flash/nor/stm32x.c
@@ -1217,7 +1217,6 @@ COMMAND_HANDLER(stm32x_handle_lock_command)
COMMAND_HANDLER(stm32x_handle_unlock_command)
{
struct target *target = NULL;
- struct stm32x_flash_bank *stm32x_info = NULL;
if (CMD_ARGC 1)
{
@@ -1230,8 +1229,6 @@ COMMAND_HANDLER(stm32x_handle_unlock_command)
if (ERROR_OK != retval)
return retval;
- stm32x_info = bank-driver_priv;
-
target = bank-target;
if (target-state != TARGET_HALTED)
diff --git a/src/flash/nor/str9x.c b/src/flash/nor/str9x.c
index 303daa0..61a438f 100644
--- a/src/flash/nor/str9x.c
+++ b/src/flash/nor/str9x.c
@@ -681,7 +681,6 @@ static int get_str9x_info(struct flash_bank *bank, char
*buf, int buf_size)
COMMAND_HANDLER(str9x_handle_flash_config_command)
{
- struct str9x_flash_bank *str9x_info;
struct target *target = NULL;
if (CMD_ARGC 5)
@@ -700,8 +699,6 @@ COMMAND_HANDLER(str9x_handle_flash_config_command)
COMMAND_PARSE_NUMBER(u32, CMD_ARGV[3], bbadr);
COMMAND_PARSE_NUMBER(u32, CMD_ARGV[4], nbbadr);
- str9x_info = bank-driver_priv;
-
target = bank-target;
if (bank-target-state != TARGET_HALTED)
diff --git a/src/pld/virtex2.c b/src/pld/virtex2.c
index f4657bc..fdaeb61 100644
--- a/src/pld/virtex2.c
+++ b/src/pld/virtex2.c
[Openocd-development] [PATCH 2/2] Fix unused variable warnings (errors) detected with GCC 4.7.0 - dubious fixes
From 47280c11e16f2136ef4c4c7ffd89466985cc5faa Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Fri, 3 Jun 2011 22:13:35 +0200
Subject: [PATCH 2/2] Fix unused variable warnings (errors) detected with GCC
4.7.0 - dubious fixes
---
src/jtag/drivers/usbprog.c |6 --
src/target/arm11_dbgtap.c |4
src/target/arm_simulator.c |2 --
3 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/src/jtag/drivers/usbprog.c b/src/jtag/drivers/usbprog.c
index 17b0116..3b8a613 100644
--- a/src/jtag/drivers/usbprog.c
+++ b/src/jtag/drivers/usbprog.c
@@ -214,15 +214,9 @@ static void usbprog_end_state(tap_state_t state)
static void usbprog_state_move(void)
{
- int i = 0, tms = 0;
uint8_t tms_scan = tap_get_tms_path(tap_get_state(),
tap_get_end_state());
- int tms_count = tap_get_tms_path_len(tap_get_state(),
tap_get_end_state());
usbprog_jtag_write_tms(usbprog_jtag_handle, (char)tms_scan);
- for (i = 0; i tms_count; i++)
- {
- tms = (tms_scan i) 1;
- }
tap_set_state(tap_get_end_state());
}
diff --git a/src/target/arm11_dbgtap.c b/src/target/arm11_dbgtap.c
index 4e90933..5c671cc 100644
--- a/src/target/arm11_dbgtap.c
+++ b/src/target/arm11_dbgtap.c
@@ -1045,10 +1045,6 @@ static inline struct arm11_common *dpm_to_arm11(struct
arm_dpm *dpm)
static int arm11_dpm_prepare(struct arm_dpm *dpm)
{
- struct arm11_common *arm11 = dpm_to_arm11(dpm);
-
- arm11 = container_of(dpm-arm, struct arm11_common, arm);
-
return arm11_run_instr_data_prepare(dpm_to_arm11(dpm));
}
diff --git a/src/target/arm_simulator.c b/src/target/arm_simulator.c
index 905dd11..0a34cfc 100644
--- a/src/target/arm_simulator.c
+++ b/src/target/arm_simulator.c
@@ -666,7 +666,6 @@ static int arm_simulate_step_core(struct target *target,
}
else
{
- enum arm_mode mode = sim-get_mode(sim);
int update_cpsr = 0;
if (instruction.info.load_store_multiple.S)
@@ -720,7 +719,6 @@ static int arm_simulate_step_core(struct target *target,
uint32_t Rn = sim-get_reg_mode(sim,
instruction.info.load_store_multiple.Rn);
int bits_set = 0;
- enum arm_mode mode = sim-get_mode(sim);
for (i = 0; i 16; i++)
{
--
1.7.4.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Fix unused variable warnings (errors) detected with GCC 4.7.0
On 2011-06-02 08:12, Øyvind Harboe wrote: Perhaps you could split this patch into several patches with the first patch to go in are with the most obvious fixes? E.g. I was less sure about etb.c, but it might be fine... Any hints on the method to split such commited change into several commits? GIT is still not my strongest side (; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Compilation errors
Hi again! I've completely modified my build environment. Now I'm using current Ubuntu (on virtual machine) with most recent MinGW-W64 (32-bit for now, currently setting up 64-bit). The error with sscanf() is gone, but new GCC (4.7.0) is now more picky about non-used variables and it almost killed me with warnings=errors... I've fixed 26 files and I will provide a patch soon - I have to check it first (; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Fix unused variable warnings (errors) detected with GCC 4.7.0
Please review - I'm not sure about more drastic changes (removing some
function calls), however all of them seem correct. I've tested it and it
now compiles on my system, the executable works (no functional testing).
Cheers!
From dbec85dc76abee585d59e0a1f406a81945bc2189 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie@Ubuntu-VirtualBox.(none)
Date: Wed, 1 Jun 2011 22:18:38 +0200
Subject: [PATCH] Fix unused variable warnings (errors) detected with GCC 4.7.0
---
src/flash/nor/core.c |2 --
src/flash/nor/em357.c |3 ---
src/flash/nor/pic32mx.c |3 ---
src/flash/nor/stm32x.c|3 ---
src/flash/nor/str9x.c |3 ---
src/jtag/drivers/usbprog.c|6 --
src/pld/virtex2.c |3 ---
src/rtos/rtos.c |5 ++---
src/server/gdb_server.c |3 +--
src/svf/svf.c |8 +++-
src/target/arm11_dbgtap.c |4
src/target/arm720t.c |5 -
src/target/arm920t.c | 10 --
src/target/arm926ejs.c|3 ---
src/target/arm946e.c |2 --
src/target/arm_adi_v5.c |6 ++
src/target/arm_disassembler.c |3 +--
src/target/arm_simulator.c|9 -
src/target/armv4_5.c |2 --
src/target/breakpoints.c |4
src/target/dsp563xx.c | 14 +++---
src/target/embeddedice.c |5 ++---
src/target/etb.c | 10 --
src/target/mips32.c |4
src/target/mips32_pracc.c |8
src/target/smp.c |4 ++--
26 files changed, 16 insertions(+), 116 deletions(-)
diff --git a/src/flash/nor/core.c b/src/flash/nor/core.c
index ab1bf03..4b5fe7d 100644
--- a/src/flash/nor/core.c
+++ b/src/flash/nor/core.c
@@ -621,7 +621,6 @@ int flash_write_unlock(struct target *target, struct image
*image,
{
uint32_t buffer_size;
uint8_t *buffer;
- int section_first;
int section_last;
uint32_t run_address = sections[section]-base_address +
section_offset;
uint32_t run_size = sections[section]-size - section_offset;
@@ -649,7 +648,6 @@ int flash_write_unlock(struct target *target, struct image
*image,
}
/* collect consecutive sections which fall into the same bank */
- section_first = section;
section_last = section;
padding[section] = 0;
while ((run_address + run_size - 1 c-base + c-size - 1)
diff --git a/src/flash/nor/em357.c b/src/flash/nor/em357.c
index 8a3cf4c..a62be6a 100644
--- a/src/flash/nor/em357.c
+++ b/src/flash/nor/em357.c
@@ -813,7 +813,6 @@ COMMAND_HANDLER(em357_handle_lock_command)
COMMAND_HANDLER(em357_handle_unlock_command)
{
struct target *target = NULL;
- struct em357_flash_bank *em357_info = NULL;
if (CMD_ARGC 1)
{
@@ -826,8 +825,6 @@ COMMAND_HANDLER(em357_handle_unlock_command)
if (ERROR_OK != retval)
return retval;
- em357_info = bank-driver_priv;
-
target = bank-target;
if (target-state != TARGET_HALTED)
diff --git a/src/flash/nor/pic32mx.c b/src/flash/nor/pic32mx.c
index a8392eb..69321ac 100644
--- a/src/flash/nor/pic32mx.c
+++ b/src/flash/nor/pic32mx.c
@@ -313,11 +313,8 @@ static int pic32mx_erase(struct flash_bank *bank, int
first, int last)
static int pic32mx_protect(struct flash_bank *bank, int set, int first, int
last)
{
- struct pic32mx_flash_bank *pic32mx_info = NULL;
struct target *target = bank-target;
- pic32mx_info = bank-driver_priv;
-
if (target-state != TARGET_HALTED)
{
LOG_ERROR(Target not halted);
diff --git a/src/flash/nor/stm32x.c b/src/flash/nor/stm32x.c
index 3914d25..b4300be 100644
--- a/src/flash/nor/stm32x.c
+++ b/src/flash/nor/stm32x.c
@@ -1217,7 +1217,6 @@ COMMAND_HANDLER(stm32x_handle_lock_command)
COMMAND_HANDLER(stm32x_handle_unlock_command)
{
struct target *target = NULL;
- struct stm32x_flash_bank *stm32x_info = NULL;
if (CMD_ARGC 1)
{
@@ -1230,8 +1229,6 @@ COMMAND_HANDLER(stm32x_handle_unlock_command)
if (ERROR_OK != retval)
return retval;
- stm32x_info = bank-driver_priv;
-
target = bank-target;
if (target-state != TARGET_HALTED)
diff --git a/src/flash/nor/str9x.c b/src/flash/nor/str9x.c
index 303daa0..61a438f 100644
--- a/src/flash/nor/str9x.c
+++ b/src/flash/nor/str9x.c
@@ -681,7 +681,6 @@ static int get_str9x_info(struct flash_bank *bank, char
*buf, int buf_size)
COMMAND_HANDLER(str9x_handle_flash_config_command)
{
- struct str9x_flash_bank *str9x_info;
struct target *target = NULL;
if (CMD_ARGC 5)
@@ -700,8 +699,6 @@ COMMAND_HANDLER(str9x_handle_flash_config_command)
COMMAND_PARSE_NUMBER(u32, CMD_ARGV[3], bbadr
[Openocd-development] Compilation errors
Hi! I'm trying to compile new OpenOCD source (from git) in my crosscompilation setup but I see these errors: /../../src/rtos/'`rtos.c libtool: compile: i686-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../../src/rtos -I../.. -I../../../src -I../../src -DPKGDATADIR=\/usr/local/share/openocd\ -I../../../jimtcl -I../../jimtcl -Wno-sign-compare -g -O2 -D__USE_MINGW_ANSI_STDIO -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT librtos_la-rtos.lo -MD -MP -MF .deps/librtos_la-rtos.Tpo -c ../../../src/rtos/rtos.c -o librtos_la-rtos.o cc1: warnings being treated as errors ../../../src/rtos/rtos.c: In function ‘gdb_thread_packet’: ../../../src/rtos/rtos.c:147: error: unknown conversion type character ‘l’ in format ../../../src/rtos/rtos.c:147: error: too many arguments for format ../../../src/rtos/rtos.c:223: error: unknown conversion type character ‘l’ in format ../../../src/rtos/rtos.c:223: error: too many arguments for format ../../../src/rtos/rtos.c:320: error: unknown conversion type character ‘l’ in format ../../../src/rtos/rtos.c:320: error: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘int64_t *’ ../../../src/rtos/rtos.c:320: error: too many arguments for format ../../../src/rtos/rtos.c:473: error: unknown conversion type character ‘l’ in format ../../../src/rtos/rtos.c:473: error: too many arguments for format ../../../src/rtos/rtos.c:497: error: unknown conversion type character ‘l’ in format ../../../src/rtos/rtos.c:497: error: too many arguments for format Any hints for solving that? Should I try to use a different setup for compiling OpenOCD for Windows (both 32- and 64-bit) - if yes, what do you use? Currently I use i686-w64-mingw32 and x86_64-w64-mingw32 - is there a better option using up-to-date compilers? I had to comment out dlerror definition in jim-win32compat.h but that was simple to fix. The sscanf()s that cause errors look pretty wild... Thx for help! 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] lpc21xx: common target script
On 2011-01-09 23:50, Øyvind Harboe wrote: I don't think so, I'm not sure what you mean. So I'm not sure whether I know what you propose (; Your example is pretty cryptic for me (; In a free moment I'd be grateful for a better explanation of your idea. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] lpc21xx: common target script
Hi!
Here's another path which improves the idea.
I've come with a problem, that has two solutions. When a board (or
whatever) configures some event handlers (like reset init) this is
usually done like this:
$_TARGETNAME configure -event reset-init {
...
}
But now, _TARGETNAME is defined deep within init procedures and is
unavailable at this level. Solution 1 is to make _TARGETNAME global
(inside setup_lpc2xxx and before use). Solution 2 is to use real names
instead of variables (lpc2103.cpu instead of $_TARGETNAME). Which
would be prefered?
The same would be true for names like $_FLASHNAME and so on.
4\/3!!
From 3fad208e72dff84db40e95d9553944a105f2b977 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Sat, 8 Jan 2011 12:29:31 +0100
Subject: [PATCH] Add another level of procedures to LPC2xxx initialization -
procedures for specific targets (setup_lpcnumber) take core clock and adapter
clock as parameters. This way constant parameters (flash size and type,
CPUTAPID, etc.) do not need to be copied if one wishes to change the variable
parameters - like the core clock or adapter clock - in a board config file or
somewhere else.
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
tcl/target/lpc2103.cfg | 18 +++---
tcl/target/lpc2124.cfg | 18 +++---
tcl/target/lpc2129.cfg | 18 +++---
tcl/target/lpc2148.cfg | 18 +++---
tcl/target/lpc2294.cfg | 18 +++---
tcl/target/lpc2378.cfg | 18 +++---
tcl/target/lpc2478.cfg | 18 +++---
7 files changed, 105 insertions(+), 21 deletions(-)
diff --git a/tcl/target/lpc2103.cfg b/tcl/target/lpc2103.cfg
index 3aa590b..f55777f 100644
--- a/tcl/target/lpc2103.cfg
+++ b/tcl/target/lpc2103.cfg
@@ -2,8 +2,20 @@
source [find target/lpc2xxx.cfg]
-proc init_targets {} {
- # 32kB flash and 8kB SRAM, clocked with 12MHz crystal
+# parameters:
+# - core_freq_khz - frequency of core in kHz during flashing, usually equal to
connected crystal or internal oscillator, e.g. 12000
+# - adapter_freq_khz - frequency of debug adapter in kHz, should be 8x slower
than core_freq_khz, e.g. 1000
+
+proc setup_lpc2103 {core_freq_khz adapter_freq_khz} {
+ # 32kB flash and 8kB SRAM
# setup_lpc2xxx chip_name cputapid flash_size flash_variant
workarea_size core_freq_khz adapter_freq_khz
- setup_lpc2xxx lpc2103 0x4f1f0f0f 0x8000 lpc2000_v2 0x2000 12000 1500
+ setup_lpc2xxx lpc2103 0x4f1f0f0f 0x8000 lpc2000_v2 0x2000
$core_freq_khz $adapter_freq_khz
+}
+
+proc init_targets {} {
+ # default to core clocked with 12MHz crystal
+ echo Warning - assuming default core clock 12MHz! Flashing may fail if
actual core clock is different.
+
+ # setup_lpc2103 core_freq_khz adapter_freq_khz
+ setup_lpc2103 12000 1500
}
diff --git a/tcl/target/lpc2124.cfg b/tcl/target/lpc2124.cfg
index 94ac5be..0251738 100644
--- a/tcl/target/lpc2124.cfg
+++ b/tcl/target/lpc2124.cfg
@@ -2,8 +2,20 @@
source [find target/lpc2xxx.cfg]
-proc init_targets {} {
- # 256kB flash and 16kB SRAM, clocked with 12MHz crystal
+# parameters:
+# - core_freq_khz - frequency of core in kHz during flashing, usually equal to
connected crystal or internal oscillator, e.g. 12000
+# - adapter_freq_khz - frequency of debug adapter in kHz, should be 8x slower
than core_freq_khz, e.g. 1000
+
+proc setup_lpc2124 {core_freq_khz adapter_freq_khz} {
+ # 256kB flash and 16kB SRAM
# setup_lpc2xxx chip_name cputapid flash_size flash_variant
workarea_size core_freq_khz adapter_freq_khz
- setup_lpc2xxx lpc2124 0x4f1f0f0f 0x4 lpc2000_v1 0x4000 12000 1500
+ setup_lpc2xxx lpc2124 0x4f1f0f0f 0x4 lpc2000_v1 0x4000
$core_freq_khz $adapter_freq_khz
+}
+
+proc init_targets {} {
+ # default to core clocked with 12MHz crystal
+ echo Warning - assuming default core clock 12MHz! Flashing may fail if
actual core clock is different.
+
+ # setup_lpc2124 core_freq_khz adapter_freq_khz
+ setup_lpc2124 12000 1500
}
diff --git a/tcl/target/lpc2129.cfg b/tcl/target/lpc2129.cfg
index 10fcd0c..2c33cde 100644
--- a/tcl/target/lpc2129.cfg
+++ b/tcl/target/lpc2129.cfg
@@ -2,8 +2,20 @@
source [find target/lpc2xxx.cfg]
-proc init_targets {} {
- # 256kB flash and 16kB SRAM, clocked with 12MHz crystal
+# parameters:
+# - core_freq_khz - frequency of core in kHz during flashing, usually equal to
connected crystal or internal oscillator, e.g. 12000
+# - adapter_freq_khz - frequency of debug adapter in kHz, should be 8x slower
than core_freq_khz, e.g. 1000
+
+proc setup_lpc2129 {core_freq_khz adapter_freq_khz} {
+ # 256kB flash and 16kB SRAM
# setup_lpc2xxx chip_name cputapid flash_size flash_variant
workarea_size core_freq_khz adapter_freq_khz
- setup_lpc2xxx lpc2129 0xcf1f0f0f 0x4 lpc2000_v1 0x4000 12000 1500
+ setup_lpc2xxx lpc2129 0xcf1f0f0f 0x4
Re: [Openocd-development] [PATCH] lpc21xx: common target script
On 2011-01-07 17:11, Øyvind Harboe wrote: Hopefully we can make some progress towards simplifying the scripts going forward... I've come up with an improvement of the idea - I'll present the patch tomorrow. This will make it easier to create custom versions of specific targets (; Would you mind having a crack at the other LPC series scripts? You mean LPC17xx, LPC29xx and LPC3xxx? You know that I couldn't test any of those? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] LPC2xxx scripts
On 2011-01-07 17:18, Øyvind Harboe wrote: How about using named parameters instead? Is that possible? How would that be done? This could be very nice, as now the comment with explanation is necessary. The same is true for flash bank command. There is one con of such idea - the call to setup_lpc2xxx is pretty long now, adding names will make it even longer... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] lpc21xx: common target script
On 2011-01-07 17:22, Freddie Chopin wrote:
I've come up with an improvement of the idea - I'll present the patch
tomorrow. This will make it easier to create custom versions of specific
targets (;
Here is an example of lpc2103.cfg with this change (draft [; ):
# NXP LPC2103 ARM7TDMI-S with 32kB flash and 8kB SRAM, clocked with 12MHz
crystal
source [find target/lpc2xxx.cfg]
# parameters:
# - core_freq_khz - frequency of core in kHz during flashing, usually equal to
connected crystal or internal oscillator, e.g. 12000
# - adapter_freq_khz - frequency of debug adapter in kHz, should be 8x slower
than core_freq_khz, e.g. 1000
proc setup_lpc2103 {core_freq_khz adapter_freq_khz} {
# 32kB flash and 8kB SRAM
# setup_lpc2xxx chip_name cputapid flash_size flash_variant workarea_size
core_freq_khz adapter_freq_khz
setup_lpc2xxx lpc2103 0x4f1f0f0f 0x8000 lpc2000_v2 0x2000 core_freq_khz
adapter_freq_khz
}
proc init_targets {} {
# default to core clocked with 12MHz crystal
echo Warning - assuming default core clock 12MHz! Flashing may fail if
actual core clock is different.
# setup_lpc2103 core_freq_khz adapter_freq_khz
setup_lpc2103 12000 1500
}
As you see, there is another proc for configuring this specific part -
setup_lpc2103. This proc takes only two changeable parameters (for
regular user) in this equation: core clock and adapter clock. This
way when someone wishes to use lpc2103.cfg inside a board cfg file,
he/she does not have to copy/paste the parameters like cputapid, flash
size and type, etc. What do you think about this idea?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] lpc21xx: common target script
How about something like this?
4\/3!!
From d89da81ac005fd645522e620fee20cd6808a0af1 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Thu, 6 Jan 2011 12:48:05 +0100
Subject: [PATCH] Add common LPC2xxx setup procedure, use in all LPC2xxx files.
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
tcl/target/lpc2103.cfg | 35 +
tcl/target/lpc2124.cfg | 36 +-
tcl/target/lpc2129.cfg | 34 +---
tcl/target/lpc2148.cfg | 46
tcl/target/lpc2294.cfg | 36 --
tcl/target/lpc2378.cfg | 46 +---
tcl/target/lpc2478.cfg | 49 +--
tcl/target/lpc2xxx.cfg | 41
8 files changed, 85 insertions(+), 238 deletions(-)
create mode 100644 tcl/target/lpc2xxx.cfg
diff --git a/tcl/target/lpc2103.cfg b/tcl/target/lpc2103.cfg
index 7f14555..3aa590b 100644
--- a/tcl/target/lpc2103.cfg
+++ b/tcl/target/lpc2103.cfg
@@ -1,32 +1,9 @@
-# NXP LPC2103 ARM7TDMI-S with 32kB Flash and 8kB SRAM, clocked with 12MHz
crystal
+# NXP LPC2103 ARM7TDMI-S with 32kB flash and 8kB SRAM, clocked with 12MHz
crystal
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
- set _CHIPNAME lpc2103
-}
+source [find target/lpc2xxx.cfg]
-if { [info exists CPUTAPID ] } {
- set _CPUTAPID $CPUTAPID
-} else {
- set _CPUTAPID 0x4f1f0f0f
+proc init_targets {} {
+ # 32kB flash and 8kB SRAM, clocked with 12MHz crystal
+ # setup_lpc2xxx chip_name cputapid flash_size flash_variant
workarea_size core_freq_khz adapter_freq_khz
+ setup_lpc2xxx lpc2103 0x4f1f0f0f 0x8000 lpc2000_v2 0x2000 12000 1500
}
-
-reset_config trst_and_srst
-
-# reset delays
-adapter_nsrst_delay 100
-jtag_ntrst_delay 100
-
-jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
-
-set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME arm7tdmi -chain-position $_TARGETNAME
-
-# 8kB of internal SRAM
-$_TARGETNAME configure -work-area-phys 0x4000 -work-area-size 0x2000
-work-area-backup 0
-
-# 32kB of internal Flash, core clocked with 12MHz crystal
-# flash bank name lpc2000 base size 0 0 target# variant clock
[calc checksum]
-set _FLASHNAME $_CHIPNAME.flash
-flash bank $_FLASHNAME lpc2000 0x0 0x8000 0 0 $_TARGETNAME lpc2000_v2 12000
calc_checksum
diff --git a/tcl/target/lpc2124.cfg b/tcl/target/lpc2124.cfg
index df71bdd..94ac5be 100644
--- a/tcl/target/lpc2124.cfg
+++ b/tcl/target/lpc2124.cfg
@@ -1,33 +1,9 @@
-# NXP LPC2124
+# NXP LPC2124 ARM7TDMI-S with 256kB flash and 16kB SRAM, clocked with 12MHz
crystal
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
- set _CHIPNAME lpc2124
-}
+source [find target/lpc2xxx.cfg]
-if { [info exists CPUTAPID ] } {
- set _CPUTAPID $CPUTAPID
-} else {
-set _CPUTAPID 0x4f1f0f0f
+proc init_targets {} {
+ # 256kB flash and 16kB SRAM, clocked with 12MHz crystal
+ # setup_lpc2xxx chip_name cputapid flash_size flash_variant
workarea_size core_freq_khz adapter_freq_khz
+ setup_lpc2xxx lpc2124 0x4f1f0f0f 0x4 lpc2000_v1 0x4000 12000 1500
}
-
-reset_config trst_and_srst
-
-# reset delays
-adapter_nsrst_delay 100
-jtag_ntrst_delay 100
-
-adapter_khz 1000
-
-#jtag scan chain
-jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
-
-set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME arm7tdmi -chain-position $_TARGETNAME
-
-$_TARGETNAME configure -work-area-phys 0x4000 -work-area-size 0x4000
-work-area-backup 0
-
-# flash bank name lpc2000 base size 0 0 target# variant clock
[calc checksum]
-set _FLASHNAME $_CHIPNAME.flash
-flash bank $_FLASHNAME lpc2000 0x0 0x4 0 0 $_TARGETNAME lpc2000_v1 14745
calc_checksum
diff --git a/tcl/target/lpc2129.cfg b/tcl/target/lpc2129.cfg
index 2587bf7..10fcd0c 100644
--- a/tcl/target/lpc2129.cfg
+++ b/tcl/target/lpc2129.cfg
@@ -1,31 +1,9 @@
-# NXP LPC2129
+# NXP LPC2129 ARM7TDMI-S with 256kB flash and 16kB SRAM, clocked with 12MHz
crystal
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
- set _CHIPNAME lpc2129
-}
+source [find target/lpc2xxx.cfg]
-if { [info exists CPUTAPID ] } {
- set _CPUTAPID $CPUTAPID
-} else {
- set _CPUTAPID 0xcf1f0f0f
+proc init_targets {} {
+ # 256kB flash and 16kB SRAM, clocked with 12MHz crystal
+ # setup_lpc2xxx chip_name cputapid flash_size flash_variant
workarea_size core_freq_khz adapter_freq_khz
+ setup_lpc2xxx lpc2129 0xcf1f0f0f 0x4 lpc2000_v1 0x4000 12000 1500
}
-
-reset_config trst_and_srst
-
-# reset delays
-adapter_nsrst_delay 100
-jtag_ntrst_delay 100
-
-#jtag scan chain
-jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
-
-set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME arm7tdmi
Re: [Openocd-development] [PATCH] lpc21xx: common target script
On 2011-01-06 13:00, Øyvind Harboe wrote: What about the reset-init sequences? E.g. LPC2478 has a reset-init sequence that is gone here, so this would break flash programming. Can or should the reset-init sequences be pretty much centralized too? Are they simply missing from some of the other files? I can't say that for sure (I cannot check that), but I think that these reset-init sequences are no longer valid / necessary since srst_pulls_trst was removed. Basically all these procedures did was change state to ARM and force flash to be remapped on the address 0. Now - since halt is possible right after reset, the core state is ARM (there is no chance that a running code changed that to thumb before halt), and forcing the remap is probably not good too, because after this early halt the bootloader code should be executed anyway. This should not affect flashing, as this is done via special ISP commands in LPC2xxx - these commands don't care for remap. LPC2103 (which I have) worked for me without any additional steps - forcing ARM state or remap. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] lpc21xx: common target script
On 2011-01-05 20:02, Øyvind Harboe wrote: Going twice... I'd just like to say, that I like the idea but all LPC2xxx family can have only one common script, as there are no differences in how OpenOCD handles these chips. If you want to make that in several steps - fine, but the lpc21xx.cfg file can be renamed to lpc2xxx.cfg and used as it is right now. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] lpc21xx: common target script
On 2011-01-05 23:00, Øyvind Harboe wrote: On Wed, Jan 5, 2011 at 10:55 PM, Freddie Chopinfreddie_cho...@op.pl wrote: On 2011-01-05 20:02, Øyvind Harboe wrote: Going twice... I'd just like to say, that I like the idea but all LPC2xxx family can have only one common script, as there are no differences in how OpenOCD handles these chips. If you want to make that in several steps - fine, but the lpc21xx.cfg file can be renamed to lpc2xxx.cfg and used as it is right now. Would you like to pick up these patches and submit your version? I'm just trying to get the ball rolling by showing a first step and your help here would be much appreciated! I will try to do that, as I have 4 almost-free days... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] lpc2x78: share more between config scripts
On 2010-12-26 17:54, Øyvind Harboe wrote: tcl/target/lpc2x78.cfg | 32 Wouldn't that be better to just add lpc2xxx.cfg file? Whole LPC2xxx family is quite the same if OpenOCD is concerned... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] stm32: add dual flash bank support
On 2010-12-22 18:31, Spencer Oliver wrote: - 0xdf, 0xf8, 0x20, 0x40, /* ldr r4, STM32_FLASH_BASE */ + 0x08, 0x4c, /* ldr r4, STM32_FLASH_BASE */ How is that possible? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] stm32: add stm32 xl family flash support
On 2010-12-22 18:31, Spencer Oliver wrote:
diff --git a/tcl/target/stm32.cfg b/tcl/target/stm32.cfg
index 86e6ebb..eef1269 100644
--- a/tcl/target/stm32.cfg
+++ b/tcl/target/stm32.cfg
@@ -52,18 +52,22 @@ if { [info exists BSTAPID ] } {
set _BSTAPID4 0x06414041
# Connectivity line devices, Rev A and Rev Z
set _BSTAPID5 0x06418041
+ # XL line devices, Rev A
+ set _BSTAPID6 0x06430041
}
jtag newtap $_CHIPNAME bs -irlen 5 -expected-id $_BSTAPID1 \
-expected-id $_BSTAPID2 -expected-id $_BSTAPID3 \
- -expected-id $_BSTAPID4 -expected-id $_BSTAPID5
+ -expected-id $_BSTAPID4 -expected-id $_BSTAPID5 \
+ -expected-id $_BSTAPID6
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position
$_TARGETNAME
$_TARGETNAME configure -work-area-phys 0x2000 -work-area-size
$_WORKAREASIZE -work-area-backup 0
+# flash size will be probed
set _FLASHNAME $_CHIPNAME.flash
-flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME stm32x 0x0800 0 0 0 $_TARGETNAME
# if srst is not fitted use SYSRESETREQ to
# perform a soft reset
diff --git a/tcl/target/stm32xl.cfg b/tcl/target/stm32xl.cfg
new file mode 100644
index 000..cde07df
--- /dev/null
+++ b/tcl/target/stm32xl.cfg
@@ -0,0 +1,6 @@
+# script for stm32xl family (dual flash bank)
+source [find target/stm32.cfg]
+
+# flash size will be probed
+set _FLASHNAME $_CHIPNAME.flash1
+flash bank $_FLASHNAME stm32x 0x0808 0 0 0 $_TARGETNAME
If there is another target file for XL devices, maybe the BSTAPIDs
shouldn't be added to stm32.cfg file, but rather provided in stm32xl.cfg
before including stm32.cfg?
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Help needed for SAM3S4C
On 2010-12-20 15:58, Kenan Özdemir wrote: I already turned off the optimization, and there is no return in my main. my code looks like this: ... I reduced it a lot to find the error, but it always jumps to the same address. So as you can see I dont return from main... Show the whole disassembly and the compilation command. In 99,666% cases the root cause of problem is NOT a compiler bug and I bet this one is no different. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] tcl/board: Fix ST URLs in stm32* eval board configuration files
According to ST datasheets the last two characters (usually -T6) stand for package type (T = LQFP) and temperature range (6 - industrial). These two are not very informative and not very important, so I'd be for omitting them every time. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 flash
On 2010-12-14 17:35, Alan Bowman wrote: I have just connected my JTAGkey2 to a new STM32E-EVAL board, and have found that I am unable to program/erase the onboard flash. When I first connected to the target, I was warned that there was an unrecognised BS tap ID. I added an extra expected-id to my config file (0x06430041) and that allowed me to connect without errors. When I came to erase the flash using stm32x mass_erase 0 I received the following error: device id = 0x10006430 Cannot identify target as a STM32 family. I am using openOCD 0.4.0, but looking through the latest repository code, I think that I would get the same error. I think it is just that recognition of the larger family of STM32s (I have an STM32F103ZG on my board, one of the later eval boards) have not been added to OpenOCD. It looks like it should be a handful of lines to add the extra devices/flash - is this true, or have I missed some subtle reason why this isn't easy to support? I would make the change and try it out but I'm not currently able to rebuild from source on my Windows platform. I wanted to see if there was a good reason why it wasn't worth doing before going down that route. I guess it's just not supported yet - you can add those lines and it will work. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On 2010-12-09 10:07, Peter Stuge wrote: I'm hoping to hear test results from Rolf soon, as long as he does not discover any problem I think the patch should be committed. I'm afraid they are hoping that we get bored with waiting for any reply or decision, and that this good idea will die. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On 2010-12-06 00:35, Rolf Meeser wrote: Copy protection of LPC controllers relies on the fact that it is not possible to halt the processor right after reset. If your findings were correct, you would have discovered an easy way to circumvent NXP's security mechanism. The copy protection still works fine - as soon as it's enabled JTAG access is impossible and no reset_config options can change this. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
On 2010-12-08 06:57, Peter Stuge wrote: Freddie Chopin wrote: I've CCed Peter Stuge, as he's another person that has different opinion on this subject than official version from NXP. Thanks. U'r welcome [; I will violently oppose any attempt to add the option back to config files for 2148 and 1768. Expect all sorts of bits and bytes thrown at you. It has wasted enough of my life time already thank you very much. Right now we need to violently demand this patch to be committed ; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
I've CCed Peter Stuge, as he's another person that has different opinion on this subject than official version from NXP. On 2010-12-07 20:45, Rolf Meeser wrote: The problem is that in fact LPC2000 targets need the srst_pulls_trst option. Your claim is: The srst_pulls_trst option doesn't apply to LPC2000 devices, and therefore must be removed from the target scripts. And this is your argument: I can show that I'm able to stop the CPU before it executes the first instruction of my code. I want to show that your argument is invalid. The srst_pulls_trst option must be applied to targets that reset the TAP controller when the system reset is applied. LPC2000 (except LPC28xx/29xx) is such a target. While RESET input is active, you cannot access the TAP controller. As a consequence it is not possible to keep the device in reset state, set a breakpoint at 0, release reset, and have the CPU stop at 0 before it executes the first instruction. For LPC2000 you must release the reset in order to get access to the TAP controller. As getting access takes quite a few JTAG clock cycles, the CPU will inevitably execute code. Now this is perhaps what causes some confusion: It's not the user firmware that gets executed after reset, it's *always* the primary boot code! Without looking in detail at what you've done, I admit that it is indeed possible to stop an LPC2000 before it executes the user firmware. However, it is not possible to stop the CPU before it executes *any* code. Boot code always starts running. srst_pull_trst must remain in the LPC2000 target configurations. If what you say is true, than why I was able to halt the chip after reset at address 0 with MEMMAP still selecting bootloader? Don't you think that bootloader code would change MEMMAP value after it's executed? After normal reset (after which the chip is running) and halting the chip some time later at address 0 I see my code, MEMMAP is changed (not by me) to 1. When I do reset halt (when reset_config is separate), at address 0 I can see the code of the bootloader, MEMMAP value is 0. Here a simple experiment that shows that you're wrong. reset_config trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain reset halt JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x00d3 pc: 0x NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'. NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'. mdw 0xe01fc040 0xe01fc040: arm disassemble 0 16 0x 0xe59f201c LDR r2, [r15, #0x1c] 0x0004 0xe3a03000 MOV r3, #0x0 0x0008 0xe1020093 SWP r0, r3, [r2] 0x000c 0xe2822028 ADD r2, r2, #0x28 0x0010 0xe1021093 SWP r1, r3, [r2] 0x0014 0xe3c03007 BIC r3, r0, #0x7 0x0018 0xe5023028 STR r3, [r2, #-0x28] 0x001c 0xe51ff004 LDR r15, [r15, #-0x4] 0x0020 0x7fffe178 SVC 0xffe178 0x0024 0xe002c014 AND r12, r2, r4, LSL r0 0x0028 0xe01fc000 ANDS r12, r15, r0 0x002c 0x ANDEQ r0, r0, r0 0x0030 0x ANDEQ r0, r0, r0 0x0034 0x ANDEQ r0, r0, r0 0x0038 0x ANDEQ r0, r0, r0 0x003c 0x ANDEQ r0, r0, r0 bp 0 4 hw breakpoint set at 0x resume target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x60d3 pc: 0x mdw 0xe01fc040 0xe01fc040: 0001 arm disassemble 0 16 0x 0xe59f00a4 LDR r0, [r15, #0xa4] 0x0004 0xe580 STR r0, [r0] 0x0008 0xea04 B 0x0020 0x000c 0xe1a0 NOP 0x0010 0xe1a0 NOP 0x0014 0xc460ff58 STRGTBT r15, [r0], #-0xf58 0x0018 0xe1a0 NOP 0x001c 0xe1a0 NOP 0x0020 0xe59fd088 LDR r13, [r15, #0x88] 0x0024 0xe321f0d1 MSR CPSR_c, 0x00d1 0x0028 0xe59fd084 LDR r13, [r15, #0x84] 0x002c 0xe321f0d2 MSR CPSR_c, 0x00d2 0x0030 0xe59fd080 LDR r13, [r15, #0x80] 0x0034 0xe321f0d7 MSR CPSR_c, 0x00d7 0x0038 0xe59fd07c LDR r13, [r15, #0x7c] 0x003c 0xe321f0db MSR CPSR_c, 0x00db As you see I can halt the code at 0, MEMMAP is 0 (bootloader), at address 0 I see bootloader code. I set the breakpoint at 0, resume, the breakpoint is hit, MEMMAP is 1 (flash), at address 0 I see my code. Tell me where I'm wrong, but try to show an example that proves your point, because my LPC2103 clearly behaves differently than you'd expect it to. You say this option is required, I say it's not, the experiments show reliable debugging etc. so where's the problem?
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 19:29, Michael Schwingen wrote: Just because the current files are hard-wired in a way that suits you does not mean they work fine for everyone. Have you considered opposite approach? Just because the need of creating another file suits you does not mean this is fine for everyone. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-05 10:13, Andrew Leech wrote: On 05/12/2010, at 7:49 PM, Freddie Chopinfreddie_cho...@op.pl wrote: On 2010-12-04 19:29, Michael Schwingen wrote: Just because the current files are hard-wired in a way that suits you does not mean they work fine for everyone. Have you considered opposite approach? Just because the need of creating another file suits you does not mean this is fine for everyone. Just to throw in a suggestion, would it simply be better to have a hardwired default that can be overridden in the config file? For me that solves the issue discussed in this thread - I've even created a modification of this patch that has a default value: https://lists.berlios.de/pipermail/openocd-development/2010-December/017408.html 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
Oh - another solution is creating a board file that defines all that is necessary. Such board file could also define some default values of reset_config, adapter_khz etc. I'm starting to like that idea (; The only problem is the amount of new files that would be created this way... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
So how about this idea of removing useless and wrong occurences of srst_pulls_trst from lpc config files? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 00:00, Michael Schwingen wrote: On 12/03/2010 11:11 PM, Freddie Chopin wrote: How can this be unreliable? LPC23xx/LPC24xx after reset use 4MHz internal clock. Doing reset halt sets that clock and prevents any code from changing that (let's not talk about broken cases, because a broken case can be found everywhere), so what's wrong with this approach? So flashing is only supported after reset halt? That adds another step during development in case I work with different clock settings. That's what I meant by broken: flashing does not work until I bring the board into some configuration (reset halt) that is different from what I normally need. So you're all about correctness and you don't reset halt the chip before flashing? How is that correct? Actually flashing does not work if you don't reset halt the chip. The need for halting is obvious. The need for reset is not, but think about what would happen if your code would have a timer (or any) interrupt enabled and running during your flashing. Actually you DO need to get the chip in some known (and specific!) condition to flash it. Moreover - the new config file works exactly the same way - you can specify the clock as a parameter, but to be sure about it you need to reset halt or reset init. Why use big chip? LPC2478 has an LCD driver, and there is no chip with LCD driver that has less flash. Because for developement of the project you take big chip just-in-case, and choose right one (regarding flash size) for production when the code is ready. Anyway - we should be talking about the average size of the upload, and that's never 512kB - the code has to grow from 0 to this size during developement. BTW - you use libusb of ftd2xx (if you use Windows and FT2232 based JTAG)? I'm asking because if waiting 10s is worth breaking configurations of OpenOCD's regular users, then I hope you use the fastest library for the process. C'mon! 10s?! Don't read mailing lists and that will save you much more time (; It's not about the total amount of time, it is about interrupting my work on every upload. Now how is the operating system I use relevant for this discussion? Just because some things in OpenOCD might be improved does not mean that we should slow down other operations as well - for no benefit, just because you declare that it should be good enough for everyone. Operating system matters because ftd2xx is faster only on Windows - in Linux it's slower or the same. I'm not telling slow down - I'm saying don't use this file that can speed things up because it also makes using OpenOCD a bit harder. Technically this file does not speed anything up, because there is no PLL setting anywhere in it - the new board config file (another patch) does speed things up and it can speed things up exactly the same way now or when lpc2478.cfg would use some default value. BTW why isn't the pll configuration function placed in target file? Then let's provide a board config file that works fine on those barebone applications where OpenOCD does not need to know anything beyond the CPU. But there's no point in having a board file that in reality is not for board but for target, that will do nothing more than include target file... What for? What does that make easier? If one has it's own board with some chip I don't think one would look for config scripts in board directory... I wouldn't. Please - try to make OpenOCD more user-friendly, not user-hostile! The config file you need *is* for a board, so it belongs in the board directory. The LPC target alone can not know the clock used. If I'd have the microcontroller hooked up directly to JTAG and PSU with thin cables would that be considered a board too? It's just a simple microcontroller! It needs almost none configuration on OpenOCD's side - every board with LPC2478 was using the old file and it was fine. The problem is that right now OpenOCD provides all I need, because there is no lpc2478_std config file, lpc2478.cfg works just fine - I (and anyone willing to use OpenOCD with that chip) would have to create it first. Same amount of typing and user experience? I doubt it - right now I don't need to know ANYTHING about tcl, OpenOCD's config files etc. They work out-of-the-box. People working with more complex boards are not forbidden to set right clock speed now. Actually I think they managed, because I've not seen any complaints... Um - no. I proposed to add that file to OpenOCD, so no user would need to learn TCL or write his own config file - just like it is now. You said use some file, not I'll add that to OpenOCD... I've made a proposal to create target files for every chip that OpenOCD could support and organize them neatly in directories. This has a disadvantage of having hundreds of files. Your approach (having board file just because target file was made dependent on some parameters) creates a need for otherwise useless files... It is not useless - it enables other
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 00:32, Rolf Meeser wrote: This is a misconception. When OpenOCD tries to take control after a reset, the CPU is already running. ISP mode or existing user firmware may or may not have changed the clock tree. Like it or not, but there is no a priori knowledge of CPU clock. When doing reset halt (which would halt the chip immediately after reset) the clock would be 4MHz. With LPC23xx you are in the same situation as with older LPC2000 which required an external crystal. The operating frequency is *not* a target parameter, it is a board/application parameter. Indeed - older LPCs don't work this way, because there is no internal oscillator. So why change lpc2478.cfg that CAN work with default value, and leave all older files that CAN'T? C'mon! 10s?! Don't read mailing lists and that will save you much more time (; I'm afraid but professional embedded development is different. Speed matters. Why would I renounce the comfort of a fast download when I can get it for free? I want OpenOCD to be as efficient as possible. If you don't like that, you may always run at a slower clock, and help yourself with a cup of tea. I like that I can take my mind off firmware for a few seconds and trade a few words with a co-worker sitting next to me. Actually professional embedded development in here must not look like in your place - we're not racing for the fastest upload on the market, because the client probably would not care if you could deliver the product a few hours earlier due to these tremendous savings on upload time (; But there's no point in having a board file that in reality is not for board but for target, that will do nothing more than include target file... What for? What does that make easier? If one has it's own board with some chip I don't think one would look for config scripts in board directory... I wouldn't. Please - try to make OpenOCD more user-friendly, not user-hostile! That's the whole point of OpenOCD's layered config file approach. Do you refuse to work with an LPC2138 device just because its target config file cannot include a clock frequency? There is no way to avoid a board file here. And at the risk of repeating myself, the situation for LPC23xx is the same. I've stated on multiple occasions that for me this whole policy is wrong. As for the second paragraph, you are wrong. All LPC2xxx target config files have that frequency embedded without possibility to change with some parameters in board config files and - somehow - people manage to use it without problems. And I like those files very much, because they work standalone, so in my favorite way. The problem is that right now OpenOCD provides all I need, because there is no lpc2478_std config file, lpc2478.cfg works just fine - I (and anyone willing to use OpenOCD with that chip) would have to create it first. Same amount of typing and user experience? I doubt it - right now I don't need to know ANYTHING about tcl, OpenOCD's config files etc. They work out-of-the-box. People working with more complex boards are not forbidden to set right clock speed now. Actually I think they managed, because I've not seen any complaints... Why can't you do with LPC2478 what you *must* do with LPC2148? I'm not getting it. We're talking about a three-liner: 1. your interface, 2. your clock frequency, 3. your target. That's clearly a no-brainer! I don't have to do that with ANY LPC2xxx file now. You're wrong here, because all these target files have frequency embedded inside without any parameters. Just for the record - typing names of 2 files in command line is more-no-brainer than creating a config file that includes them. I have a crazy idea - I think it is possible to measure frequency of the external crystal (and check for it's existence) with simple code using one timer. This way OpenOCD would work without specifying this frequency. It could then - before programming - measure it (backup-ing all settings of timer), switch PLL to max value (using external crystal or internal resonator, also backup-ing all settings of clock and PLL), flash, revert all changes made to clock, PLL and timer and voila [; Problem gone Nice idea. However, that goes way beyond what is required right now to get reliable programming at the maximum possible speed. Also, will this work without a reset init to get the system into a known state? I was thinking about embedding that within OpenOCD's flash handling code specific for LPC, not in config files. Right now you have to supply that speed, with such wise flashing algorithm this parameter would be useless (could be provided, could be omitted - freq would be measured then). Deep inside I have a feeling that this proposal is on a head-on collision course with your wish for simplicity... Technically, I do not know how you want to measure frequency without a timing reference. And why on earth would I *temporarily* enable the PLL to circumvent the difficulty of
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 12:05, Rolf Meeser wrote: When doing reset halt (which would halt the chip immediately after reset) the clock would be 4MHz. Wrong. I've explained that often enough. So you say that after reset and immediate halt the chip clock (for new LPCs) is not 4MHz? Are you working for NXP and do you know something that's not public? Because the manuals say something different than you. Bootloader has nothing to do with it, as reset halt will prevent it from running and changing anything. Indeed - older LPCs don't work this way, because there is no internal oscillator. So why change lpc2478.cfg that CAN work with default value, and leave all older files that CAN'T? No, the lpc2478.cfg *CANNOT* work with a default, because there is none. You say there is none, I say there is. There's no way we can agree. Are you blaming me for not having changed all the other lpc2xxx.cfg files yet? I promise I *will* change them all. They *must* be changed. See below. Sure - OpenOCD can be changed so that other - easier to use - tools would be more and more popular. For me this policy is right. I'm willing to state this on as many occasions as required. I can also say it's wrong anytime, so obviously we cannot agree on that subject too. Look at the ever so perfect standalone configs: lpc2148.cfg: The clock frequency is hard-coded as 14.756 MHz. Nobody will ever use this device with a 14.756 MHz crystal. Nobody. Never. Now assuming a realistic crystal of 12 MHz, the gentle user will use the device outside spec. With a 24 MHz crystal he might still be able to program the flash and verify correctly. Unfortunately he will have field returns, because the devices will certainly start failing after six months or so. This has already happened. Changing these 5 numbers is pretty straightforward and people do that (as OpenOCD works for them). I do. And are you saying that programming flash with wrong speed causes it to fail LATER? Again - do you have some secret knowledge from NXP that general public doesn't? lpc2103.cfg: The clock frequency is hard-coded as 12 MHz. So you're saying is that anybody using crystals of 10, 14.756, 16, 18.432, 20, 24 MHz has to accept that flashing won't work for him? Just because you don't mind failures here and then? Obviously this device cannot be used with 14.765 crystal because LPC2148 also cannot (see your paragraph above) - I don't know why is that, but if you say so... I don't have to do that with ANY LPC2xxx file now. You're wrong here, because all these target files have frequency embedded inside without any parameters. You don't do it now? Then you're failing *miserably*. Having embedded frequencies in the target files is plain wrong. It *DOESN'T* work. It works because I set the right frequency in files. This is pretty simple because I usually see no reason to use crystals different than 12MHz. Yes, this must be plain wrong, and you must be plain right, as the world is black and white. Ease of use does not matter, the most important thing is to be ultra-correct with everything. Do you actually care about the users, or maybe you're affiliated with Keil or IAR and your goal is to make using OpenOCD harder? Really - your change does nothing more than make OpenOCD harder to use, as everyone could change that frequency before that (and they did, as people were using OpenOCD successfully with those chips for a long time), but to do that no additional file was required. Again (and again) - default (whatever they may or may not be) values with warning for ALL LPC config files are GOOD. Adding board files with such default value is exactly the same as leaving default value inside target files. You loose nothing, we gain easy use and we are warned that this may fail in some way or another. Alternatively you may want to make that work: openocd -c set FREQ 12345 -f interface/... -f target/... Because now it does not work (at least it didn't work the last time I've tried). It would also be fine. The need for obligatory creation of otherwise useless files is not fine. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 12:05, Rolf Meeser wrote: For me this policy is right. I'm willing to state this on as many occasions as required. Speaking about this right/wrong policy - it's said that reset_config does not belong to target config files, yet you haven't changed that, but left these wrong command there... How come? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 13:59, Rolf Meeser wrote: Definitely my last post on this thread. If that's the case then there's no need to reply... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-04 13:59, Rolf Meeser wrote: Definitely my last post on this thread. On 12/04/2010 12:33 PM, Freddie Chopin wrote: On 2010-12-04 12:05, Rolf Meeser wrote: When doing reset halt (which would halt the chip immediately after reset) the clock would be 4MHz. Wrong. I've explained that often enough. So you say that after reset and immediate halt the chip clock (for new LPCs) is not 4MHz? Are you working for NXP and do you know something that's not public? Because the manuals say something different than you. Bootloader has nothing to do with it, as reset halt will prevent it from running and changing anything. One last time. OpenOCD cannot halt an LPC2000 immediately after reset. It must let the CPU run, then try to gain control over the CPU as fast as possible. How fast it can do that depends on the JTAG clock and on delay settings. By the time OpenOCD has taken control, the CPU may have entered ISP mode (it does that if the flash contains no user firmware). In that case the clock will be 14.748 MHz, and not 4 MHz anymore. If there is valid user firmware, this firmware may have set the PLL to any value you like, leaving you with an unknown clock frequency. This process is not under your control. The only possible conclusion is that you cannot have knowledge of the CPU frequency even after reset halt. As a side note: This is the reason why PLL initialization of an LPC2000 device should first disconnect and disable the PLL before it configures/starts/connects it again. If the device runs standalone, this step is unnecessary (the PLL is off after reset). However, if you debug the application via JTAG, things are different: Your JTAG box may not be able to stop the CPU before the firmware starts the PLL. The debugger will then just set the program counter to 0, so that it *appears* to be the reset state. But it isn't. Running PLL initialization again on the now already connected PLL will let your system crash. That's a fact which you should accept. Not only because I do indeed work for NXP. You may work for NXP, but you are wrong on this one. OpenOCD can halt the core before any instructions are executed. You may not believe me, but I've checked that. I've created a code that changes the value of Timer0 TC register in the second instruction (the first one is loading the address of this register): ldr r0, =0xe0004008 str r0, [r0] After this instruction this register should have a value equal to its address. Value after reset is 0. Remember that this is the very first code that will be executed! There is no vector table, these two instructions are placed at address 0 in flash. Value of this register is not used anywhere else, the timer itself also isn't. Open On-Chip Debugger reset_config trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain reset halt JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) srst pulls trst - can not reset into halted mode. Issuing halt after reset. target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x801f pc: 0x0124 mdw 0xe0004008 1 0xe0004008: e0004008 resume halt target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x801f pc: 0x0124 mdw 0xe0004008 1 0xe0004008: e0004008 reset_config separate trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain reset halt JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x00d3 pc: 0x mdw 0xe0004008 1 0xe0004008: resume halt target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x801f pc: 0x0170 mdw 0xe0004008 1 0xe0004008: e0004008 As you see having reset_config separate allows you to halt the chip immediatelly after reset - the value of Timer0 TC after reset halt is 0. That's why having default value (when having reset_config separate) actually is possible for the parts that have internal oscillator. The core is halted even before executing the code of internal LPC bootloader... I can see the first instructions of it, changing MEMMAP makes it possible to see the code I'm talking about above. mdw 0xe01fc040 0xe01fc040: arm disassemble 0 64 0x 0xe59f201c LDR r2, [r15, #0x1c] 0x0004 0xe3a03000 MOV r3, #0x0 0x0008 0xe1020093 SWP r0, r3, [r2] 0x000c 0xe2822028 ADD r2, r2, #0x28 0x0010 0xe1021093 SWP r1, r3, [r2] 0x0014 0xe3c03007 BIC r3, r0, #0x7 0x0018 0xe5023028 STR r3, [r2, #-0x28] 0x001c 0xe51ff004 LDR r15, [r15, #-0x4] 0x0020 0x7fffe178 SVC 0xffe178 0x0024 0xe002c014 AND r12, r2, r4, LSL r0 0x0028 0xe01fc000 ANDS r12
[Openocd-development] [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
This is directly related to the findings from this post:
https://lists.berlios.de/pipermail/openocd-development/2010-December/017405.html
I've only removed srst_pulls_trst and comments that mentioned that (and
comments that were not very helpful)
4\/3!!
From 74e3b52516be9211fa6ea6a89853ac7a3a1fa478 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Sat, 4 Dec 2010 15:45:40 +0100
Subject: [PATCH] remove srst_pulls_trst from LPC2xxx target scripts
LPC2xxx do not require reset_config srst_pulls_trst. This can cause various
strange problems when flashing the chip, because reset halt actually allows
the chip to run for some short period of time and execute some code.
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
tcl/target/lpc2103.cfg |3 +--
tcl/target/lpc2124.cfg |3 +--
tcl/target/lpc2129.cfg |3 +--
tcl/target/lpc2294.cfg |3 +--
tcl/target/lpc2378.cfg |3 +--
tcl/target/lpc2478.cfg |3 +--
6 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/tcl/target/lpc2103.cfg b/tcl/target/lpc2103.cfg
index 714267f..7f14555 100644
--- a/tcl/target/lpc2103.cfg
+++ b/tcl/target/lpc2103.cfg
@@ -12,8 +12,7 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0x4f1f0f0f
}
-# LPC2000 - SRST causes TRST
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
# reset delays
adapter_nsrst_delay 100
diff --git a/tcl/target/lpc2124.cfg b/tcl/target/lpc2124.cfg
index c511589..df71bdd 100644
--- a/tcl/target/lpc2124.cfg
+++ b/tcl/target/lpc2124.cfg
@@ -12,8 +12,7 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0x4f1f0f0f
}
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
# reset delays
adapter_nsrst_delay 100
diff --git a/tcl/target/lpc2129.cfg b/tcl/target/lpc2129.cfg
index 103f18e..2587bf7 100644
--- a/tcl/target/lpc2129.cfg
+++ b/tcl/target/lpc2129.cfg
@@ -12,8 +12,7 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0xcf1f0f0f
}
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
# reset delays
adapter_nsrst_delay 100
diff --git a/tcl/target/lpc2294.cfg b/tcl/target/lpc2294.cfg
index 6f34171..ecf0599 100644
--- a/tcl/target/lpc2294.cfg
+++ b/tcl/target/lpc2294.cfg
@@ -14,8 +14,7 @@ if { [info exists CPUTAPID ] } {
adapter_nsrst_delay 200
jtag_ntrst_delay 200
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
#jtag scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
diff --git a/tcl/target/lpc2378.cfg b/tcl/target/lpc2378.cfg
index 65b554c..21fdd1b 100644
--- a/tcl/target/lpc2378.cfg
+++ b/tcl/target/lpc2378.cfg
@@ -16,8 +16,7 @@ if { [info exists CPUTAPID ] } {
adapter_nsrst_delay 200
jtag_ntrst_delay 200
-# LPC2000 - SRST causes TRST
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
diff --git a/tcl/target/lpc2478.cfg b/tcl/target/lpc2478.cfg
index df46c10..99c8ce9 100644
--- a/tcl/target/lpc2478.cfg
+++ b/tcl/target/lpc2478.cfg
@@ -16,8 +16,7 @@ if { [info exists CPUTAPID ] } {
adapter_nsrst_delay 100
jtag_ntrst_delay 100
-# LPC2000 - SRST causes TRST
-reset_config trst_and_srst srst_pulls_trst
+reset_config trst_and_srst
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
--
1.6.5.1.1367.gcd48
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
Here is my vision of this patch - with default value.
4\/3!!
From f573665d0ea4afbacff730c2591cf593374097b7 Mon Sep 17 00:00:00 2001
From: Rolf Meeser rolfm_...@yahoo.de
Date: Fri, 3 Dec 2010 14:10:40 +0100
Subject: [PATCH] lpc2478 target config: CCLK as (optional) parameter
Differences to original patch: CCLK is made optional, if not specified use 4MHz
default value.
Originally by: Rolf Meeser rolfm_...@yahoo.de
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
tcl/target/lpc2478.cfg |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/tcl/target/lpc2478.cfg b/tcl/target/lpc2478.cfg
index 99c8ce9..8cd65b2 100644
--- a/tcl/target/lpc2478.cfg
+++ b/tcl/target/lpc2478.cfg
@@ -12,6 +12,13 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0x4f1f0f0f
}
+if { [info exists CCLK ] } {
+ set _CCLK $CCLK
+} else {
+ set _CCLK 4000
+ echo Warning! You should specify the CCLK that will be used for flash
programming! Using default value of 4MHz.
+}
+
#delays on reset lines
adapter_nsrst_delay 100
jtag_ntrst_delay 100
@@ -37,7 +44,7 @@ $_TARGETNAME configure -event reset-init {
# After reset the chip uses its internal 4MHz RC oscillator.
# flash bank name lpc2000 base size 0 0 target# variant clock
[calc checksum]
set _FLASHNAME $_CHIPNAME.flash
-flash bank $_FLASHNAME lpc2000 0x0 0x7D000 0 0 $_TARGETNAME lpc2000_v2 4000
calc_checksum
+flash bank $_FLASHNAME lpc2000 0x0 0x7E000 0 0 $_TARGETNAME lpc2000_v2 $_CCLK
calc_checksum
# Try to use RCLK, if RCLK is not available use normal mode. 4MHz / 6 =
666kHz, so use 500.
jtag_rclk 500
--
1.6.5.1.1367.gcd48
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-03 14:31, Rolf Meeser wrote: This patch allows a board script to specify the CPU clock of the LPC2478 target. The clock frequency used to be fixed to 4 MHz. However, there is no default frequency for this CPU. You mustn't assume prior knowledge of the clock frequency, but rather demand that the user (board script) specifies it. This clock frequency is the CPU clock at the time of flash programming! Usually board scripts will enable the PLL to speed up debugging/programming. This MUST be the correct frequency, or flash programming will fail or produce unreliable results. This will break all LPC2478 board or user scripts. Users must add the intended operating clock frequency before they include the target script: set CCLK 72000 source [find target/lpc2478.cfg] Looks wrong to me. First of all, the chip frequency after reset actually is 4MHz due to internal RC oscillator, so this default frequency assumption seems pretty correct (actually it was probably me who added that script to OpenOCD). Debugging is negligibly faster when using high clock, flash programming duration gain is probably also negligible (what's the difference between waiting for 20 seconds to waiting for 10 seconds?). Anyway - I never enable PLL before flash programming, I bet that most regular users also don't. But most of all - this makes running OpenOCD with just command line arguments impossible (openocd -f interface/sth.cfg -f target/sth_else.cfg), as now you have to have your board config file. Please - don't go this way. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] add quot; cortex m3 reset config= = ...quot; to stm32.cfg
On 2010-12-03 12:49, Spencer Oliver wrote: On 02/12/2010 13:15, Spencer Oliver wrote: How about something like this: http://repo.or.cz/w/openocd/ntfreak.git/shortlog/refs/heads/stm32reset No objections to this then i will commit later today. If I understand your path correctly - it removes option srst and software reset options never override hardware resets if those are available? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-03 21:39, Rolf Meeser wrote: On 12/03/2010 08:09 PM, Freddie Chopin wrote: First of all, the chip frequency after reset actually is 4MHz due to internal RC oscillator, so this default frequency assumption seems pretty correct (actually it was probably me who added that script to OpenOCD). Incorrect. Yes, the chip starts from its 4 MHz oscillator, but what the clock frequency actually is by the time OpenOCD gets access is unpredictable. If for instance the flash is empty, the device will enter ISP mode automatically. It will activate the PLL, and from then on run with 14.748 MHz. When in this situation you program the flash with the clock parameter set to 4 MHz, the programming pulse will have a width of less than 30% of the required time. Might work, usually will, but is unreliable. The clock parameter is vital for correct and reliable flash programming. It must be possible for the user to select the frequency that he is using. I don't know how about you, but me (and 99% of normal users) reset halt the chip before programming - so it does run at 4MHz during programming. Debugging is negligibly faster when using high clock, flash programming duration gain is probably also negligible (what's the difference between waiting for 20 seconds to waiting for 10 seconds?). 10 seconds? 100% (as seen by the the lucky 10s user)? And by the way this is unrealistic. The penalty is much higher! At 72 MHz I can program the LPC2478 (504 KiB) in 14s with a simple JTAG interface. I feel no urge to wait longer than that. And how often do you flash full 504kB? 100kB will take ~4s, so whats a difference between ~4 and ~20 seconds? How about small program - 10kB? In a day your way will give me maybe 1 free minute more. For me that's not worth the trouble [; But that's not the main point... Anyway - I never enable PLL before flash programming, I bet that most regular users also don't. A classical chicken and egg case. We don't have good board scripts especially for the LPC devices. That's why people don't use it. And you won't have because world does not end on ready made boards. That's why people don't use them and that's why IMHO there is no point in creating them. What's the point for a board config file if most of the boards with small microcontrollers don't have any external ram, fancy reset circuitry and anything unusual - normal target file works just fine, and what's most important for me (and not only me!) is that it works standalone - without anything more. But most of all - this makes running OpenOCD with just command line arguments impossible (openocd -f interface/sth.cfg -f target/sth_else.cfg), as now you have to have your board config file. Please - don't go this way. Why would that be impossible? Who prevents you to use a script that sets *your* clock frequency and includes the target script? You don't get my point. To run OpenOCD my way I don't need ANY scripts beside standard target/interface files that come with OpenOCD. For this reply to be constrictive criticism, I suggest you leave 4MHz default value in case no clock is specified. I have a crazy idea - I think it is possible to measure frequency of the external crystal (and check for it's existence) with simple code using one timer. This way OpenOCD would work without specifying this frequency. It could then - before programming - measure it (backup-ing all settings of timer), switch PLL to max value (using external crystal or internal resonator, also backup-ing all settings of clock and PLL), flash, revert all changes made to clock, PLL and timer and voila [; Problem gone 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-03 21:39, Rolf Meeser wrote: If for instance the flash is empty, the device will enter ISP mode automatically. It will activate the PLL, and from then on run with 14.748 MHz. When in this situation you program the flash with the clock parameter set to 4 MHz, the programming pulse will have a width of less than 30% of the required time. Might work, usually will, but is unreliable. Crazy idea nr 2 - why not set max frequency - this way this pulse will always be long enough (I don't see any reason for problems with longer pulse) - maybe this way this parameter would not be required too? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] (patch) Change target script for LPC2478
On 2010-12-03 22:42, Michael Schwingen wrote: On 12/03/2010 10:06 PM, Freddie Chopin wrote: On 2010-12-03 21:39, Rolf Meeser wrote: The clock parameter is vital for correct and reliable flash programming. It must be possible for the user to select the frequency that he is using. I don't know how about you, but me (and 99% of normal users) reset halt the chip before programming - so it does run at 4MHz during programming. And everyone else can live with unreliable results? I don't like this approach. Correct operation should be the highest priority. How can this be unreliable? LPC23xx/LPC24xx after reset use 4MHz internal clock. Doing reset halt sets that clock and prevents any code from changing that (let's not talk about broken cases, because a broken case can be found everywhere), so what's wrong with this approach? Debugging is negligibly faster when using high clock, flash programming duration gain is probably also negligible (what's the difference between waiting for 20 seconds to waiting for 10 seconds?). 10 seconds? 100% (as seen by the the lucky 10s user)? And by the way this is unrealistic. The penalty is much higher! At 72 MHz I can program the LPC2478 (504 KiB) in 14s with a simple JTAG interface. I feel no urge to wait longer than that. And how often do you flash full 504kB? 100kB will take ~4s, so whats a difference between ~4 and ~20 seconds? How about small program - 10kB? In a day your way will give me maybe 1 free minute more. For me that's not worth the trouble [; But that's not the main point... What's the purpose of using a 512KiB flash micro if you only need 50K? Lots of applications *will* use big parts of the flash, and yes, programming times *do* matter in my development cycle, especially if we are talking 10s vs. 20s (and for no good reason!). Why use big chip? LPC2478 has an LCD driver, and there is no chip with LCD driver that has less flash. Because for developement of the project you take big chip just-in-case, and choose right one (regarding flash size) for production when the code is ready. Anyway - we should be talking about the average size of the upload, and that's never 512kB - the code has to grow from 0 to this size during developement. BTW - you use libusb of ftd2xx (if you use Windows and FT2232 based JTAG)? I'm asking because if waiting 10s is worth breaking configurations of OpenOCD's regular users, then I hope you use the fastest library for the process. C'mon! 10s?! Don't read mailing lists and that will save you much more time (; And you won't have because world does not end on ready made boards. That's why people don't use them and that's why IMHO there is no point in creating them. What's the point for a board config file if most of the boards with small microcontrollers don't have any external ram, fancy reset circuitry and anything unusual - normal target file works just fine, and what's most important for me (and not only me!) is that it works standalone - without anything more. Then let's provide a board config file that works fine on those barebone applications where OpenOCD does not need to know anything beyond the CPU. But there's no point in having a board file that in reality is not for board but for target, that will do nothing more than include target file... What for? What does that make easier? If one has it's own board with some chip I don't think one would look for config scripts in board directory... I wouldn't. Please - try to make OpenOCD more user-friendly, not user-hostile! But most of all - this makes running OpenOCD with just command line arguments impossible (openocd -f interface/sth.cfg -f target/sth_else.cfg), as now you have to have your board config file. Please - don't go this way. Why would that be impossible? Who prevents you to use a script that sets *your* clock frequency and includes the target script? You don't get my point. To run OpenOCD my way I don't need ANY scripts beside standard target/interface files that come with OpenOCD. So what is the problem? Right now, you are using the LPC2478 target config file. You could use some kind of lpc2478_std config file instead - same amount of typing, same user experience, but those people working with more complex boards will have the benefit of running at the right clock speed. The problem is that right now OpenOCD provides all I need, because there is no lpc2478_std config file, lpc2478.cfg works just fine - I (and anyone willing to use OpenOCD with that chip) would have to create it first. Same amount of typing and user experience? I doubt it - right now I don't need to know ANYTHING about tcl, OpenOCD's config files etc. They work out-of-the-box. People working with more complex boards are not forbidden to set right clock speed now. Actually I think they managed, because I've not seen any complaints... For this reply to be constrictive criticism, I suggest you leave 4MHz default value in case no clock is specified
Re: [Openocd-development] [PATCH 1/2] add quot; cortex m3 reset config= = ...quot; to stm32.cfg
On 2010-12-03 23:29, Spencer Oliver wrote: On 03/12/2010 19:13, Freddie Chopin wrote: On 2010-12-03 12:49, Spencer Oliver wrote: On 02/12/2010 13:15, Spencer Oliver wrote: How about something like this: http://repo.or.cz/w/openocd/ntfreak.git/shortlog/refs/heads/stm32reset No objections to this then i will commit later today. If I understand your path correctly - it removes option srst and software reset options never override hardware resets if those are available? Correct. Then the idea is pretty fine (; I believe that you've coded that right ; Seems OK for me. My oroginal patch (adding soft reset configuration for stm32.cfg) or the version from your repository will still be useful and I hope that you'll commit that too. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] rename some target scripts to be consistent with the rest
On 2010-12-02 00:37, Antonio Borneo wrote: the patch involves file renaming. Please add the flags -M -C to git-format-patch With these flags the patch would be smaller, and would be easier to follow the renaming. Sorry, can't do that... The patch you see was created in Windows with TortoiseGIT, and there you cannot change method of patch creation. In Linux using git from command line makes me crazy in less then 5 minutes... I really can't do anything with it, SVN is like 10^10 times simpler to use, and the names of commands do mean something, while in git they are very amusing and completely meaningless for me... Believe me - I've tried. I've read a dozen of git guides lately and while I'd like to do something as simple as rename 3 files and commit it, I just can't. First I've fought for a while to reset my repository to a clean state (it's easier to just delete it and download again...), then I've tried renaming those files, but no luck there - git wants to commit a new directory jimtcl and there is no way to change its mind, and files with new names just cannot be commited... Sorry, maybe someone else can try to do this right. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Remote 'g' packet reply is too long
Update Eclipse to the most recent version (Helios SR1) and use the most recent GDB Hardware Debugging plugin. Take a look at similar thread on arm-gnu list (CodeSourcery's mailing list for Lite version). 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Lost patches
On 2010-11-30 08:20, Øyvind Harboe wrote: Are there any patches out there that should have been applied but haven't? Are you planning a release? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current stable release is very very stale
On 2010-11-30 06:38, Tomek CEDRO wrote: The SWJ cable that I have use tdi and tdo pins anyway but the buffers are more complex, maybe there is a simple way to make jtag only cable swd aware, i have some other cables so after the base is working we can give a try on that :-) This is also an important issue (; Rowley has done a converter for Amontec JTAGkey, but so far I haven't found much detail about it. It would be very very cool to be able to use old JTAGs with OpenOCD and SWD - with some kind of detachable simple converter. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] SWD progress
On 2010-11-30 17:46, Tomek CEDRO wrote: Freddie, this is free and open source project, so no way to enforce rush from anyone on anyone, the work is in progress. I have managed to include this project somehow with my current tasks so I can put some more time into it, but I had to reschedule it from march too and it collides with some others tasks as well... The delays are unavoidable in a real world, and each second costs money - this is why I try to document it as well I can to spare this time for further implementation in openocd, so you wont have to reseach again :-) Nobody's forcing anything on anyone - I'm merely stating facts. OpenOCD is not normal open-source project, as most users have small knowledge about PC programming (e.g. me), that's why most of us OpenOCD-users can do nothing more than simple requests and bug reports... The fact that I can build OpenOCD myself is a huge success for me ; I'd really like to help with OpenOCD, but someone would need to tell me what to do (; In details like where, what mechanism / algorithm, what it should do. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/2] add cortex_m3 reset_config ... to stm32.cfg
From 852e118ef27fd3fb0b7d32f9524c89f58d171152 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Wed, 1 Dec 2010 22:49:48 +0100
Subject: [PATCH 1/2] add cortex_m3 reset_config ... to stm32.cfg
STM32 fully support NVIC's sysresetreq (which also resets peripherals and
generates SRST pulse), so use it in place of default vectreset (which does
not reset peripherals and does not generate SRST pulse).
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
tcl/target/stm32.cfg |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/tcl/target/stm32.cfg b/tcl/target/stm32.cfg
index fa59e35..ad5b50c 100644
--- a/tcl/target/stm32.cfg
+++ b/tcl/target/stm32.cfg
@@ -26,6 +26,9 @@ adapter_khz 1000
adapter_nsrst_delay 100
jtag_ntrst_delay 100
+# STM32 fully support NVIC's sysresetreq (which also resets peripherals and
generates SRST pulse)
+cortex_m3 reset_config sysresetreq
+
#jtag scan chain
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
--
1.6.5.1.1367.gcd48
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/2] rename some target scripts to be consistent with the rest
___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/2] rename some target scripts to be consistent with the rest
From 995335b80223931c2c4b3686c4db563b9119cce1 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Wed, 1 Dec 2010 22:55:56 +0100
Subject: [PATCH 2/2] rename some target scripts to be consistent with the rest
Rename Atmel target scripts which had wrong name (at91 missing for ARM7
AT91SAM7..., at missing for AVR ATmega...)
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
tcl/target/at91sam7se512.cfg | 40 +
tcl/target/at91sam7x256.cfg | 50 ++
tcl/target/atmega128.cfg | 40 +
tcl/target/mega128.cfg | 40 -
tcl/target/sam7se512.cfg | 40 -
tcl/target/sam7x256.cfg | 50 --
6 files changed, 130 insertions(+), 130 deletions(-)
create mode 100644 tcl/target/at91sam7se512.cfg
create mode 100644 tcl/target/at91sam7x256.cfg
create mode 100644 tcl/target/atmega128.cfg
delete mode 100644 tcl/target/mega128.cfg
delete mode 100644 tcl/target/sam7se512.cfg
delete mode 100644 tcl/target/sam7x256.cfg
diff --git a/tcl/target/at91sam7se512.cfg b/tcl/target/at91sam7se512.cfg
new file mode 100644
index 000..c48afef
--- /dev/null
+++ b/tcl/target/at91sam7se512.cfg
@@ -0,0 +1,40 @@
+
+# ATMEL sam7se512
+# Example: the Elektor Internet Radio - EIR
+# http://www.ethernut.de/en/hardware/eir/index.html
+
+if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
+ set _CHIPNAME sam7se512
+}
+
+if { [info exists ENDIAN] } {
+ set _ENDIAN $ENDIAN
+} else {
+ set _ENDIAN little
+}
+
+if { [info exists CPUTAPID ] } {
+ set _CPUTAPID $CPUTAPID
+} else {
+ # force an error till we get a good number
+ set _CPUTAPID 0x
+}
+
+#use combined on interfaces or targets that can't set TRST/SRST separately
+reset_config srst_only srst_pulls_trst
+
+#jtag scan chain
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
+
+# The target
+set _TARGETNAME $_CHIPNAME.cpu
+target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm7tdmi
+
+$_TARGETNAME configure -work-area-phys 0x0020 -work-area-size 0x4000
-work-area-backup 0
+
+#flash bank driver base_addr size chip_width bus_width
target_number [target_name banks sectors_per_bank pages_per_sector
page_size num_nvmbits ext_freq_khz]
+set _FLASHNAME $_CHIPNAME.flash
+flash bank $_FLASHNAME at91sam7 0 0 0 0 $_TARGETNAME 0 0 0 0 0 0 0 18432
+
diff --git a/tcl/target/at91sam7x256.cfg b/tcl/target/at91sam7x256.cfg
new file mode 100644
index 000..dd36458
--- /dev/null
+++ b/tcl/target/at91sam7x256.cfg
@@ -0,0 +1,50 @@
+#use combined on interfaces or targets that can't set TRST/SRST separately
+reset_config srst_only srst_pulls_trst
+
+if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
+ set _CHIPNAME sam7x256
+}
+
+if { [info exists ENDIAN] } {
+ set _ENDIAN $ENDIAN
+} else {
+ set _ENDIAN little
+}
+
+if { [info exists CPUTAPID ] } {
+ set _CPUTAPID $CPUTAPID
+} else {
+ set _CPUTAPID 0x3f0f0f0f
+}
+
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
+
+set _TARGETNAME $_CHIPNAME.cpu
+target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm7tdmi
+
+$_TARGETNAME configure -event reset-init {
+ # disable watchdog
+ mww 0xfd44 0x8000
+ # enable user reset
+ mww 0xfd08 0xa501
+ # CKGR_MOR : enable the main oscillator
+ mww 0xfc20 0x0601
+ sleep 10
+ # CKGR_PLLR: 96.1097 MHz
+ mww 0xfc2c 0x00481c0e
+ sleep 10
+ # PMC_MCKR : MCK = PLL / 2 ~= 48 MHz
+ mww 0xfc30 0x0007
+ sleep 10
+ # MC_FMR: flash mode (FWS=1,FMCN=60)
+ mww 0xff60 0x003c0100
+ sleep 100
+}
+
+$_TARGETNAME configure -work-area-phys 0x0020 -work-area-size 0x4000
-work-area-backup 0
+
+#flash bank driver base_addr size chip_width bus_width
target_number [target_name banks sectors_per_bank pages_per_sector
page_size num_nvmbits ext_freq_khz]
+set _FLASHNAME $_CHIPNAME.flash
+flash bank $_FLASHNAME at91sam7 0 0 0 0 $_TARGETNAME 0 0 0 0 0 0 0 18432
diff --git a/tcl/target/atmega128.cfg b/tcl/target/atmega128.cfg
new file mode 100644
index 000..212a267
--- /dev/null
+++ b/tcl/target/atmega128.cfg
@@ -0,0 +1,40 @@
+# for avr
+
+ set _CHIPNAME avr
+ set _ENDIAN little
+
+# jtag speed
+adapter_khz 4500
+
+reset_config srst_only
+adapter_nsrst_delay 100
+
+#jtag scan chain
+if { [info exists CPUTAPID ] } {
+ set _CPUTAPID $CPUTAPID
+} else {
+ set _CPUTAPID 0x8970203F
+}
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
+
+set _TARGETNAME $_CHIPNAME.cpu
+target create $_TARGETNAME avr -endian $_ENDIAN -chain-position $_TARGETNAME
+
+#$_TARGETNAME configure -work
Re: [Openocd-development] Current stable release is very very stale
On 2010-11-29 14:44, Tomek CEDRO wrote:
The SWD API is almost done, for few days already im trying to integrate
it into UrJTAG as this is simpler software than OpenOCD from complexity
point of view. When transport is verifed (~week 49/50) im moving to
OpenOCD and debugging. The hardware I am working on in stm32primer{1,2}
and KT-LINK SWJ cable based on FT2232H. I want it all to work by end of
year :-)
This would be great!
Do you have some idea how can SWD be used with typical FT2232 based
JTAGs - these which don't have direction control for SWDIO (like Amontec
JTAGkey, Turtelizer, etc.)?
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current stable release is very very stale
On 2010-11-29 07:40, Eric Parsonage wrote: I want a release version of openocd that supports Lisa-l. Lisa-l support has been in the code for several months now but there is no sight of any release. BTW if you use Windows, you can download development versions of OpenOCD from my webpage - usually updated every 2 months (however if you need some specific version you can always ask). http://www.freddiechopin.info/index.php/en/download/category/10-openocd-dev 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Config file format/line endings
On 2010-11-16 00:27, Andrew Leech wrote: I personally don't have an issue with requiring unix line endings Most likely all Windows users won't mind that... World does not end on *nix systems... However the list of popular OSes probably does, so actually that should be the other way around regarding line ending style. Just my small input in this matter. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Add comments and tiny improvements to STM32 flash loader algorithm
On 2010-11-14 16:13, Øyvind Harboe wrote: But you did add another error check? + tst r3, #0x14 /* PGERR (bit2) == 1 or WRPRTERR (bit4) == 1 = error */ + bne exit /* fail... */ Perhaps sharper error messages? It was in the previous code: - tst r3, #0x14 - bne exit 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Disable stm32x block write by default?
On 2010-11-09 10:16, Øyvind Harboe wrote:
Error: 793 186992 stm32x.c:582 stm32x_write_block(): error executing
stm32x flash write algorithm
Error: 794 186993 core.c:98 flash_driver_write(): error writing to
flash at address 0x0800 at offset 0x (-302)
On 2010-11-14 16:13, Øyvind Harboe wrote:
Perhaps sharper error messages?
I've checked the code in stm32x.c, and there are error messages for both
cases that are possible with this code:
if (buf_get_u32(reg_params[3].value, 0, 32) FLASH_PGERR)
{
LOG_ERROR(flash memory not erased before writing);
/* Clear but report errors */
target_write_u32(target, STM32_FLASH_SR, FLASH_PGERR);
retval = ERROR_FAIL;
break;
}
if (buf_get_u32(reg_params[3].value, 0, 32) FLASH_WRPRTERR)
{
LOG_ERROR(flash memory write protected);
/* Clear but report errors */
target_write_u32(target, STM32_FLASH_SR,
FLASH_WRPRTERR);
retval = ERROR_FAIL;
break;
}
Your code (I'm judging by the error message) failed somewhere in here:
if ((retval = target_run_algorithm(target, 0, NULL, 4,
reg_params,
stm32x_info-write_algorithm-address,
0,
1, armv7m_info)) != ERROR_OK)
{
LOG_ERROR(error executing stm32x flash write
algorithm);
break;
}
So I'd suspect target_run_algorithm() internals - in this case that would be
/** Runs a Thumb algorithm in the target. */
int armv7m_run_algorithm(struct target *target,
int num_mem_params, struct mem_param *mem_params,
int num_reg_params, struct reg_param *reg_params,
uint32_t entry_point, uint32_t exit_point,
int timeout_ms, void *arch_info)
Judging by error number (-302) we need to go deeper, as run_algorithm()
does not produce this one directly
#define ERROR_TARGET_TIMEOUT(-302)
Such error can be produced by
/* run to exit point. return error if exit point was not reached. */
static int armv7m_run_and_wait(struct target *target, uint32_t entry_point, int
timeout_ms, uint32_t exit_point, struct armv7m_common *armv7m)
And I suspect here:
retval = target_wait_state(target, TARGET_HALTED, timeout_ms);
/* If the target fails to halt due to the breakpoint, force a halt */
if (retval != ERROR_OK || target-state != TARGET_HALTED)
{
if ((retval = target_halt(target)) != ERROR_OK)
return retval;
if ((retval = target_wait_state(target, TARGET_HALTED, 500)) !=
ERROR_OK)
{
return retval;
}
return ERROR_TARGET_TIMEOUT;
}
As I cannot reproduce, if this one is repeating at your side, maybe try
injecting some messages around there to see whether that's the exact
point of problems?
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Disable stm32x block write by default?
On 2010-11-14 18:49, Øyvind Harboe wrote: The problem is that the target is crashing while executing the programming algorithm, so it never completes. You mean crashing like having Hard Fault exception or sth like this? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Add cortex_m3 capabilities soft_reset command
This is work-in-progress, but before continuing I'd like to hear your
comments - I can stop now if you don't like that idea.
User can execute command cortex_m3 capabilities soft_reset + all
supported soft-reset methods, can be selected from two: sysresetreq
and/or vectreset (or none).
This can be used in cortex_m3_assert_reset() to select best reset method.
BTW - I'm not sure whether I've added the commands right (especially
capabilities chain), but that code works fine (but currently does
nothing more than set target variables) - I've tested it.
I hope you like it...
4\/3!!
From bbd6137fdade1b2760ade58cc23d6f9fc9b52cc2 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Sat, 13 Nov 2010 13:07:08 +0100
Subject: [PATCH] Add cortex_m3 capabilities soft_reset command
Add cortex_m3 capabilities command group. Add cortex_m3 capabilities
soft_reset command that allows user to specify all soft-reset methods
supported by the target (sysresetreq, vectreset).
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
src/target/cortex_m3.c | 55
src/target/cortex_m3.h |8 +++
2 files changed, 63 insertions(+), 0 deletions(-)
mode change 100644 = 100755 src/target/cortex_m3.c
mode change 100644 = 100755 src/target/cortex_m3.h
diff --git a/src/target/cortex_m3.c b/src/target/cortex_m3.c
old mode 100644
new mode 100755
index f2947ad..42ed45d
--- a/src/target/cortex_m3.c
+++ b/src/target/cortex_m3.c
@@ -2166,6 +2166,54 @@ COMMAND_HANDLER(handle_cortex_m3_reset_config_command)
return ERROR_OK;
}
+COMMAND_HANDLER(handle_cortex_m3_capabilities_soft_reset_command)
+{
+ struct target *target = get_current_target(CMD_CTX);
+ struct cortex_m3_common *cortex_m3 = target_to_cm3(target);
+ int retval;
+ char *soft_reset_sysresetreq = , *soft_reset_vectreset = ;
+
+ retval = cortex_m3_verify_pointer(CMD_CTX, cortex_m3);
+ if (retval != ERROR_OK)
+ return retval;
+
+ cortex_m3-capabilities_soft_reset.sysresetreq = false;
+ cortex_m3-capabilities_soft_reset.vectreset = false;
+
+ for (; CMD_ARGC; CMD_ARGC--, CMD_ARGV++)
+ {
+ if (strcmp(*CMD_ARGV, sysresetreq) == 0)
+ cortex_m3-capabilities_soft_reset.sysresetreq = true;
+ else if (strcmp(*CMD_ARGV, vectreset) == 0)
+ cortex_m3-capabilities_soft_reset.vectreset = true;
+ else
+ LOG_WARNING(unknown Cortex-M3 soft-reset method
ignored: %s, *CMD_ARGV);
+ }
+
+ if (cortex_m3-capabilities_soft_reset.sysresetreq == true)
+ soft_reset_sysresetreq = sysresetreq;
+ if (cortex_m3-capabilities_soft_reset.vectreset == true)
+ soft_reset_vectreset = vectreset;
+
+ command_print(CMD_CTX, cortex_m3 capabilities soft_reset%s%s,
+ soft_reset_sysresetreq,
+ soft_reset_vectreset
+ );
+
+ return ERROR_OK;
+}
+
+static const struct command_registration
cortex_m3_capabilities_command_handlers[] = {
+ {
+ .name = soft_reset,
+ .handler = handle_cortex_m3_capabilities_soft_reset_command,
+ .mode = COMMAND_ANY,
+ .help = Specify all soft-reset methods supported by Cortex-M3
target,
+ .usage = ['sysresetreq'] ['vectreset'],
+ },
+ COMMAND_REGISTRATION_DONE
+};
+
static const struct command_registration cortex_m3_exec_command_handlers[] = {
{
.name = maskisr,
@@ -2188,8 +2236,15 @@ static const struct command_registration
cortex_m3_exec_command_handlers[] = {
.help = configure software reset handling,
.usage = ['srst'|'sysresetreq'|'vectreset'],
},
+ {
+ .name = capabilities,
+ .mode = COMMAND_ANY,
+ .help = Cortex-M3 capabilities command group,
+ .chain = cortex_m3_capabilities_command_handlers,
+ },
COMMAND_REGISTRATION_DONE
};
+
static const struct command_registration cortex_m3_command_handlers[] = {
{
.chain = armv7m_command_handlers,
diff --git a/src/target/cortex_m3.h b/src/target/cortex_m3.h
old mode 100644
new mode 100755
index db80711..6293790
--- a/src/target/cortex_m3.h
+++ b/src/target/cortex_m3.h
@@ -141,6 +141,12 @@ enum cortex_m3_soft_reset_config
CORTEX_M3_RESET_VECTRESET,
};
+struct cortex_m3_capabilities_soft_reset
+{
+ bool sysresetreq;
+ bool vectreset;
+};
+
struct cortex_m3_common
{
int common_magic;
@@ -167,6 +173,8 @@ struct cortex_m3_common
enum cortex_m3_soft_reset_config soft_reset_config;
+ struct cortex_m3_capabilities_soft_reset capabilities_soft_reset;
+
struct armv7m_common armv7m;
};
--
1.6.4.2
___
Openocd-development
Re: [Openocd-development] Peripheral register view in Eclipse
On 2010-11-13 12:48, Øyvind Harboe wrote: I was wondering if the target database of peripheral registers could somehow be leveraged in OpenOCD. Recall all those pesky target combinations? I'm not sure what do you mean ); Isn't there information in this peripheral register view plugin that OpenOCD could use? As Peter said, using names for mww, mdw etc. would be great (; FAE's from silicon vendors would probably spend time assuring that such databases are up to date. They do for Keil, IAR and their ilk. I think that they already do - releasing new versions of header files... I think that the best method is to find a way to parse such headers and create other formats with that info. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Add comments and tiny improvements to STM32 flash loader algorithm
Hi all!
Very small improvement. Tested on STM32, worst-case speed improvement is
~1.5%, best-case - ~3%.
Old one:
stm32x mass_erase 0
stm32x mass erase complete
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.390625s (12.152 KiB/s)
stm32x mass_erase 0
stm32x mass erase complete
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.390625s (12.152 KiB/s)
stm32x mass_erase 0
stm32x mass erase complete
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.390625s (12.152 KiB/s)
New one:
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.109375s (12.490 KiB/s)
stm32x mass_erase 0
stm32x mass erase complete
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.187500s (12.394 KiB/s)
stm32x mass_erase 0
stm32x mass erase complete
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.25s (12.319 KiB/s)
stm32x mass_erase 0
stm32x mass erase complete
flash write_image c:\\stm32.hex
wrote 129296 bytes from file c:\stm32.hex in 10.156250s (12.432 KiB/s)
Image can be verified and it's fine.
4\/3!!
From a8d788763856fdf4dfeecad7827bb0e51e774c13 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Sat, 13 Nov 2010 15:42:00 +0100
Subject: [PATCH] Add comments and tiny improvements to STM32 flash loader
algorithm
Add comments to assembly flash loader for STM32. Add tiny improvement in
size of the algorithm (40 vs 48 bytes) and tiny speed improvement (~1.5%,
as time is wasted on waiting for end of operation anyway).
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
contrib/loaders/flash/stm32x.s | 40 ++--
src/flash/nor/stm32x.c | 33 +
2 files changed, 39 insertions(+), 34 deletions(-)
diff --git a/contrib/loaders/flash/stm32x.s b/contrib/loaders/flash/stm32x.s
index dcf2b83..6cf9f57 100644
--- a/contrib/loaders/flash/stm32x.s
+++ b/contrib/loaders/flash/stm32x.s
@@ -19,7 +19,10 @@
***/
.text
- .arm
+ .syntax unified
+ .thumb
+ .thumb_func
+ .global write
/*
r0 - source address
@@ -27,26 +30,27 @@
r2 - count (halfword-16bit)
r3 - result
r4 - temp
- r5 - temp
*/
+#define STM32_FLASH_CR_OFFSET 0x10/* offset of CR
register in FLASH struct */
+#define STM32_FLASH_SR_OFFSET 0x0c/* offset of CR
register in FLASH struct */
+
write:
- ldr r4, STM32_FLASH_CR
- ldr r5, STM32_FLASH_SR
- mov r3, #1
- str r3, [r4, #0]
- ldrhr3, [r0], #2
- strhr3, [r1], #2
+ ldr r4, STM32_FLASH_BASE
+write_half_word:
+ movsr3, #0x01
+ str r3, [r4, #STM32_FLASH_CR_OFFSET]/* PG (bit0) ==
1 = flash programming enabled */
+ ldrhr3, [r0], #0x02 /* read
one half-word from src, increment ptr */
+ strhr3, [r1], #0x02 /*
write one half-word from src, increment ptr */
busy:
- ldr r3, [r5, #0]
- tst r3, #0x01
- beq busy
- tst r3, #0x14
- bne exit
- subsr2, r2, #1
- bne write
+ ldr r3, [r4, #STM32_FLASH_SR_OFFSET]
+ tst r3, #0x01
/* BSY (bit0) == 1 = operation in progress */
+ beq busy
/* wait more... */
+ tst r3, #0x14
/* PGERR (bit2) == 1 or WRPRTERR (bit4) == 1 = error */
+ bne exit
/* fail... */
+ subsr2, r2, #0x01 /*
decrement counter */
+ bne write_half_word
/* write next half-word if anything left */
exit:
- bkpt#0
+ bkpt#0x00
-STM32_FLASH_CR: .word 0x40022010
-STM32_FLASH_SR:.word 0x4002200C
+STM32_FLASH_BASE: .word 0x40022000 /* base address
of FLASH struct */
diff --git a/src/flash/nor/stm32x.c b/src/flash/nor/stm32x.c
index 6b46afc..7779ea3 100644
--- a/src/flash/nor/stm32x.c
+++ b/src/flash/nor/stm32x.c
@@ -503,25 +503,26 @@ static int stm32x_write_block(struct flash_bank *bank,
uint8_t *buffer,
/* see contib/loaders/flash/stm32x.s for src */
static const uint8_t stm32x_flash_write_code[] = {
+ /*
#define STM32_FLASH_CR_OFFSET0x10
Re: [Openocd-development] [PATCH] Add comments and tiny improvements to STM32 flash loader algorithm
On 2010-11-13 16:47, Øyvind Harboe wrote: Is it conceivable that this would address the block flash programming problems I saw the other day and you were not able to reproduce? Rather not... The mechanics of this algorithm are exactly the same - I've just shortened the inner write loop (no need to load addresses of registers again), and used offset ldr to use only one literal address (FLASH struct) instead of two (CR and SR). 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Add cortex_m3 capabilities soft_reset command
On 2010-11-13 21:40, Spencer Oliver wrote:
May be better calling it config_soft_reset or similar.
I've tried to keep that short (; The longest one to type is
capabilities anyway, but I couldn't find a better word [;
Another point is that some targets (luminary) do not correctly support
srst so it may be worth turning this into a config_reset cmd instead.
To make it more universal, I think that a general target capabilities
reset command should be used, that command can select srst, soft_reset
(or both [or none, but that wouldn't make much sense]), then target
specific soft-reset methods could be added.
BTW - is there some problem with dash ('-') in command names? Today I've
been searching for problems within the code, because I've typed
cortex-m3 ..., while it's cortex_m3 ..., which is quite unnatural
IMO... Maybe that could be changed?
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
