Page 1 of 1
flash programming during production (in-situ), at921sam7s
Posted: Mon Dec 05, 2005 5:49 pm
i am looking for the best solution for in-situ flash-programming of a pcb with the at91sam7s.
here the solutions i found:
is not usable because i would like to program the flash in-situ.
i already read in another thread that sam-ba is not the right choice for production programming. the tst-handling and the 10s delay at start-up make things not easier.
seems to be the only solution.
-) connector for jtagce interface on every board necessary (mainly a problem of enough space and also cost).
-) external device (e.g. sam-ice) necessary
-) at the moment no comand-line version of the programming-tool (j-flash) available(is this correct?).
-) j-flash (see www.segger.com
) is not for free (€398)
did i miss something?
Posted: Mon Dec 05, 2005 9:39 pm
With the JTAG solution you only need to provid the necessary contact pads and a spring contact fixture, this saves the cost of the connector on every board.
If you actually allow a connector you have the added advantage that in-circuit debugging can be done with any unit if you populate the connector (can be done when needed).
As for the hardware there are a number of ways to handle the JTAG interface.
Posted: Tue Dec 06, 2005 9:46 am
many thansk for your posting.
some questions i have
tschultz wrote:With the JTAG solution you only need to provid the necessary contact pads and a spring contact fixture, this saves the cost of the connector on every board.
if i use contact pads and spring contact fixture i have to use a longer cable for connecting. did you experience any problems with it?
tschultz wrote:As for the hardware there are a number of ways to handle the JTAG interface.
what types of jtag interface do you use?
i only know the segger j-link and that one from rowley.
the segger one is nice for debugging, but afaik there is no command line tool available.
crossconnect from rowley was mentioned in another thread already but no idea if there is a command line tool available.
any other ideas?
Posted: Tue Dec 06, 2005 4:12 pm
The JTAG interface can be buffered using external IC buffers, this allows you to take care fo the distance issue. As for the interface, we rolled our own in an FPGA that we used for in-circuit test and programming of the finished devices. The JTAG will need 7 connections; pwr, gnd, rst, tms, tck, tdo, and tdi.
If your system is PC based then there are a number of options, starting as simple as the paralled based Wiggler interface, which you can build easily, all the way up to Data I/O or other simliar in-line JTAG interfaces.
Posted: Thu Dec 22, 2005 7:43 am
If you can stand the assinine 10 Second "Recovery" time, and can get to the TST pin, SAM-BA *IS* MOST DEFINITELY intended for PRODUCTION Programming. Read the datasheet. I have read this in the datasheet and several people from Atmel AMERICA have told me this IN PERSON while sitting in my office, AS RECENTLY AS LAST WEEK.
Having said that, if you use JTAG, the Segger "J-Flash" CAN be called from a command line. It still opens up it's GUI, but it DOES offer the ability to send several command-line arguments to it to open "projects" (which contain settings and such) and object "files", as well as erase, program, and verify SAM7Sxx devices. It even has a nifty "Auto" command that can be invoked by the command line, that can do an erase-program-verify operation in one step. When JFlash is called from a Command Line, it will return an "errorlevel" too upon exit, (the error return values are undocumented, but a "return" value of zero means "no error").
The only issue is if something goes wrong. If that happens, the app "stalls" while displaying a dialog box. If you can tolerate this behavior temporarily, I have contacted the U.S. office of Segger, and they assured me the understood that was a problem, and promised to fix it early in 2006.
Hope this helps, but DO NOT listen to the morons that CLAIM that SAM-BA is "unsuitable" for PRODUCTION programming. THAT IS *EXACTLY* WHAT IT *WAS* DESIGNED FOR.
Posted: Thu Dec 22, 2005 10:25 am
many thanks for your comment.
regarding the sam-ba there is a second drawback beside the tst pin.
pa0-2 have to be connected to vddio. as long as the pins are not used this is not a problem because the internal pull-up is active after reset. but if the pins are used this has to be observed.
Posted: Wed Dec 28, 2005 11:32 pm
gerhardf wrote:pa0-2 have to be connected to vddio. as long as the pins are not used this is not a problem because the internal pull-up is active after reset.
Are you shure? Reading doc6175 and searching for pa0 this is PGMEN0. Searching this second function I only find this in the context of testing and serial programming.
The Hardware constrains for SAM-BA over USB are summarized on page 140. This is:
- 18.432 MHz Quarz
- PIOA16 dedicated to the USB Pull-up
The USB-Pins should be connected, too. The pin constrains should be feasable for any application using the USB-Port. The quarz gives a hard constraint but you have the choice to use seperate serial line, too
Another alternative is to include a self-Program Routine into the main Application, then you are free.
Thanks for your remark.
Posted: Thu Dec 29, 2005 1:50 pm
the hints regarding pa0 to pa2 are not clearly mentioned in the datasheet.
but take a look on this page under getting started/sam-ba/prog and some further steps you will find a table which mentions pa0-2.
the reason for using several pax is, that wiwht different port setting different functions of the boot loader can be activated.
thanks to the internal pull-up and their behaviour after reset (active) only tst pin must be hold to vddio to activate sam-ba.