-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hello,
I have a v1.1p production board, and I am having problems getting started. I am running Arch Linux, so some things may be different from a Debian base. I have not yet tried interfacing the board from a Ubuntu/Debian workstation.
I have succesfully compiled SIMtrace and its dependencies. The problem is at no point have I gotten a connection to the board. dmesg shows nothing and lsusb never shows the device. I have libusb configured on this system and programmed other avr devices.
I tried to access the board with SAM-BA by following the firmware page. I only see the red LED faintly light when I'm jumping VCC to test, but nothing once I reconnect USB. I am right to assume that with a newly acquired board, I have to flash it with the firmware?
Do you have any clues to help me talk to the SIMTrace board? I haven't found much explanation of bootloader and reset buttons on the wiki... Should I simply try with and Ubuntu/Debian workstation?
Thanks, Mat
Hi Mat!
On Sat, Jan 28, 2012 at 09:50:41PM -0500, Mat wrote:
I tried to access the board with SAM-BA by following the firmware page.
This should not (have been / be) neccessarry. But once you have tried to erase the unit and install SAM-BA from rom, your only recovery option is SAM-BA, as the simtrace firmware and the bootloader have been erased :/
I only see the red LED faintly light when I'm jumping VCC to test, but nothing once I reconnect USB.
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?
I am right to assume that with a newly acquired board, I have to flash it with the firmware?
All boards sold in the sysmocom webshop ship flashed + tested, so it should just have enumerated on USB upon connection.
I presume there was no visible mechanical damage to the unit upon arrival? Are you able to take a sharp photograph with good resolution and mail it privately to me? I just want to rule out any obvious hardware damage during shipping.
Regards, Harald
-----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
On 01/30/2012 03:40 AM, Mat wrote:
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"
Hi,
try to enter the interactive mode and then issue the commands and see how far you get.
holger
-----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.
On 01/30/2012 07:37 PM, Mat wrote:
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?
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?
holger
-----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
Mat wrote:
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...
libusb-0.1 and libusb-1.0 are different APIs for doing the same thing; accessing USB devices. They are incompatible, meaning that they can not be used interchangeably. Ie. a program built for 0.1 can not use 1.0 directly. This also means that both can be installed at the same time, since they provide different things. There is additionally the libusb-compat-0.1 package which uses the 1.0 API and provides the 0.1 API. Using this is generally more desirable than using the original 0.1 package, but it's not a huge deal.
I guess that sam7util uses the old API so you would need libusb-dev in order to build it. But the 0.1 files have literally not changed in years so Ubuntu 10.04 or 10.10 makes no difference.
After I ran strace on sam7 utility and it went much further, finally ending with something about USBDEVFS ressource busy.
A USBDEVFS message confirms that libusb is being used.
On the contrary, the strace output you provided for "libusb" mode and "POSIX" mode were identical, and both clearly showed that libusb was *not* being used.
Also note that Holger's point of making sure that you are using the correct ttyACM device is quite valid. Just because you see SAM-BA in lsusb does not mean that this piece of hardware will be ttyACM0. It might just as well be ttyACM1 or ttyACM2 or... Your strace output did however show a reply to N# on ttyACM0, indicating that indeed this was the correct port.
Clearly, this all had to do with the USB interface being picky about something. Maybe someone more knowledgeable can explain.
It's impossible to say anything without further analysis. The data you sent does not allow drawing a conclusion.
I'm glad that the device works now.
//Peter
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On the contrary, the strace output you provided for "libusb" mode and "POSIX" mode were identical, and both clearly showed that libusb was *not* being used.
I think this is important to note for future reference.
It's impossible to say anything without further analysis. The data you sent does not allow drawing a conclusion.
Thanks for your input Peter, you are right for saying we can't draw a conclusion from this. I understand now the different bases for libusb.
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.
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. This might be important to clarify. Hopefully, this can be useful in the future.
All the best, Mat
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