-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

I exchanged a couple of mails with Harald, and decided to post back a more complete report to the list because the issue is still unclear.

Was this the same before you tried erasing the flash and installing the SAM-BA loader? What exactly do you mean by "jumping VCC to test"? The device is normally USB powered, therer is no need for any additional voltage supply.

The state of the LEDs while in SAM-BA mode is undefined. However, 'faintly' might indicate a supply problem. Have you tried powering the board just from USB? Have you tried differen computers or an external USB hub?

If you applied external VCC, what kind of power supply were you using?

To clarify this point, I was just talking about jumping JP1 as instructed on SIMTrace/Firmware page. Please note that I did get a faint red LED while doing this.

All boards sold in the sysmocom webshop ship flashed + tested, so it should just have enumerated on USB upon connection.

When I received the device, I did not get any output from lsusb or dmesg when connecting it. I am working primarly on a recent T series Thinkpad. I opted to go down the SAM-BA / firmware flashing route.

This did not help the device show up on my machine. So I went to an Ubuntu base workstation, and surprisingly, the device showed up without any problem.

$ lsusb Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 004: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader $ dmesg [16867.212071] usb 4-2: new full speed USB device using uhci_hcd and address 4 [16867.375140] usbserial_generic 4-2:1.0: Generic device with no bulk out, not allowed. [16867.375152] usbserial_generic: probe of 4-2:1.0 failed with error -5 [16867.375199] usbserial_generic 4-2:1.1: generic converter detected [16867.375294] usb 4-2: generic converter now attached to ttyUSB0

When I plugged it back to my Arch laptop, I suddenly had the same output. But I was able to use sam7 to access the device. So I compiled all the software on Ubuntu and tried flashing from there.

$ sudo ./sam7 --exec set_clock --exec unlock_regions --exec "flash ../openpcd/firmware/main_simtrace.samba" [sudo] password for mathilda: can't open "/dev/at91_0": No such file or directory

Ok, let's go down the POSIX path:

$ sudo rmmod usbserial $ sudo modprobe usbserial vendor=0x03EB product=0x6124 $ sudo ./sam7 -l /dev/ttyUSB0 --exec set_clock --exec unlock_regions - --exec "flash ../openpcd/firmware/main_simtrace.samba" Page size info of not known $ sudo ./sam7 -l /dev/ttyUSB0 --exec set_clock --exec unlock_regions - --exec "flash ../openpcd/firmware/main_simtrace.samba" ^C

It just hangs there. I am stuck here, are there any tips on what I should do here? Sequence of operations? Other test commands? Should I, god forbid, try flashing it from a Windows workstation? I will end this post with strace output for the sam7 command:

$ sudo strace ./sam7 -l /dev/ttyUSB0 --exec set_clock --exec unlock_regions --exec "flash ../openpcd/firmware/main_simtrace.samba"

