I have seen some info scattered through the atmel documentation that indicates that methods exist to program the AT91SAM7 range of micros in-situ. The documentation hints that the serial debug port can be used for in-situ programming, but that the Fast Flash Programming Interface can't. X-Modem is mentioned in one place. I would like to program the micros in-situ, using either the JTAG port of the serial port. My first target is the AT91SAM7S32. Obviously the J-Link programmers etc have some technique. Does anybody have any clues or can point me to online documents that I can read. Thanks Jason |
In-situ programming
Started by ●February 8, 2005
Reply by ●February 8, 20052005-02-08
Hi, I think this is paid SW from Segger - see http://segger.com (who manufacture the J-Link). This SW is not included in the IAR KickStart package - AFAIK (I have the AT91SAM7S64-IAR package myself ...). It comes either a 'standalone' utility or as DLLs (which you can incorporate in your own SW, if you wish;-). Both have to be paid for ...:-/ You're better using the "SAMBA" utility from Atmel. It currently supports the AT91RM9200 and AT91RM3400 - but a release w. 'SAM7S support is underway (if not there already ...). The SAM7S devices have a two-part bootloader (in mask-ROM); 1) a section which contains a bootloader communication over the DBGU-UART (115200bps - AFAIK) 2) a section which contains a bootloader communication over the USB deviceport This is the same scheme as deployed on the two abovementioned devices. SAMBA is supposed to be able to use both methods. In short, SAM7S has 4 methods in all for Flash programming ---------------------- 1. FPPI/parallell - dedicated for gang programmers ('offline') - not practical on board 2. JTAG (of course) - per register manipulations and/or stub downloaded to RAM 3. internal ROM-bootloader using DBGU/UART 4. internal ROM-bootloader using USB (probably fastest & easiest) All security measures (e.g. lock bits) are available to each method (NB: AFAIK ...) -Morten > -----Original Message----- > From: jasn_net [mailto:] > Sent: Tuesday, February 08, 2005 6:24 AM > To: > Subject: [BULK] [AT91SAM7] In-situ programming > Importance: Low > > > I have seen some info scattered through the atmel > documentation that indicates that methods exist to program > the AT91SAM7 range of micros in-situ. The documentation hints > that the serial debug port can be used for in-situ > programming, but that the Fast Flash Programming Interface > can't. X-Modem is mentioned in one place. > > I would like to program the micros in-situ, using either the > JTAG port of the serial port. My first target is the AT91SAM7S32. > > Obviously the J-Link programmers etc have some technique. > Does anybody have any clues or can point me to online > documents that I can read. > > Thanks > > Jason > > Yahoo! Groups Links |
Reply by ●February 8, 20052005-02-08
Hi Larsen et al,
> The SAM7S devices have a two-part bootloader (in mask-ROM);
> 1) a section which contains a bootloader communication over the > DBGU-UART > (115200bps - AFAIK) > 2) a section which contains a bootloader communication over the USB > deviceport > This is the same scheme as deployed on the two abovementioned devices. > SAMBA is supposed to be able to use both methods. I haven't found any references yet to that Larsen, (especially the USB
bootload).
Is this still vapourware, or is that *actually* already there, wrt SAMBA
?
> In short, SAM7S has 4 methods in all for Flash programming
> ---------------------- > 1. FPPI/parallell - dedicated for gang programmers ('offline') > - not practical on board > 2. JTAG (of course) - per register manipulations and/or stub downloaded > to RAM > 3. internal ROM-bootloader using DBGU/UART > 4. internal ROM-bootloader using USB (probably fastest & easiest) > > All security measures (e.g. lock bits) are available to each method (NB: > AFAIK ...) I haven't tried setting security yet actually on the SAM7S64 thru
JTAG.
Must go on \todo list.
Surely it'd be programmed in separately *after* the Flash D/L verify
is done. :-)
For those that struggle(d) with Flash/RAM debugs and/or downloads.
You might want to give CrossWorks for ARM a whirl.
Even simply using a Wiggler really flies through the thing.
I tried with the IAR "kickstart" EWARM, and the download seems to take
forever,
even on a couple of Kb. (This is using the McCraigor driver in EW debugger,
with JTAG
clock / 1).
The same identical homebrew Wiggler connected with CrossWorks for ARM
Flashes in the
code at lighting fast speed compared, and that's just LPT1, not even
USB.
(the J-Link doesn't work too well for me)
I'm also mentioning this because Rowley Assocs provides the source for
the loader, C code,
that programs/verifies Flash on per-sector basis, with a strap from RAM of
course.
Can't go wrong with that.
Perhaps if anything else download an eval, and try it out that way,
there's turnkey examples
in there for SAM7S-EK, and in a couple of minutes you'll be "on the
air".
B rgds
Kris
|