Thank you for your replies. Internal flash is non-standard. It does not confirm to the CFI standard. So I cannot simply configure the internal flash as flash_cfi device.
The chip only uses SRAM for data (you cannot execute out of SRAM). There is a 256 byte RAM area that can be used to execute code. Right now, I have it configured for openocd to use when loading data to SRAM. My idea is to: 1. load 64k of code to SRAM via jtag (this is the method I am looking for) 2. use tcl script to erase, copy and program SRAM->flash 3. go back to step 1 (7 times for total of 512kbytes). I have a tcl script that correctly programs a sector of flash but I can't find a command that will load a portion of a file to a specific memory location. I will be happy to add such a command to openocd if it does not exit yet. I thought that someone had to run into this problem before. --Michal On Thu, 2010-03-25 at 07:11 +0100, [email protected] wrote: > Send Openocd-development mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.berlios.de/mailman/listinfo/openocd-development > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Openocd-development digest..." > > > Today's Topics: > > 1. Re: adapter_khz ... (David Brownell) > 2. Re: OpenOCD - Amontec JTAGkey-2 and default JTAG TCK > frequency problem - workaround - solution (David Brownell) > 3. Re: ST-Link with OpenOCD? (simon qian) > 4. load_image question (michal smulski) > 5. Re: load_image question (Freddie Chopin) > 6. Re: xds100v2 (Michael Schwingen) > 7. [SWD] STM32Primer2 JTAG/SWD + RLink pinout + RLink protocol > dump (CeDeROM) > 8. Re: load_image question (Michel Catudal) > 9. Re: Unused symbols; Global vs Static (Antonio Borneo) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 24 Mar 2010 11:49:59 -0700 > From: David Brownell <[email protected]> > To: [email protected] > Cc: Laurent Gauch <[email protected]> > Subject: Re: [Openocd-development] adapter_khz ... > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > On Wednesday 24 March 2010, Laurent Gauch wrote: > > > We really don't want to need JTAG and SWD versions of every config > > > script and event handler based on what transport is in use... > > > ? > > We do not need to write specific scipt versions for JTAG or SWD serial > > port, but we will have to give in the target script what is the maximum > > specific frequency of each serial port : > > > > 'target_jtag_max_tck_frequency_khz' > > 'target_swd_max_tck_frequency_khz' > > JTAG and SWD share key signals though ... on both adapter and target > sides. Lots of boards have a single JTAG/SWD connector. > > > I really see *NO* good things coming from creating more ways to confuse > configurations. Especially .... more *needless* confusion. > > > > ------------------------------ > > Message: 2 > Date: Wed, 24 Mar 2010 11:52:25 -0700 > From: David Brownell <[email protected]> > To: [email protected] > Cc: Laurent Gauch <[email protected]> > Subject: Re: [Openocd-development] OpenOCD - Amontec JTAGkey-2 and > default JTAG TCK frequency problem - workaround - solution > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > On Wednesday 24 March 2010, ?yvind Harboe wrote: > > I think it makes sense that target scripts now > > have to work on SWD *and* JTAG and that they shouldn't really > > contain anything jtag or swd specific unless there is a reason to. > > Exactly where I'm coming from... > plus, we should avoid creating such reasons > > > > ------------------------------ > > Message: 3 > Date: Thu, 25 Mar 2010 03:37:40 +0800 > From: simon qian <[email protected]> > To: Spencer Oliver <[email protected]> > Cc: [email protected], [email protected] > Subject: Re: [Openocd-development] ST-Link with OpenOCD? > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Yes, as i know, ST-Link support STM32 and STM8 only, by providing high level > function for debugging. > But the protocol is not available. > > Check mspgcc, there is a gdbproxy supporting MSP430FET tools. > If there is a similar mechanism in OpenOCD, it will be very easy to support > ST-Link. > > 2010/3/23 Spencer Oliver <[email protected]> > > > On 23/03/2010 10:12, simon qian wrote: > > > >> ST doesn't open the protocol of ST-Link, so it's impossible to support > >> it in OpenOCD. > >> I have 2 ST-Link sent by vendor of ST, but now, they are Versaloon. > >> > >> > > ST sent me the api, it is based on mass storage device. > > They are happy for openocd to support it. > > > > The current issue is that it is high level access only, eg. > > Step Core, Read registers etc. So some changes are required to support this > > kind of dongle. > > > > Cheers > > Spen > > > > > > -- > Best Regards, SimonQian > http://www.SimonQian.com > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://lists.berlios.de/pipermail/openocd-development/attachments/20100325/fd0f8498/attachment-0001.html> > > ------------------------------ > > Message: 4 > Date: Wed, 24 Mar 2010 14:35:54 -0700 > From: michal smulski <[email protected]> > To: [email protected] > Subject: [Openocd-development] load_image question > Message-ID: <[email protected]> > Content-Type: text/plain; charset="UTF-8" > > Hi, > > I have an ARM IC with internal flash (512kbytes) and sram (64kbytes). I > am trying to write flash via jtag. The idea is to split the image into > 64kb chunks and upload them via jtag one at a time to internal SRAM; > then burn to flash. > However, I can't seem to find an appropriate openocd command to do this. > load_image is the closest but it does not allow me to do this. > > Could someone point me to a thread that relates to this issue? I am sure > I am not the first person to run into this problem. > > Thanks > Michal > > > > > ------------------------------ > > Message: 5 > Date: Wed, 24 Mar 2010 23:17:18 +0100 > From: Freddie Chopin <[email protected]> > To: [email protected] > Subject: Re: [Openocd-development] load_image question > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2010-03-24 22:35, michal smulski wrote: > > I have an ARM IC with internal flash (512kbytes) and sram (64kbytes). I > > am trying to write flash via jtag. The idea is to split the image into > > 64kb chunks and upload them via jtag one at a time to internal SRAM; > > then burn to flash. > > However, I can't seem to find an appropriate openocd command to do this. > > load_image is the closest but it does not allow me to do this. > > > > Could someone point me to a thread that relates to this issue? I am sure > > I am not the first person to run into this problem. > > Where is your problem? OpenOCD usually does just that - uploads pieces > of image to RAM and flash them. > > 4\/3!! > > > ------------------------------ > > Message: 6 > Date: Wed, 24 Mar 2010 23:24:26 +0100 > From: Michael Schwingen <[email protected]> > To: [email protected] > Subject: Re: [Openocd-development] xds100v2 > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-15 > > David Brownell wrote: > > Not quite. One you own the hardware you can do whatever you > > like with it. > > > > The legal restriction has to do with using schematics/etc to > > provide support for other tools. But if you create such > > support and don't distribute it, you should be OK. > > > So if someone writes up documentation on the interface, and someone else > who never downloaded the schematics from TI writes OpenOCD support based > on that documentation, it should be OK to distribute - but IANAL. > > cu > Michael > > > > ------------------------------ > > Message: 7 > Date: Thu, 25 Mar 2010 00:06:57 +0000 > From: CeDeROM <[email protected]> > To: Openocd-Dev <[email protected]> > Subject: [Openocd-development] [SWD] STM32Primer2 JTAG/SWD + RLink > pinout + RLink protocol dump > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > Hello world! > > I had to reschedule my tasks/priorities and it looks I am totally > overworked until end of June, so I will not be able to work on SWD as > I wanted, sorry :-( :-( :-( However I am still able to perform > part-time support towards STM32 and SWD. Currently I have captured > data transfers between RIDE7 and RLink on STM32Primer2 in most popular > operations, so it could give an input on how to program this device > (no debug at this moment). I guess that RLink might be intelligent > enough not to disturb user with low-level operations such as JTAG and > SWD, so programming with SWD might look similar than it is done with > JTAG (only my guess!). Please take a look at the dumps - I have also > attached an installation software viewer for *.ufo file format > (windows only sorry). With the RLink pinout and the transfer dumps it > should be possible to implement at least flash programming onboard > the STM32Primer2. If desired I can also perform similar low-level > hardware dumps done with STM32Primer1 for full protocol comparision > (if still anything is unknown for Primer1). > > Here are the files: > http://files.tomek.cedro.info/electronics/arm/cortex-m3/stm32/ > > Best regards, > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > ------------------------------ > > Message: 8 > Date: Wed, 24 Mar 2010 19:51:16 -0400 > From: Michel Catudal <[email protected]> > To: [email protected] > Subject: Re: [Openocd-development] load_image question > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Le 24/03/2010 17:35, michal smulski a ?crit : > > Hi, > > > > I have an ARM IC with internal flash (512kbytes) and sram (64kbytes). I > > am trying to write flash via jtag. The idea is to split the image into > > 64kb chunks and upload them via jtag one at a time to internal SRAM; > > then burn to flash. > > However, I can't seem to find an appropriate openocd command to do this. > > load_image is the closest but it does not allow me to do this. > > > > Could someone point me to a thread that relates to this issue? I am sure > > I am not the first person to run into this problem. > > > > Thanks > > Michal > > > > > > > > > You need to have an application that takes over. > Since your code would run into RAM you could not use the whole 64k for > your buffer. > > Michel > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