execve("./sam7", ["./sam7", "-l", "/dev/ttyUSB0", "--exec", "set_clock", "--exec", "unlock_regions", "--exec", "flash ../openpcd/firmware/main_s"...], [/* 15 vars */]) = 0 brk(0) = 0x8542000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb78ee000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=66517, ...}) = 0 mmap2(NULL, 66517, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb78dd000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libncurses.so.5", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\224\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=227864, ...}) = 0 mmap2(NULL, 231632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf69000 mmap2(0xf9f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x35) = 0xf9f000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libreadline.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\277\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=204860, ...}) = 0 mmap2(NULL, 212492, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xab4000 mmap2(0xae3000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2e) = 0xae3000 mmap2(0xae7000, 3596, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xae7000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@n\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1421892, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb78dc000 mmap2(NULL, 1427880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b3000 mmap2(0x40a000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x157) = 0x40a000 mmap2(0x40d000, 10664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40d000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\n\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=9736, ...}) = 0 mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x120000 mmap2(0x122000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x122000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb78db000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb78db6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0x122000, 4096, PROT_READ) = 0 mprotect(0x40a000, 8192, PROT_READ) = 0 mprotect(0xae3000, 4096, PROT_READ) = 0 mprotect(0xf9f000, 8192, PROT_READ) = 0 mprotect(0x804c000, 4096, PROT_READ) = 0 mprotect(0x448000, 4096, PROT_READ) = 0 munmap(0xb78dd000, 66517) = 0 open("/dev/ttyUSB0", O_RDWR) = 3 write(3, "N#", 2) = 2 nanosleep({0, 2000000}, NULL) = 0 read(3,

Thanks, Mat

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

try to enter the interactive mode and then issue the commands and see how far you get.

Good idea. Interestingly enough, the process hangs when launching the sam7 utility. I don't even get to the interactive command prompt.

There is something I don't fully understand in the documentation. It says on ubuntu the device is mapped on /dev/ttyACMx using the cdc_cam. If I rmmod cdc_cam, the sam7 utility cannot find /dev/at91_0. To make it work I have to symlink /dev/ttyACM0 to /dev/at91_0... How does the device get mapped to /dev/at91_0?

Trying to address with libusb this way, the strace ends with:

open("/dev/at91_0", O_RDWR) = 3 write(3, "N#", 2) = 2 nanosleep({0, 2000000}, NULL) = 0 read(3, "\n", 2) = 1 nanosleep({0, 2000000}, NULL) = 0 write(3, "wFFFFF240,4#", 12) = 12 nanosleep({0, 2000000}, NULL) = 0 read(3, "\n", 4) = 1 nanosleep({0, 2000000}, NULL) = 0 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77bb000 write(1, "Page size info of not known\n", 29Page size info of not known ) = 29 exit_group(1)

Trying to go down the POSIX path:

open("/dev/ttyUSB0", O_RDWR) = 3 write(3, "N#", 2) = 2 nanosleep({0, 2000000}, NULL) = 0 read(3, ^C

I also tried removing libusb before recompiling sam7, but this gives me the same output for POSIX.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

No idea, I have only used sam7util (from our git repository) with the posix mode and /dev/ttyACM0..as device. So the device is really in the SAM-BA state? Are you sure /dev/ttyACM0 is really coming from the SIMtrace?

Yes, according to Harald, if the device identifies as Atmel Corp. at91sam SAMBA bootloader when issuing lsusb, this confirms it is in SAM-BA state. I quickly tried the dfu-util, and it did not recognize any device.

I identified the hanging point to be at the very beginning of samba_init(void) in samba.ca. It stopped at the first if, never being able to read a response from the device.

The great news is, I finally flashed it! The second workstation I was working from was Ubuntu 10.10. This time, I tried on another Ubuntu 10.04 workstation, which is in a fairly fresh install state. I I installed dependencies to build the firmware: The arm-elf-toolchain from bsprak PPA, and most importantly (my guess is, this changed something), libusb-dev and NOT libusb-1.0.0-dev. This is might seem strange, but the installed packages are libusb-0.1-4 libusb-1.0.0 and libusb-dev. Maybe this is a meta package and I'm wrong...

After I ran strace on sam7 utility and it went much further, finally ending with something about USBDEVFS ressource busy. Simply rmmod cdc_acm and try again, et voila! Flashed! Device now boots with bright red LED and identifies as VOTI.

Clearly, this all had to do with the USB interface being picky about something. Maybe someone more knowledgeable can explain.

Thanks for all you help, Mat

Hi,

Excerpts from Mat's message of Mon Jan 30 19:37:16 +0100 2012:

There is something I don't fully understand in the documentation. It says on ubuntu the device is mapped on /dev/ttyACMx using the cdc_cam. If I rmmod cdc_cam, the sam7 utility cannot find /dev/at91_0. To make it work I have to symlink /dev/ttyACM0 to /dev/at91_0... How does the device get mapped to /dev/at91_0?

this is the output I got on Ubuntu when I did not installed libusb, or with the wrong version. Once the right version is installed, you have to recompile sam7utils (clean to be sure). Maybe you have/had the same error.

kevin

Mathieu Jolicoeur wrote:

I think I was getting stuck because by I had installed SIMtrace before sam7utils. This way, I had already installed libusb-1.0-0-dev, so sam7utils would compile with that base.

And since sam7utils has not yet been adapted to support libusb-1.0 it requires the libusb-dev package with the libusb-0.1 API.

Having only libusb-1.0-0-dev and not libusb-dev means that libusb-dev is not available, and that is the only libusb which sam7utils currently can use.

//Peter