Linux SAM7S USB flash utility

Microchip in-system programming solution: SAM-BA

Moderators: nferre, fab

konkers
Posts: 25
Joined: Tue Dec 13, 2005 10:47 am

Linux SAM7S USB flash utility

Fri Dec 16, 2005 11:21 am

I've been working on a linux utility to flash a sam7s over usb. I have it working, however it uses a piece of atmel code which I got from analyzing SAM-BA's USB traffic. I plan on writing a piece of replacement code to replace that one. In a mean time here's the rest of the code release under the GPL.

EDIT: added manual_flash command which does not need samba.bin and is ~ 10x slower

Enjoy,
Erik
Last edited by konkers on Sat Dec 31, 2005 7:58 am, edited 1 time in total.
dmcintosh256
Posts: 8
Joined: Tue Nov 08, 2005 8:50 am

GPL'ed USB SAM7 Flasher

Thu Dec 22, 2005 7:16 am

Hi,

Thanx for the great utility!

Do you think this could be Ported to OS X?

Thanx,

-Doug
konkers
Posts: 25
Joined: Tue Dec 13, 2005 10:47 am

Re: GPL'ed USB SAM7 Flasher

Tue Dec 27, 2005 11:46 pm

dmcintosh256 wrote: Do you think this could be Ported to OS X?
The port of the utility should be simple. I have ignored endianess. I can't remember if OSX runs the PPC in big or little endian mode. If it run in big endian mode the code would have to be audited for endianess issues.

The only other part would be a USB driver. Doing this for linux was as easy as changing a couple lines in the usb_skeleton.c driver. The sam7 boot program uses one bulk in and one bulk out endpoint. I'd imagine Apple provides and example driver illustrating how to do this.

-Erik
twilmer
Posts: 4
Joined: Wed Dec 28, 2005 10:57 pm

AT91SAM7S64 connected via usb to Linux

Wed Dec 28, 2005 11:15 pm

Hello,

why is a new module needed?

module usbserial vendor=0x3eb product=0x6124

gives me a new Serial Device to my AT91SAM7S64 evaluation Board. I am able to connect via minicom. V# gives the Version. I am even able to write Data into the memory.


Page 137 of doc6175 gives a complete lists of commands which are available. Pages 100 to 114 describe the Flash interface which should be accessable via the SAM-BA, too.
I am currently writing a userspace program which should be able to write into flash. Writing into RAM works. It is not completed yet, it is not supposed to do any usefull yet. I have not erased the chip and I do no unlocking yet.

You and the original Program seem to upload a small flash routine into memory which does the actual programming. Why is this programm needed what is the advantage?

The SAM-BA Application runs from SRAM so flashing should be possible. Am I missing some timmings?

I like a solution which does not reuse any existing non-free binary blops. A simple user-Space application should also work via the Debug-Port and should be easily portable.

Best Regards


Thorsten Wilmer
konkers
Posts: 25
Joined: Tue Dec 13, 2005 10:47 am

Re: AT91SAM7S64 connected via usb to Linux

Wed Dec 28, 2005 11:43 pm

twilmer wrote:Hello,

why is a new module needed?

module usbserial vendor=0x3eb product=0x6124

gives me a new Serial Device to my AT91SAM7S64 evaluation Board. I am able to connect via minicom. V# gives the Version. I am even able to write Data into the memory.
I started using that, however I was having problems with incomplete reads. Instead of tracking down why that was happining, I addapted the usb_skeleton.c driver. I also like having a more deterministic node in /dev
twilmer wrote: Page 137 of doc6175 gives a complete lists of commands which are available. Pages 100 to 114 describe the Flash interface which should be accessable via the SAM-BA, too.
Unfortunately these commands do not seem to work as advertised. Specifically the S command does not wait for any data over USB before echoing '>' back.

Using a USB analyzer, I found that SAM-BA was issuing an undocumented N# command as soon as it connected. This switches the boot program into an undocumented binary command set.
twilmer wrote: You and the original Program seem to upload a small flash routine into memory which does the actual programming. Why is this programm needed what is the advantage?

