Re: [Openocd-development] Modify a git commit ?
Hi spen, I'm pretty sure I have something wrong. I would like to only push the commit 7cc475d31a8289c35d41a377ddc54c55b352be80. I want to reedit it to add the signed off. Is it possible ? $ git log commit a8558a1a9bf558fea7dec027c424f010b2e97982 Merge: 7cc475d 9780683 Author: Jonathan Dumaresq Date: Fri Oct 28 10:05:30 2011 -0400 Merge branch 'master' of git://openocd.git.sourceforge.net/gitroot/openocd/o Change-Id: Ib5ae7f423c165add1190435cd874fcc80cd845d4 Signed-off-by: Jonathan Dumaresq modified: src/flash/nor/stm32f1x.c commit 97806831e25e8b75c02d61a30a98b18e090619f2 Author: Øyvind Harboe Date: Thu Oct 27 23:51:50 2011 +0200 bugfixes: numerous bugs in error propagation found by clang Change-Id: I784068325b422d1918e28c08544bc5a1332d712f Signed-off-by: Øyvind Harboe Reviewed-on: http://openocd.zylin.com/130 Tested-by: jenkins Reviewed-by: Øyvind Harboe commit 7cc475d31a8289c35d41a377ddc54c55b352be80 Author: Jonathan Dumaresq Date: Thu Oct 27 14:50:36 2011 -0400 Correct a typo for page size Regards Jonathan Spencer Oliver wrote: > On 28 October 2011 15:21, Jonathan Dumaresq > wrote: >> HI, >> >> I have create a change in one of my patch that i have already sent. I >> commited it, but I forget to add the signed-off by... Is it possible >> to edit a commit message ? >> >> Jonathan >> > > git commit -s --amend > > Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Modify a git commit ?
HI, I have create a change in one of my patch that i have already sent. I commited it, but I forget to add the signed-off by... Is it possible to edit a commit message ? Jonathan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Info about RTOS support
Hi Evan, openocd-development-boun...@lists.berlios.de wrote: > Hi Jonathan, > > You should be able to simply add something like the following to your > config file: > > $_TARGETNAME configure -rtos auto Thanx for your help ! > > > It should automatically detect the FreeRTOS instance. It's work. > > Additional notes: > * You will probably need to rebuild GDB with this bug fixed: > http://sourceware.org/bugzilla/show_bug.cgi?id=12648 It's seem to have a strange thing that happen when I put breakpoint. The Gdb stop, but I cannot see where the PC are. All thread are stopped, but the "focus" are not on the breakpoint. Is it a normal thing ? As for the gdb bug, I have not compiled a new one. I only use the one that came with the toolchain. I use the codesourcery one. Do you have this application builded somewhere that I can doownload it ? I'm on windows. > * You may need to use Eclipse Helios rather than Indigo, since Indigo > seems to not display thread names I already use Helios. I have not upgraded my eclipse to Indigo. > * Your OpenOCD startup script should clear memory to avoid confusion > due to old data persisting in RAM after reset: > > # clear RAM so that the rtos awareness does not detect threads > left in memory from previous run mww 0x2000 0x 0x4000 I will put his in my reset init call back ? > > > Regards, > > Evan Hunter Regards Jonathan Dumaresq ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Info about RTOS support
Hi, Øyvind Harboe wrote: > There is some in the OpenOCD manual, but we would very much welcome > patches for more! > > Did you check out the documentation you could find in the OpenOCD > manual? I checked on the http://openocd.sourceforge.net/doc//pdf/openocd.pdf. I did a find on rtos keyword, and find nothing about this. Regards Jonathan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Info about RTOS support
Hi, I have seem on the ml that FreeRTOS is now supported in openocd. I wonder if there is some documentation about this ? I use eclipse to code and debug. I would like to use this feature. I'm using an STM32 part. From what I see, it is supported. Regards Jonathan Dumaresq ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Add STM32 value line MD and HD support
Hi Tormod, Tormod Volden wrote: > Hi Jonathan, > > In the patch you wrote, 1k pages versus page_size = 2048 seems > contradictory, I guess the comment is wrong: Yes I will check that. > > + /* value line density - we have 1k pages > + * 4 pages for a protection area */ > + page_size = 2048; > > Maybe you want to fix it up in a follow-up patch. The problem is that i have some trouble to fix the sendmail under cygwin. I have to copy the pacth and attached it. I'll try to fix that too. Regards Jonathan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Add STM32 value line MD and HD support
Hi, I have added the Value line HD support. Thsi have been tested in a real HD chip. STM32T100VE Jonathan Dumaresq 0002-Add-Valuline-HD-to-config-file.patch Description: Binary data 0001-This-will-add-the-Value-Line-HD-of-stm32-devices.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cortex-M0 support ?
Hi, -Message d'origine- De : openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] De la part de Tomek CEDRO Envoyé : 6 juin 2011 16:16 À : Freddie Chopin Cc : openocd-development@lists.berlios.de Objet : Re: [Openocd-development] Cortex-M0 support ? On Mon, Jun 6, 2011 at 3:39 PM, Freddie Chopin wrote: > 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. Work in progress, almost ready, still fixing stuff, should send patches soon :-) Cool !! Jonathan -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Cortex-M0 support ?
Hi all, 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. Regards Jonathan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] making contributing easier
Hi, -Message d'origine- De : openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] De la part de Tormod Volden Envoyé : 29 mars 2011 16:59 À : openocd-development@lists.berlios.de Objet : Re: [Openocd-development] making contributing easier On Tue, Mar 29, 2011 at 10:35 PM, Øyvind Harboe wrote: > How about adding a "contribute" script which did the following: > > - fetch from origin > - commit changes from user, bringing up a text editor with > a template commit message. > - rebase origin to the master branch, abort if there are conflicts > - create patches and git send-email them to the list Hi, I would suggest shipping a HACKING or README.patches file that shows the "real" commands to do the above steps. Teach a man to fish... Otherwise I think your "contribute" script will be yet another Easy Git[1]. And if every little project makes their own "contribute" implementation, it will just be more confusion for everyone. A small web page on the openocd that explain it should help! Just something that we can refer befor starting hacking the code My 0.02$ cent Jonathan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] info on cpu speed
Hi all, I work on stm32 devices and I would like to kow if ther exist a openocd command to retreived the cpu speed ? I would like to know if my pll setup are OK. I remember whan I have worked on ARM7 target that with flash info 0 the mcu speed was approximed. But could not find this with STM32 Regards Jonathan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New patch series for the handling of CFI with stm32
>From a newbie like me that have no idea of how openocd backend works... This was the only solution that i found. Anyways, the cfi driver should be target independent... Jonathan openocd-development-boun...@lists.berlios.de wrote: > Am 01/05/2011 06:04 PM, schrieb Jonathan dumaresq: >> Hi, >> >> Here my new series of patches. > Looks good after a cursory inspection. > > The strcmp for "cortex_m3" looks a bit dodgy - I guess the target > should be reworked to provide some enum for that purpose. However, > that can be done later and should not stop this from getting merged, > IMHO. > > cu > Michael > > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New patch series for the handling of CFI with stm32
Hi, Here my new series of patches. Jonathan 0002-Add-the-support-for-the-armv7m-arch.patch Description: Binary data 0001-Add-the-contrib-file-for-the-armv7m-arch.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
openocd-development-boun...@lists.berlios.de wrote: > On Sun, Dec 19, 2010 at 3:56 AM, Michael Schwingen > wrote: >> I think it is time to re-factor that target-algorithm code and pull >> the target dependencies out of the CFI code, but that would be a >> separate step. > > Fully agree! +1 Jonathan > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
andr...@fritiofson.net wrote: > On Fri, Dec 17, 2010 at 4:36 PM, Jonathan dumaresq > wrote: >> Hi all, >> >> Here my first patches to be able to use the CFI driver on cortex M3 >> with the helper code on target. This is probably not the better way >> of >> doing it, but at least it's work. This have been tested on real >> hardware. The default cfg that enable the fsmc can be used. Right now >> only the 16 bit interface has been tested. I can add the 8 and 32 >> bit if the patch is correct. >> >> From my testing, I got 17KB/sec >> >> I'll apreciate a feedback for thoses patches. Since this is nearly my >> first git pacthes... >> >> Regards >> >> Jonathan Dumaresq > > Just drop patch #3 and replace 'b done' with 'bkpt #0' in patch #1 > (and the corresponding opcode in patch #2). No need to add a > breakpoint programmatically. Look at the other armv7-m algorithms. As soon as I have some time (hoppefully befor xmas) I will change that. No problem at all > > Otherwise it looks good to me, but I'm no expert on the cfi-code. > Maybe the armv4_5_info naming is a bit odd if it now contains > armv7-related stuff, though. Full agree too. But I won't have an agressive patches set only for that. Since i'm not en expert at all in the openocd structure etc.. Jonathan > > /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Hi all, Here my first patches to be able to use the CFI driver on cortex M3 with the helper code on target. This is probably not the better way of doing it, but at least it's work. This have been tested on real hardware. The default cfg that enable the fsmc can be used. Right now only the 16 bit interface has been tested. I can add the 8 and 32 bit if the patch is correct. >From my testing, I got 17KB/sec I'll apreciate a feedback for thoses patches. Since this is nearly my first git pacthes... Regards Jonathan Dumaresq openocd-development-boun...@lists.berlios.de wrote: > Hi Spen, > > I'm happy that i'm not the only one !!! > > Is it possible to send or put somewhere a windows version that works > ? I have never compiled openocd so, if you can provide the binary > file i'll be happy. If not I can try to compiled it too. > > Regards > > Jonathan > Spencer Oliver wrote: >> On 06/12/2010 14:42, Jonathan dumaresq wrote: >>> >>> Have you fond some time to test this ? >>> >> >> I have run a quick test and it fails for me also. >> As a quick test i commented out block writes (cfi_write_words) and it >> works as expected - albeit even slower. >> >> Also found this patch where they have disabled buffer writes for the >> M29W128. >> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif > f;h=504a3e72208fc6a65924426ff5693982590bccdc >> >> Investigating there seems to be stack corruption within openocd when >> using block writes - the timeout param of >> cfi_spansion_wait_status_busy gets clobbered somewhere. >> >> Cheers >> Spen > > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development 0001-Add-new-loader-for-cortex-m3-16bit-spansion-interface.patch Description: Binary data 0002-Add-the-cortex-m3-target-as-possible-target.patch Description: Binary data 0003-Add-break-point-befor-going-in-target_resume.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Hi Spen, Have you try to write the image at 0x6420 ? From my testing on my custom board I always got random errors. I try with WORKING area and not. Regards Jonathan -Message d'origine- De : Spencer Oliver [mailto:s...@spen-soft.co.uk] Envoyé : 7 décembre 2010 11:21 À : Jonathan dumaresq Cc : 'Antonio Borneo'; openocd-development@lists.berlios.de Objet : Re: [Openocd-development] Problem loading to CFI flash On 06/12/2010 14:42, Jonathan dumaresq wrote: > > Have you fond some time to test this ? > I have run a quick test and it fails for me also. As a quick test i commented out block writes (cfi_write_words) and it works as expected - albeit even slower. Also found this patch where they have disabled buffer writes for the M29W128. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif f;h=504a3e72208fc6a65924426ff5693982590bccdc Investigating there seems to be stack corruption within openocd when using block writes - the timeout param of cfi_spansion_wait_status_busy gets clobbered somewhere. Cheers Spen -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Hi, -Message d'origine- De : andr...@fritiofson.net [mailto:andr...@fritiofson.net] De la part de Andreas Fritiofson Envoyé : 14 décembre 2010 15:39 À : Jonathan dumaresq Cc : Spencer Oliver; openocd-development@lists.berlios.de Objet : Re: [Openocd-development] Problem loading to CFI flash On Tue, Dec 14, 2010 at 7:26 PM, Jonathan dumaresq wrote: > Hi, > > I have pull the head branch of openocd and now I can write to the cfi > at a slow speed. I want to modify openocd to use the asm code for the > cortex. I have used the sample contrib file as starting point for the > cortex. I have been able to translate (a little effort there) the code. Now the question: > > 1- I have modifer the cfi.c to use my new opcodes in the word_16_code array. > 2- I have change armv4_5_info.common_magic for ARMV7M_COMMON_MAGIC > > Up to now, I get to the point that my new code is loaded to ram and > executed. The problem, is that I always exit of the > armv7m_run_algorithm with an timeout. The target is never halt. BUT, > when I look at the PC I'm at the exit point of the code, and the value > of R5 is 0x80. So From what I see, The flash have been writed > correctly. When I double check with mdw 0x6400 all the data is well written. > > I have no idea why or How the target will be halted. Does any one here > can point me to the righ direction ? > > I attach the asm file for the spansion 16 bin interface with the > cortex m3 > > Regards > > Jonathan Dumaresq > IIRC, all armv7-m algorithms must end with a BKPT instruction. That should probably be documented somewhere. Which sample contrib file are you talking about? armv4_5_cfi_span_16.s from the contrib folder Jonathan Regards, Andreas -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Found it. In the armv7m target, no breakpoint have been set. I have added a soft break point and now it seem to work well. Huge performance increase I try to get something in pathes Jonathan -Message d'origine- De : openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] De la part de Jonathan dumaresq Envoyé : 14 décembre 2010 13:27 À : 'Spencer Oliver' Cc : openocd-development@lists.berlios.de Objet : Re: [Openocd-development] Problem loading to CFI flash Hi, I have pull the head branch of openocd and now I can write to the cfi at a slow speed. I want to modify openocd to use the asm code for the cortex. I have used the sample contrib file as starting point for the cortex. I have been able to translate (a little effort there) the code. Now the question: 1- I have modifer the cfi.c to use my new opcodes in the word_16_code array. 2- I have change armv4_5_info.common_magic for ARMV7M_COMMON_MAGIC Up to now, I get to the point that my new code is loaded to ram and executed. The problem, is that I always exit of the armv7m_run_algorithm with an timeout. The target is never halt. BUT, when I look at the PC I'm at the exit point of the code, and the value of R5 is 0x80. So From what I see, The flash have been writed correctly. When I double check with mdw 0x6400 all the data is well written. I have no idea why or How the target will be halted. Does any one here can point me to the righ direction ? I attach the asm file for the spansion 16 bin interface with the cortex m3 Regards Jonathan Dumaresq -Message d'origine- De : openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] De la part de Jonathan dumaresq Envoyé : 7 décembre 2010 11:25 À : 'Spencer Oliver' Cc : openocd-development@lists.berlios.de Objet : Re: [Openocd-development] Problem loading to CFI flash Hi Spen, I'm happy that i'm not the only one !!! Is it possible to send or put somewhere a windows version that works ? I have never compiled openocd so, if you can provide the binary file i'll be happy. If not I can try to compiled it too. Regards Jonathan Spencer Oliver wrote: > On 06/12/2010 14:42, Jonathan dumaresq wrote: >> >> Have you fond some time to test this ? >> > > I have run a quick test and it fails for me also. > As a quick test i commented out block writes (cfi_write_words) and it > works as expected - albeit even slower. > > Also found this patch where they have disabled buffer writes for the > M29W128. > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif f;h=504a3e72208fc6a65924426ff5693982590bccdc > > Investigating there seems to be stack corruption within openocd when > using block writes - the timeout param of > cfi_spansion_wait_status_busy gets clobbered somewhere. > > Cheers > Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Hi, I have pull the head branch of openocd and now I can write to the cfi at a slow speed. I want to modify openocd to use the asm code for the cortex. I have used the sample contrib file as starting point for the cortex. I have been able to translate (a little effort there) the code. Now the question: 1- I have modifer the cfi.c to use my new opcodes in the word_16_code array. 2- I have change armv4_5_info.common_magic for ARMV7M_COMMON_MAGIC Up to now, I get to the point that my new code is loaded to ram and executed. The problem, is that I always exit of the armv7m_run_algorithm with an timeout. The target is never halt. BUT, when I look at the PC I'm at the exit point of the code, and the value of R5 is 0x80. So From what I see, The flash have been writed correctly. When I double check with mdw 0x6400 all the data is well written. I have no idea why or How the target will be halted. Does any one here can point me to the righ direction ? I attach the asm file for the spansion 16 bin interface with the cortex m3 Regards Jonathan Dumaresq -Message d'origine- De : openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] De la part de Jonathan dumaresq Envoyé : 7 décembre 2010 11:25 À : 'Spencer Oliver' Cc : openocd-development@lists.berlios.de Objet : Re: [Openocd-development] Problem loading to CFI flash Hi Spen, I'm happy that i'm not the only one !!! Is it possible to send or put somewhere a windows version that works ? I have never compiled openocd so, if you can provide the binary file i'll be happy. If not I can try to compiled it too. Regards Jonathan Spencer Oliver wrote: > On 06/12/2010 14:42, Jonathan dumaresq wrote: >> >> Have you fond some time to test this ? >> > > I have run a quick test and it fails for me also. > As a quick test i commented out block writes (cfi_write_words) and it > works as expected - albeit even slower. > > Also found this patch where they have disabled buffer writes for the > M29W128. > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif f;h=504a3e72208fc6a65924426ff5693982590bccdc > > Investigating there seems to be stack corruption within openocd when > using block writes - the timeout param of > cfi_spansion_wait_status_busy gets clobbered somewhere. > > Cheers > Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. armv7_cfi_span_16.s Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Hi Spen, I'm happy that i'm not the only one !!! Is it possible to send or put somewhere a windows version that works ? I have never compiled openocd so, if you can provide the binary file i'll be happy. If not I can try to compiled it too. Regards Jonathan Spencer Oliver wrote: > On 06/12/2010 14:42, Jonathan dumaresq wrote: >> >> Have you fond some time to test this ? >> > > I have run a quick test and it fails for me also. > As a quick test i commented out block writes (cfi_write_words) and it > works as expected - albeit even slower. > > Also found this patch where they have disabled buffer writes for the > M29W128. > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif f;h=504a3e72208fc6a65924426ff5693982590bccdc > > Investigating there seems to be stack corruption within openocd when > using block writes - the timeout param of > cfi_spansion_wait_status_busy gets clobbered somewhere. > > Cheers > Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Hi Spen, Spencer Oliver wrote: > On 23/11/2010 03:04, Antonio Borneo wrote: >> Jonathan, >> could you please report the full part number of the flash chip? >> Form the log, seems Numonyx M29W128G >>Flash Manufacturer/Device: 0x0020 0x227e >> >> Spencer, >> the flash M29W128G has a HW bug. Numonyx application note in >> http://www.numonyx.com/Documents/Application%20Notes/AN309814.pdf >> You already fixed it in commit >> bbc8f4e6cec361a34028dad4b5000c136f4f48b2 >> Have you ever tested writing this flash NOT in block mode? >> > > Pretty certain when i added the patch it was tested on the stm32eval. > If get a chance tomorrow i will recheck writing to this board. > > Cheers > Spen Have you fond some time to test this ? Jonathan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Hi Antonio, Antonio Borneo wrote: > Jonathan, > could you please report the full part number of the flash chip? > Form the log, seems Numonyx M29W128G > Flash Manufacturer/Device: 0x0020 0x227e Yes this is the part in question. M29W128GL70N6E > > Spencer, > the flash M29W128G has a HW bug. Numonyx application note in > http://www.numonyx.com/Documents/Application%20Notes/AN309814.pdf You > already fixed it in commit bbc8f4e6cec361a34028dad4b5000c136f4f48b2 > Have you ever tested writing this flash NOT in block mode? Is it possible to use the block mode to flash a binary file ? Regards Jonathan > > Best Regards, > Antonio Borneo ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Hi Michael, openocd-development-boun...@lists.berlios.de wrote: > On 11/22/2010 07:10 PM, Jonathan dumaresq wrote: >> >>> Cannot see anthing wrong with that log - except it is probably slow. >>> >>> Cheers >>> Spen >> The problem seem to me that the remaining bytes should be zero at the >> end of the flashing ? > It should be, yes. > > However, I can't see the end in the log - did it stop there without > an error message, or did you abort because it was slow? I have no error. The openocd stop there, and I loose the control of it. Openocd stop responding. > > I see the remaining count decreasing in 256-byte steps, which looks > normal. As soon as it reaches zero, it should terminate. > > The slow speed is normal in the case where no support code on the > target is available - we need to shift several 10-100 bits for each > bus cycle to the flash, and every word takes 3 bus cycles if the > flash has no pagemode, or 1 cycle + setup if pagemode is used. I see the 256 chunk decrease at a slow speed, but it's hang there. > > cu > Michael > Jonathan > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Hi, Spencer Oliver wrote: What you found is a missing feature of OpenOCD. The fix would require one of the following: - a specific code for ARMV7M (this will solve your case only) - a fall-back C code in case of no binary for target (solves all cases, but slow) >> I tried this approach but the writing of the image hangs. I'll >> attached the log output. It's always hang at the same place. >> > > Cannot see anthing wrong with that log - except it is probably slow. > > Cheers > Spen The problem seem to me that the remaining bytes should be zero at the end of the flashing ? Jonathan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Hi spencer, Spencer Oliver wrote: > On 20/11/2010 01:39, Antonio Borneo wrote: >> >> Ciao Jonathan, >> OpenOCD runs binary code on the target CPU to speed-up some operation >> that through JTAG would take too long. >> Programming the Flash is one of them. >> >> In the CFI driver there is the binary code for generic ARM only. >> armv4_5_info.common_magic = ARM_COMMON_MAGIC; >> STM32 is a Cortex M3 CPU, and it requires code to be labelled >> "ARMV7M_COMMON_MAGIC" to run it. This is why you get that error. >> >> At this point I already see something to double check in the code: >> Cortex M3 code defines the macro CORTEX_M3_COMMON_MAGIC, but then >> requires ARMV7M >> >> What you found is a missing feature of OpenOCD. >> The fix would require one of the following: >> - a specific code for ARMV7M (this will solve your case only) >> - a fall-back C code in case of no binary for target (solves all >> cases, but slow) >> I tried this approach but the writing of the image hangs. I'll attached the log output. It's always hang at the same place. Regards Jonathan > > This has been on my todo list for a while. > A temp workaround is to not use a working area - it will be a lot > slower however. > > My init script for the stm32 fsmc can be found here: > http://repo.or.cz/w/openocd/ntfreak.git/commitdiff/dee66760b31d85d61e19d5a40 1f23c2a8bcc590f > > Cheers > Spen openocd.log Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Hi Spencer, Spencer Oliver wrote: > On 20/11/2010 01:39, Antonio Borneo wrote: >> >> Ciao Jonathan, >> OpenOCD runs binary code on the target CPU to speed-up some operation >> that through JTAG would take too long. >> Programming the Flash is one of them. >> >> In the CFI driver there is the binary code for generic ARM only. >> armv4_5_info.common_magic = ARM_COMMON_MAGIC; >> STM32 is a Cortex M3 CPU, and it requires code to be labelled >> "ARMV7M_COMMON_MAGIC" to run it. This is why you get that error. >> >> At this point I already see something to double check in the code: >> Cortex M3 code defines the macro CORTEX_M3_COMMON_MAGIC, but then >> requires ARMV7M >> >> What you found is a missing feature of OpenOCD. >> The fix would require one of the following: >> - a specific code for ARMV7M (this will solve your case only) >> - a fall-back C code in case of no binary for target (solves all >> cases, but slow) At least if this work, i will try it. Righ now we have 2 choices, 1 serial flashing or jtag flashing. Regards Jonathan >> > > This has been on my todo list for a while. > A temp workaround is to not use a working area - it will be a lot > slower however. > > My init script for the stm32 fsmc can be found here: > http://repo.or.cz/w/openocd/ntfreak.git/commitdiff/dee66760b31d85d61e19d5a40 1f23c2a8bcc590f > > Cheers > Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem loading to CFI flash
Antonio Borneo wrote: > On Sat, Nov 20, 2010 at 4:51 AM, Jonathan dumaresq > wrote: >> Hi all, >> >> I try to get my cfi external nor flash programmed with openocd. >> >>> flash write_image test.hex 0x6400 bin >> current target isn't an ARMV7M target >> >> I have no idea why ARMV7M is listed here... >> >> Any idea ? > > Ciao Jonathan, > OpenOCD runs binary code on the target CPU to speed-up some operation > that through JTAG would take too long. > Programming the Flash is one of them. > > In the CFI driver there is the binary code for generic ARM only. >armv4_5_info.common_magic = ARM_COMMON_MAGIC; > STM32 is a Cortex M3 CPU, and it requires code to be labelled > "ARMV7M_COMMON_MAGIC" to run it. This is why you get that error. > > At this point I already see something to double check in the code: > Cortex M3 code defines the macro CORTEX_M3_COMMON_MAGIC, but then > requires ARMV7M > > What you found is a missing feature of OpenOCD. This is what I though > The fix would require one of the following: > - a specific code for ARMV7M (this will solve your case only) > - a fall-back C code in case of no binary for target (solves all > cases, but slow) I'll see what I can do for this. > > Best Regards > Antonio Borneo ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Problem loading to CFI flash
Hi all, I try to get my cfi external nor flash programmed with openocd. I use en stm32 chip with the FSMC to talk to the CFI flash. Write now I can get the openocd reconised the cfi chip. cfi information: mfr: 0x0020, id:0x227e qry: 'QRY', pri_id: 0x0002, pri_addr: 0x0040, alt_id: 0x, alt_addr: 0x Vcc min: 2.7, Vcc max: 3.6, Vpp min: b.5, Vpp max: c.5 typ. word write timeout: 16, typ. buf write timeout: 16, typ. block erase timeou t: 512, typ. chip erase timeout: 65536 max. word write timeout: 256, max. buf write timeout: 256, max. block erase time out: 4096, max. chip erase timeout: 1048576 size: 0x100, interface desc: 2, max buffer write size: 40 Spansion primary algorithm extend information: pri: 'PRI', version: 1.3 Silicon Rev.: 0x3, Address Sensitive unlock: 0x1 Erase Suspend: 0x2, Sector Protect: 0x1 VppMin: 11.5, VppMax: 12.5 I can erase sectors, I can unlock the sectors too, but I could not program to it. When I try the Flash write_image test.bin 0x6400 bin , I got this error from openocd > flash protect 1 0 127 off protect: cfi primary command set 2 unsupported cleared protection for sectors 0 through 127 on flash bank 1 > flash erase_sector 1 0 127 erased sectors 0 through 127 on flash bank 1 in 49.546875s > flash write_image test.hex 0x6400 bin current target isn't an ARMV7M target error writing to flash at address 0x6400 at offset 0x (-902) Command handler execution failed in procedure 'flash' called at file "command.c", line 650 called at file "command.c", line 361 > I have no idea why ARMV7M is listed here... Any idea ? openocd.log Description: Binary data openocd.cfg Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Stm32 load elf file with gdb
Hi,
andr...@fritiofson.net wrote:
> On Thu, Nov 4, 2010 at 2:46 PM, Jonathan dumaresq
> wrote:
>> Hi all,
>>
>> I try to get my stm32 environnement working with gdb. I'm unable to
>> get my elf file loaded with gdb. Here my setup:
>>
>> Openocd.cfg
>> /
>> source [find interface/olimex-arm-usb-ocd.cfg] source [find
>> target/stm32.cfg]
>>
>> stm32.cpu configure -event gdb-flash-write-end {
>> reset init
>> }
>>
>> stm32.cpu configure -event gdb-flash-erase-start {
>> reset init
>> }
>> ///
>>
>> All include file are default.
>>
>> Here how i lunch gdb
>>
>> Arm-none-eabi-gdb rtosdemo.elf
>>
>>
>> (gdb)target remote | openocd --pipe
>> (gdb)load rtosdemo.elf
>> (gdb) load
>> Loading section .text, size 0xa7d8 lma 0x0
>> Debug: 408 139609 gdb_server.c:2145 gdb_input_inner(): received
>> packet: 'X0,3fb0 :'
>> Debug: 409 139609 gdb_server.c:1388
>> gdb_write_memory_binary_packet(): addr: 0x00 00, len: 0x3fb0
>> Debug: 410 139609 target.c:1251 target_write_buffer(): writing buffer
>> of
>> 16304 b
>> yte at 0x
>
> 0x is most certainly the wrong place to be writing stuff...
Agree
>
>> Warn : 419 139828 arm_adi_v5.c:720 mem_ap_write_buf_u32(): Block
>> write error add ress 0x0, wcount 0xfec
>> Error: 420 139828 gdb_server.c:1211 gdb_error(): unexpected error
>> -107 Load failed (gdb)
>>
>> I have to admit that i'm a little bit lost there. Do i have something
>> else to do to get this work ?
>
> Yes, you need to fix your broken linker script (in case of GNU ld) to
> place your code in flash, which is located at 0x0800, not 0x0.
That strange, this is the linker file from ST. I fix that and see what
happen !
Regards
Jonathan
>
> Regards,
> Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Stm32 load elf file with gdb
Hi all,
I try to get my stm32 environnement working with gdb. I'm unable to get my
elf file loaded with gdb. Here my setup:
Openocd.cfg
/
source [find interface/olimex-arm-usb-ocd.cfg]
source [find target/stm32.cfg]
stm32.cpu configure -event gdb-flash-write-end {
reset init
}
stm32.cpu configure -event gdb-flash-erase-start {
reset init
}
///
All include file are default.
Here how i lunch gdb
Arm-none-eabi-gdb rtosdemo.elf
(gdb)target remote | openocd --pipe
(gdb)load rtosdemo.elf
(gdb) load
Loading section .text, size 0xa7d8 lma 0x0
Debug: 408 139609 gdb_server.c:2145 gdb_input_inner(): received packet:
'X0,3fb0
:'
Debug: 409 139609 gdb_server.c:1388 gdb_write_memory_binary_packet(): addr:
0x00
00, len: 0x3fb0
Debug: 410 139609 target.c:1251 target_write_buffer(): writing buffer of
16304 b
yte at 0x
Debug: 411 139687 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp:
CTRL/
STAT error, 0xf021
Error: 412 139687 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP
STICKY
ERROR
Debug: 413 139703 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp:
CTRL/
STAT 0xf001
Error: 414 139703 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW
0x2
352, MEM_AP_TAR 0x4
Debug: 415 139797 arm_adi_v5.c:335 jtagdp_transaction_endcheck(): jtag-dp:
CTRL/
STAT error, 0xf021
Error: 416 139797 arm_adi_v5.c:361 jtagdp_transaction_endcheck(): JTAG-DP
STICKY
ERROR
Debug: 417 139797 arm_adi_v5.c:373 jtagdp_transaction_endcheck(): jtag-dp:
CTRL/
STAT 0xf001
Error: 418 139828 arm_adi_v5.c:380 jtagdp_transaction_endcheck(): MEM_AP_CSW
0x2
352, MEM_AP_TAR 0x4
Warn : 419 139828 arm_adi_v5.c:720 mem_ap_write_buf_u32(): Block write error
add
ress 0x0, wcount 0xfec
Error: 420 139828 gdb_server.c:1211 gdb_error(): unexpected error -107
Load failed
(gdb)
I have to admit that i'm a little bit lost there. Do i have something else
to do to get this work ?
Thanx
Jonathan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
Hi, -Message d'origine- De : oyvindhar...@gmail.com [mailto:oyvindhar...@gmail.com] De la part de Øyvind Harboe Envoyé : 15 mai 2009 09:15 À : Jonathan Dumaresq Cc : Rick Altherr; openocd-development Objet : Re: [Openocd-development] resubmit lost works! > Generally this is where a bug tracking system comes into play. Of > course, as a community, we seem to be against that idea. > > This is something that we like to use too keep track of issues. > > It's easy to use and at least, outsider don't have to read all the last > years of email to know what's work and what don't ! Do we allow anybody to register bugs? Perhaps we should require all bugs to be discussed in this mailing list first? Yes this is the way that i'm thinking of. But if this bugs is confirmed but could not get fixed right now, you need to read all post of the list to know that this bugs exist and it's not fixed. We are 5 developper here, and I'm the only one that read all the mail in that list. For our projects, we use a project manager that is called DotProject. We have written some plugins to get it work as we want. It's a web based system. We can assign task to developer, rank % of the completion etc. Create bugs report. I don't see more work to write a problem in a text file instead of a web based application. It's no good to have a million bugs in a database and have nobody read that database either. Well this is only a suggestion than a request. Regards Jonathan -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
-Message d'origine-
De : openocd-development-boun...@lists.berlios.de
[mailto:openocd-development-boun...@lists.berlios.de] De la part de Rick
Altherr
Envoyé : 15 mai 2009 02:09
À : Øyvind Harboe
Cc : openocd-development
Objet : Re: [Openocd-development] resubmit lost works!
On May 14, 2009, at 11:03 PM, Øyvind Harboe wrote:
> Where do I post bugs that I observe, but have no time to pursue?
>
> Here is a bug that I have observed and kinda know the reason for:
>
> proc foo{a} {
>verify_image $a
> }
>
> # this will fail since command.c does not correctly create an
> overrideable proc
> foo c:\\temp\\test.bin
>
> #this works
> verify_image c:\\temp\\test.bin
>
>
>
> --
> Øyvind Harboe
> Embedded software and hardware consulting services
> http://consulting.zylin.com
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
Generally this is where a bug tracking system comes into play. Of
course, as a community, we seem to be against that idea.
This is something that we like to use too keep track of issues.
It's easy to use and at least, outsider don't have to read all the last
years of email to know what's work and what don't !
My 0.02$
Jonathan
--
Rick Altherr
kc8...@kc8apf.net
"He said he hadn't had a byte in three days. I had a short, so I split
it with him."
-- Unsigned
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] config file for downloading to a sam7s device
Hi all, I want to upgrade my revision 645 openocd to the new 0.1.0. I see that many things have changed. I try to get my setup in the same way I had my last one. I would like to be able to download my application to the flash of the sam7s parts. I Have a 256K flash device. Here what I have so far in my cfg. // source [find interface/olimex-arm-usb-ocd.cfg] # Change the default telnet port... telnet_port # GDB connects here gdb_port # GDB can also flash my flash! gdb_memory_map enable gdb_flash_program enable source [find target/sam7x256.cfg] # AT91SAM7 flash command-"batch" wait_halt arm7_9 dcc_downloads enable armv4_5 core_state arm flash probe 0 #flash erase 0 0 0 #flash protect 0 0 2 off flash write_binary 0 main.bin 0x0 mww 0xfd08 0xa5000401 reset shutdown // But I got errors on Wait_halt, flash probe 0 and flash write_binary command. They are not reconized. //--- C:\Documents and Settings\dumarjo\Bureau\test_location_code>openocd Open On-Chip Debugger 0.1.0 (2009-01-21-21:15) Release BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd 0.1.0/src /openocd.c $ Runtime error, file "openocd.cfg", line 14: Unknown command: wait_halt C:\Documents and Settings\dumarjo\Bureau\test_location_code> // Is there a sample cfg that I can start with ? I can connect to the target with telnet with no problem. I can use the flash info 0 to get the falsh status. Regards Jonathan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 RIDE7 OPENCOD
HI, Thanx for the answer. SO from what I see, is no way to use openOCD with RIDE7 ? I have an Olimex ARM-USB-OCD device. This could be fun to have OpenOCD support in RIDE7. Jonathan -Message d'origine- De : openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] De la part de Freddie Chopin Envoyé : 3 mars 2009 16:52 À : openocd-development@lists.berlios.de Objet : Re: [Openocd-development] STM32 RIDE7 OPENCOD Jonathan Dumaresq pisze: > If not, what IDE > toolchain you suggest to be able to debug, download to target ? you can create your own toolchain with Eclipse, CodeSourcery's gcc (G++ Lite) and OpenOCD. Just remember that the gdb in the most recent CodeSourcery (and the one before) are somehow broken, so just use the gdb from Ride or yagarto or any other toolchain you like. > Eclipse with CDT ? is it possible to get something that use managed makefile There is - AFAIK - no working plugin to support managed makefile project for ARM in Eclipse. some very useful info can be found on yagarto.de website, in the How-To sections. You can use that to create your own toolchain. IMHO you don't need the Zylin CDT plugin, because the GDB Hardware Debugging (standard plugin) works just fine (and for me even better). 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] STM32 RIDE7 OPENCOD
HI all, I have used openocd for more than 1 year now on ARM7 platform. We will start a new design based on the STM32. I see some information about it here in the list aboute the speed issue. This is not my main issue with this. I would like to know if it is possible to use openocd from RIDE7 ? If not, what IDE toolchain you suggest to be able to debug, download to target ? Eclipse with CDT ? is it possible to get something that use managed makefile ? Regards Jonathan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] TR: OpenOCD 0.1.0 released
Forgot to cc the list. Sorry about that. Jonathan Hi, Great Job We are happy that OpenOCD will do releases. It always easier for user to have official releases. Keep your great work all ! Jonathan -Message d'origine- De : openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] De la part de Rick Altherr Envoyé : 20 janvier 2009 23:33 À : Openocd-Dev Objet : [Openocd-development] OpenOCD 0.1.0 released I just uploaded the source distribution of OpenOCD 0.1.0 to the BerliOS project site (http://developer.berlios.de/projects/openocd/). Thanks to everyone for their contributions and testing. The final version of 0.1.0 differs only by a few minor fixes to the autotools scripts and the inclusion of the udev script in contrib. Package maintainers: If you wish to have a set of binaries placed on the project site, please build the package and send it to me. -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
