From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3699 invoked by alias); 25 May 2006 00:39:07 -0000 Received: (qmail 3683 invoked by uid 22791); 25 May 2006 00:39:07 -0000 X-Spam-Check-By: sourceware.org Received: from h-66-166-225-55.cmbrmaor.covad.net (HELO baradas.org) (66.166.225.55) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 25 May 2006 00:39:05 +0000 Received: by baradas.org (Postfix, from userid 500) id 024D298B97; Wed, 24 May 2006 20:38:58 -0400 (EDT) From: Peter Barada To: sjohnson@sakuraindustries.com Cc: gdb@sourceware.org In-reply-to: <4474F8D3.3000708@sakuraindustries.com> (message from Steven Johnson on Thu, 25 May 2006 11:22:43 +1100) Subject: Re: GDB support for Flash memory programming References: <4474F8D3.3000708@sakuraindustries.com> Message-Id: <20060525003858.024D298B97@baradas.org> Date: Thu, 25 May 2006 01:11:00 -0000 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00359.txt.bz2 >>If the flash memory controller has a JTAG interface (most do) then the >>flash memory can typically be programmed using the same ICE/BDM unit >>that is used for debugging. >> >> >Yes, but my experience is this is horribly slow, due to the polling >that has to occur of each byte (or programming word for 16bit and 32bit >wide flashes) as it is programmed. I think directly programming over >JTAG/BDM should be avoided, unless there is no alternative. Even on >systems where ram is limited, flash could be programmed in chunks, eg: Another possibility is to have GDB could download/execute a small PIC function that does the flash programming with its inherent polling which should speed things up *immensely*. Also this function can be tailored to the specifics of the layout (or use global variables for it). I think the necessary "programming stub" would be small enough to download, and it would leverage the code that GDB uses to call a procedure on the target, captures the return, aka: (gdb) p burn_to_flash(flash_addr, buf_addr, sector_size) Of course presented to the user to appear as a command as in: (gdb) burn-flash where the buf_addr could be on the stack, and capture the result from the download/call as a command result, that can then generate an error as in "flash block locked". This result is extremely extensible to do far more flexible things that require target manipulation at speeds *far* faster than the remote protocol can do. It also allows for manipulating a target that uses a stub that doesn't even have a JTAG/BDM interface... -- Peter Barada peter@the-baradas.com