The SAM-BA Application runs from SRAM so flashing should be possible. Am I missing some timmings?
I am doing this because my first step was to try to emulate SAM-BA as close a possible to establish a base line. I'm not sure why SAM-BA does this. It might be due to bugs in the boot program.
twilmer wrote: I like a solution which does not reuse any existing non-free binary blops. A simple user-Space application should also work via the Debug-Port and should be easily portable.
My intention is to re-implement SAM-BA's binary blob as a GPLed piece of code. I don't use the debug port in my development although I'd be happy to take a patch to add support. I also inted the code to be portable, however it's pretty POSIX heavy so a win32 port would either require cygwin or some real work.
twilmer
Posts: 4
Joined: Wed Dec 28, 2005 10:57 pm

Re: AT91SAM7S64 connected via usb to Linux

Thu Dec 29, 2005 10:02 am

konkers wrote: Unfortunately these commands do not seem to work as advertised. Specifically the S command does not wait for any data over USB before echoing '>' back.
There is a rather very short timout for the S command. The existence is documented but not the duration. If the Data are following then S works quite well. I have successfully written into the SRAM.
konkers wrote: Using a USB analyzer, I found that SAM-BA was issuing an undocumented N# command as soon as it connected. This switches the boot program into an undocumented binary command set.
Yes the N# command is undocumented. But the other commands used seem to be the same with the exception that S gives also the length of the Data to be sent. But this works without N#, too. I assume that N# switches of the '>' reply. As '>' is missing in the log.

Best regards,

Thorsten Wilmer


Input:
modprobe usbserial vendor=0x3eb product=0x6124
minicom -o my-config

V#
S202000,10#This is a very long sentence
R202000,15#

Everly line is pasted into minicom at once.

Output:

v1.4 Nov 10 2004 14:49:33
>
>
This is a very lN¢...>


cat /etc/minicom/minirc.my-config
# Machine-generated file - use "minicom -s" to change parameters.
pu port /dev/ttyUSB0
pu baudrate 115200
pu bits 8
pu parity N
pu stopbits 1
twilmer
Posts: 4
Joined: Wed Dec 28, 2005 10:57 pm

Re: AT91SAM7S64 connected via usb to Linux

Thu Dec 29, 2005 5:10 pm

Hello,

I have polished my current work and the communication via /dev/ttyUSB0 is now working realibly. This Program is able to Read the Version of the SAM-BA and is able to Read and Write Memory with a short string.

Best regards,
Thorsten Wilmer
konkers
Posts: 25
Joined: Tue Dec 13, 2005 10:47 am

Re: AT91SAM7S64 connected via usb to Linux

Thu Dec 29, 2005 9:42 pm

twilmer wrote: There is a rather very short timout for the S command. The existence is documented but not the duration. If the Data are following then S works quite well. I have successfully written into the SRAM.
I tried different amounts of time between sending the S command and the data. I hadn't however tried setting a length before going the N# route.
twilmer wrote: Yes the N# command is undocumented. But the other commands used seem to be the same with the exception that S gives also the length of the Data to be sent. But this works without N#, too. I assume that N# switches of the '>' reply. As '>' is missing in the log.
The N# command does more than that, it changes the response of of the commands from ascii to binary mode. The commands are still issued as ascii strings however thier responses are in binary. It looks like, according to your log bellow, the S and R commands are unaffected by the N# command and always use the binary form (and no Xmodem) when in USB mode.

-Erik
pjs
Contact:
Posts: 16
Joined: Wed Apr 27, 2005 8:06 pm

Fri Dec 30, 2005 3:43 am

I finally got my linux-based code working to program the flash. So far, serial only, not USB. Made a quick-n-dirty web page, if you want to download the code.

Here it is:

http://www.pjrc.com/arm/sam7_pgm/

100% GPL... has twice successfully programmed a tiny led_blink.hex file onto my AT91SAM7S64 board. Haven't done other testing yet... bugs still quite possible, so use with caution.
konkers
Posts: 25
Joined: Tue Dec 13, 2005 10:47 am

Fri Dec 30, 2005 3:55 am

pjs wrote:I finally got my linux-based code working to program the flash. So far, serial only, not USB. Made a quick-n-dirty web page, if you want to download the code.

Here it is:

http://www.pjrc.com/arm/sam7_pgm/

100% GPL... has twice successfully programmed a tiny led_blink.hex file onto my AT91SAM7S64 board. Haven't done other testing yet... bugs still quite possible, so use with caution.
This is neat.... it proves that you can write the flash w/o uploading code to do the job. I wonder if you can use the S command to fill the flash buffer.

-Erik
pjs
Contact:
Posts: 16
Joined: Wed Apr 27, 2005 8:06 pm

Fri Dec 30, 2005 4:16 am

konkers wrote: This is neat.... it proves that you can write the flash w/o uploading code to do the job. I wonder if you can use the S command to fill the flash buffer.

-Erik
Just tried it, and yes, it seems to also work.

On USB, I'd imagine either way would be similar. At only 115200 baud, programming 256k is going to be slow no matter what you do, but using xmodem rather than ascii hex and lots of command/reply sequences seems like a good thing.
konkers
Posts: 25
Joined: Tue Dec 13, 2005 10:47 am

Sat Dec 31, 2005 8:02 am

pjs wrote: Just tried it, and yes, it seems to also work.

On USB, I'd imagine either way would be similar. At only 115200 baud, programming 256k is going to be slow no matter what you do, but using xmodem rather than ascii hex and lots of command/reply sequences seems like a good thing.
Unfortunately it looks like writing to the flash buffer using the S$ command does not work over USB. The boot program probably uses byte writes as the MSB of the word is repeated throughout the whole word. I added a manual_flash command to my program which uses W# command to write to the flash buffer (updated above). It's ~ 10 times slower however. I guess this explains why SAM-BA uploads it's own code.

-Erik
pjs
Contact:
Posts: 16
Joined: Wed Apr 27, 2005 8:06 pm

Sat Dec 31, 2005 9:13 am

Erik,

I did make an attempt at uploading and running some code. I never did get it to work, but it's in there if you want to try to use/fix it. It does (or attempts to do) exactly the same thing those many write word commands do. The code is in flasher.armasm. It's well commented. There's some lines in the makefile to turn it into flasher.c and flasher.h, which defines the raw bytes to load into the SAM7's memory. I commented out the code in main() that uploads it, writes its params and then runs it.

My 30 day eval for IAR expired... else I'd use the jtag to set a breakpoint on 0x0020290 and then step through it to see what's really happening when it runs. Maybe I could get another 30 days somehow? I'm pretty sure that code is close to working. It's really very simple, only 24 ARM assembly instructions.

Anyway, doing it slowly with the word writes is a lot better than no GPL'd linux-based code at all !!


- Paul
konkers
Posts: 25
Joined: Tue Dec 13, 2005 10:47 am

Sat Dec 31, 2005 2:31 pm

pjs wrote: My 30 day eval for IAR expired... else I'd use the jtag to set a breakpoint on 0x0020290 and then step through it to see what's really happening when it runs. Maybe I could get another 30 days somehow? I'm pretty sure that code is close to working. It's really very simple, only 24 ARM assembly instructions.
I have access to a BDI2000. I'll see if I can make sense of what's going on.

-Erik
gerhardf
Posts: 554
Joined: Thu Dec 02, 2004 2:28 pm

Sun Jan 01, 2006 12:03 pm

pjs wrote:Erik,

My 30 day eval for IAR expired... else I'd use the jtag to set a breakpoint on 0x0020290 and then step through it to see what's really happening when it runs. Maybe I could get another 30 days somehow? I'm pretty sure that code is close to working. It's really very simple, only 24 ARM assembly instructions.
- Paul
hello paul,
you can use the kickstart version of ewarm. you can donwload it from here:
http://supp.iar.com/Download/SW/?item=EWARM-KS32

regards
gerhard

Return to “SAM-BA”

Who is online

Users browsing this forum: No registered users and 1 guest