Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#11 XU1541 not recognized

open
5
2014-08-21
2012-02-19
shendriks
No

Hi,

I'm having trouble with my XU1541. I was able to successfully install the bootloader. I can also install the firmware via USB. But once the firmware is installed, the device is no longer recognized.

root@nebuchadnezzar:/home/sven# uname -a
Linux nebuchadnezzar 3.0.0-15-generic #26-Ubuntu SMP Fri Jan 20 15:59:53 UTC 2012 i686 i686 i386 GNU/Linux

When I connect the XU1541 in bootloader mode, I get:

root@nebuchadnezzar:/home/sven# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 006: ID 0403:c632 Future Technology Devices International, Ltd

I can flash the firmware via USB:

./update_tool/xu1541_update ./firmware/firmware.hex
-- XU1541 flash updater --
-- (c) 2007 by the opencbm team --
-- http://www.harbaum.org/till/xu1541 --
Device reports BIOS version 1.15.
Device reports: No firmware available.
Device reports capabilities 0x4000.
Device is in bootloader mode.
Uploading 92 pages starting from 0x0000
............................................................................................ done
If you had installed a jumper switch, please remove it and replug the USB cable
to return to normal operation!
If not, the xu1541 will reboot itself automatically.

But when I reboot the XU1541 device, I only get this:

root@nebuchadnezzar:/home/sven/git/opencbm/xu1541# dmesg | tail
[ 507.688058] usb 3-2: device descriptor read/64, error -71
[ 507.952074] usb 3-2: device descriptor read/64, error -71
[ 508.168056] usb 3-2: new low speed USB device number 14 using uhci_hcd
[ 508.288056] usb 3-2: device descriptor read/64, error -71
[ 508.512056] usb 3-2: device descriptor read/64, error -71
[ 508.728055] usb 3-2: new low speed USB device number 15 using uhci_hcd
[ 509.136072] usb 3-2: device not accepting address 15, error -71
[ 509.248058] usb 3-2: new low speed USB device number 16 using uhci_hcd
[ 509.656071] usb 3-2: device not accepting address 16, error -71
[ 509.656110] hub 3-0:1.0: unable to enumerate USB device on port 2

Any ideas?

Thanks
Sven

Discussion

  • Hello Sven,

    some questions:

    1. After flashing the bootloader, how does the XU1541 behave? Especially look at the LED after you plug it in.

    2. Did you flash the exact .HEX files that are in git, or did you compile your own ones? (Some avr-gcc versions generate code that will not fit into the xu1541 as it is intended).

    3. After the firmware has been flashed (and the device does not respond anymore on the USB bus), does installing the jumper resurrect the bootloader? Can you flash the firmware again afterwards?

    4. Spiro

     
  • shendriks
    shendriks
    2012-02-21

    Hi Spiro,

    thanks for your response. I did not flash the exact .hex files, I indeed used self-compiled ones. Using the .hex files from the git repository makes it work! The device is still recognised with the firmware flashed. Thanks a lot for this hint.

    However, I'm now struggling with accessing a floppy disk. I have a 1541-II connected to the xu1541. Some commands work, others do not.

    For example, this works:

    sven@slartibartfast:~/git/opencbm/opencbm/LINUX$ cbmctrl status 8
    73,cbm dos v2.6 1541,00,00
    sven@slartibartfast:~/git/opencbm/opencbm/LINUX$ cbmctrl status 8
    00, ok,00,00

    But when I try to list the directory of a floppy disk, the drive will spin up, and then the command hangs:

    sven@slartibartfast:~/git/opencbm/opencbm/LINUX$ cbmctrl dir 8

    I see this in /var/log/kern.log:

    Feb 21 23:15:19 slartibartfast kernel: [55203.092373] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd cbmctrl rqt 160 rq 13 len 2 ret -110
    Feb 21 23:15:19 slartibartfast kernel: [55203.131351] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd cbmctrl rqt 160 rq 13 len 2 ret -71
    Feb 21 23:15:19 slartibartfast kernel: [55203.172108] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd cbmctrl rqt 160 rq 13 len 2 ret -71
    Feb 21 23:15:20 slartibartfast kernel: [55203.212067] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd cbmctrl rqt 160 rq 13 len 2 ret -71
    Feb 21 23:15:20 slartibartfast kernel: [55203.250902] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd cbmctrl rqt 160 rq 13 len 2 ret -71
    Feb 21 23:15:20 slartibartfast kernel: [55203.289751] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd cbmctrl rqt 160 rq 13 len 2 ret -71
    Feb 21 23:15:20 slartibartfast kernel: [55203.328617] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd cbmctrl rqt 160 rq 13 len 2 ret -71
    Feb 21 23:15:20 slartibartfast kernel: [55203.367480] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd cbmctrl rqt 160 rq 13 len 2 ret -71
    Feb 21 23:15:20 slartibartfast kernel: [55203.406345] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd cbmctrl rqt 160 rq 13 len 2 ret -71
    Feb 21 23:15:20 slartibartfast kernel: [55203.445335] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd cbmctrl rqt 160 rq 13 len 2 ret -71
    Feb 21 23:15:20 slartibartfast kernel: [55203.484287] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd cbmctrl rqt 160 rq 13 len 2 ret -71
    Feb 21 23:15:20 slartibartfast kernel: [55203.523251] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd cbmctrl rqt 160 rq 13 len 2 ret -71
    Feb 21 23:15:20 slartibartfast kernel: [55203.562225] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd cbmctrl rqt 160 rq 13 len 2 ret -71

    "cbmctrl detect" also hangs. I've tried d64copy as well:

    sven@slartibartfast:~/git/opencbm/opencbm/LINUX$ d64copy -v -v -v -t s1 -d 1541 8 ~/test.d64
    [Debug] transfer mode is 2
    [Debug] decided to use transfer mode 2
    [Info] drive 08 (1541): 00, OK,00,00
    USB error xu1541_write(): error sending control message: Broken pipe

    from /var/log/kern.log:

    Feb 21 23:17:37 slartibartfast kernel: [55340.483489] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd d64copy rqt 160 rq 13 len 2 ret -110
    Feb 21 23:17:37 slartibartfast kernel: [55340.522350] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd d64copy rqt 160 rq 13 len 2 ret -71
    Feb 21 23:17:37 slartibartfast kernel: [55340.561204] usb 2-1.6: usbfs: USBDEVFS_CONTROL failed cmd d64copy rqt 160 rq 13 len 2 ret -71

    I've also tried multiple floppy disks - no luck. All can be read OK from a real C64.

    Thanks a lot
    Sven

     
  • Hello,

    sorry for the late reply.

    What makes me wonder is the word "USBFS" in the logs.

    In the xu1541/misc/ directory, there is the usb_echo_test.c file. Can you build that one and post the output of the program? It tests some general communication between PC and XU1541 and it might tell us about some problem of the communication.

    Regards,
    Spiro

     
  • shendriks
    shendriks
    2012-03-01

    Hi Spiro,

    here's the output from usb_echo_test:

    sven@slartibartfast:~/git/opencbm/xu1541/misc$ ./usb_echo_test
    -- XU1541 USB test application --
    -- (c) 2007 the opencbm team --
    -- http://www.harbaum.org/till/xu1541 --
    -- http://sourceforge.net/projects/opencbm --
    Device reports BIOS version 2.15.
    Device reports firmware version 1.18.
    Device reports capabilities 0x00f7.
    Device is not in bootloader mode.
    === Running standard echo test ===
    256 echo test transmissions successful!
    === Running irq disabled echo test ===
    GOOD: No error sending control message.
    USB errors may (and even should) be reported in the following lines.
    Expected error: error sending control message: Broken pipe!
    Expected error: error sending control message: Broken pipe!
    Expected error: error sending control message: Broken pipe!
    Expected error: error sending control message: Broken pipe!
    Echo successful
    Echo successful
    Echo successful
    Echo successful
    Echo successful
    Echo successful
    USB timeout states: 4
    GOOD: Device/USB link successfully recovered from disabled target irq

    Sven

     
  • (Un-)fortunately, this looks exactly as it should.

    This is good as it tells us that the USB communication works stable, at least partially. This is bad as it makes it harder to find out what is going on.

    Could you please test a program with settings XU1541_DEBUG, i.e.,

    XU1541_DEBUG cbmctrl dir 8

    and giving the output here?

    Note: If cbmctrl has problems, d64copy and cbmcopy are very unlikely to work at all. We must fix cbmctrl before we can try with the other tools.

    What about the tools "morse" and "flash"? Do these work?

    You could also try a

    cbmctrl download 8 0xff00 0x100 file1.bin

    If this works and gives you a file "file1.bin" with 256 bytes, then please also try

    cbmctrl download 8 0xc000 0x4000 1541.bin (if you are using a 1541 floppy)
    cbmctrl download 8 0x8000 0x8000 1571.bin (if you are using a 1570 or 1571 floppy)

    and send me the file 1541.bin or 1571.bin you get. (This command dumps the ROM contents. This way, I can find out if

    1. the transfer itself works, as the command does not involve a disk, and
    2. if you have a customized firmware ROM. These might make problems in some rare cases.

    3. Spiro

     
  • shendriks
    shendriks
    2012-03-05

    Hi Spiro,

    here's what I've tried:

    sven@slartibartfast:~/git/opencbm$ export XU1541_DEBUG=1

    sven@slartibartfast:~/git/opencbm$ cbmctrl dir 8
    [XU1541] Scanning usb ...
    [XU1541] Scanning bus 002
    [XU1541] Device 0403:c632 at 066
    [XU1541] Found xu1541 device on bus 002 device 066.
    [XU1541] firmware version 1.18
    [XU1541] ioctl 7 for device 8, sub 0
    [XU1541] write 2 bytes from address 0x7ffff2200ff0
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] ioctl 3 for device 8, sub 15
    [XU1541] read 38 bytes to address 0x7ffff2201000
    [XU1541] ioctl 5 for device 0, sub 0
    [XU1541] ioctl 3 for device 8, sub 0
    [XU1541] read 2 bytes to address 0x7ffff2201000
    [XU1541] read 2 bytes to address 0x7ffff2201000
    [XU1541] read 2 bytes to address 0x7ffff2201000
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    0 ."10108 seite a " 64'er
    [XU1541] read 2 bytes to address 0x7ffff2201000
    [XU1541] read 2 bytes to address 0x7ffff2201000
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff
    [XU1541] read 1 bytes to address 0x7ffff2200fff

    [then hangs]

    sven@slartibartfast:~/git/opencbm/opencbm/demo/morse$ ./morse
    [XU1541] Scanning usb ...
    [XU1541] Scanning bus 002
    [XU1541] Device 0403:c632 at 070
    [XU1541] Found xu1541 device on bus 002 device 070.
    [XU1541] firmware version 1.18
    [XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 6 bytes from address 0x7fffe1ced150
    [XU1541] write 32 bytes from address 0x601060
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 6 bytes from address 0x7fffe1ced150
    [XU1541] write 32 bytes from address 0x601080
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 6 bytes from address 0x7fffe1ced150
    [XU1541] write 32 bytes from address 0x6010a0
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 6 bytes from address 0x7fffe1ced150
    [XU1541] write 32 bytes from address 0x6010c0
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 6 bytes from address 0x7fffe1ced150
    [XU1541] write 20 bytes from address 0x6010e0
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 6 bytes from address 0x40096c
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] Closing USB link

    sven@slartibartfast:~/git/opencbm/opencbm/demo/flash$ ./flash
    [XU1541] Scanning usb ...
    [XU1541] Scanning bus 002
    [XU1541] Device 0403:c632 at 074
    [XU1541] Found xu1541 device on bus 002 device 074.
    [XU1541] firmware version 1.18
    [XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 6 bytes from address 0x7fff437c5450
    [XU1541] write 32 bytes from address 0x601060
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 6 bytes from address 0x7fff437c5450
    [XU1541] write 21 bytes from address 0x601080
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 3 bytes from address 0x4008bc
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] Closing USB link

    [Green floppy LED flashing smoothly]

    sven@slartibartfast:~/git/opencbm/opencbm/demo/morse$ cbmctrl download 8 0xff00 0x100 file1.bin
    [XU1541] Scanning usb ...
    [XU1541] Scanning bus 002
    [XU1541] Device 0403:c632 at 113
    [XU1541] Found xu1541 device on bus 002 device 113.
    [XU1541] firmware version 1.18
    o[XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 7 bytes from address 0x7fffd64e7d40
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] ioctl 3 for device 8, sub 15
    [XU1541] read 256 bytes to address 0x7fffd64e7dd0
    [XU1541] read 1 bytes to address 0x7fffd64e7d3f
    A transfer error occurred!

    [turning xu1541 off and on again a few times]

    sven@slartibartfast:~/git/opencbm/opencbm/demo/morse$ cbmctrl download 8 0xff00 0x100 file1.bin
    [XU1541] Scanning usb ...
    [XU1541] Scanning bus 002
    [XU1541] Device 0403:c632 at 121
    [XU1541] Found xu1541 device on bus 002 device 121.
    [XU1541] firmware version 1.18
    o[XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 7 bytes from address 0x7fff638731a0
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] ioctl 3 for device 8, sub 15
    [XU1541] read 256 bytes to address 0x7fff63873230
    [XU1541] read 1 bytes to address 0x7fff6387319f
    [XU1541] ioctl 5 for device 0, sub 0
    [XU1541] Closing USB link

    sven@slartibartfast:~/git/opencbm/opencbm/demo/morse$ hd file1.bin
    00000000 e9 ad 02 02 c9 2d f0 05 38 e9 2b d0 da 85 23 60 |.....-..8.+...#| 00000010 8e 03 18 a9 02 8d 00 18 a9 1a 8d 02 18 4c a7 ea |.............L..| 00000020 ad 00 18 29 01 d0 f9 a9 01 8d 05 18 4c df e9 a9 |...)........L...| 00000030 ff 85 51 4c c6 c8 85 ff 4c 00 c1 c9 02 90 07 c9 |..QL....L.......| 00000040 0f f0 03 4c 6b d3 4c 73 d3 78 a2 45 9a 4c 25 eb |...Lk.Ls.x.E.L%.| 00000050 2c 01 18 4c 5b e8 bd ff 00 60 a6 7f bd ff 00 4c |,..L[.........L|
    00000060 1b f0 a9 00 9d ff 00 4c b7 c1 98 9d ff 00 4c 64 |.......L......Ld|
    00000070 c6 95 1c 9d ff 00 4c 75 d0 aa aa aa aa aa aa aa |......Lu........|
    00000080 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |................|
    *
    000000e0 aa aa aa aa aa eb c6 c8 8f f9 5f cd 97 cd 00 05 |.........._.....|
    000000f0 03 05 06 05 09 05 0c 05 0f 05 01 ff a0 ea 67 fe |..............g.|
    00000100

    sven@slartibartfast:~/git/opencbm/opencbm/demo/morse$ cbmctrl download 8 0xc000 0x4000 1541.bin
    [XU1541] Scanning usb ...
    [XU1541] Scanning bus 002
    [XU1541] Device 0403:c632 at 082
    [XU1541] Found xu1541 device on bus 002 device 082.
    [XU1541] firmware version 1.18
    .,[XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 7 bytes from address 0x7fff34bc1220
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] ioctl 3 for device 8, sub 15
    [XU1541] read 256 bytes to address 0x7fff34bc12b0
    [XU1541] read 1 bytes to address 0x7fff34bc121f
    [XU1541] ioctl 5 for device 0, sub 0
    ;[XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 7 bytes from address 0x7fff34bc1220
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] ioctl 3 for device 8, sub 15
    [XU1541] read 256 bytes to address 0x7fff34bc12b0

    [then hangs]

    sven@slartibartfast:~/git/opencbm/opencbm/demo/morse$ cbmctrl download 8 0xc000 0x4000 1541.bin
    [XU1541] Scanning usb ...
    [XU1541] Scanning bus 002
    [XU1541] Device 0403:c632 at 085
    [XU1541] Found xu1541 device on bus 002 device 085.
    [XU1541] firmware version 1.18
    .,[XU1541] ioctl 4 for device 8, sub 15
    [XU1541] write 7 bytes from address 0x7fffd59c03f0
    [XU1541] ioctl 6 for device 0, sub 0
    [XU1541] ioctl 3 for device 8, sub 15
    [XU1541] read 256 bytes to address 0x7fffd59c0480
    [XU1541] read 1 bytes to address 0x7fffd59c03ef
    A transfer error occurred!
    [XU1541] Closing USB link

    Unfortunately, I wasn't able to download the ROM from the 1541 (it is a 1541-II btw, if that matters.)

    Sven

     
  • Hallo again,

    I see, this seems not to be so simple.

    I see that you are using the usbtiny version of the bootloader ("BIOS-Version: 2.15"). Did you also try to avrusb one? The avrusb one has been tested more thoroughly, and your problem might be related to it.

    At least, the outputs indicate to me that we have a USB communication problem.

    BTW: You do not - by any chance - use a 64 bit version of linux?

    • Spiro
     
  • shendriks
    shendriks
    2012-03-20

    Yes, I tried both USB libs. And yes I do have a 64bit Linux. Is this a problem? I'm gonna try with a 32bit Linux as soon as I find one.

    Sven

     

  • Anonymous
    2012-05-29

    Hi. I am having the same problem, apparently.

    I build a XU1541 on a breadboard, checked out the git repository and uploaded the bootloader (avrusb) into the XU1541. Bootloader is working and responsive. I can run "make update-firmware" and the updater successfully puts the firmware onto the device (LED goes off after like a second after upload). However, as soon as there is a firmware on the device, it is not recognized by Linux any more:
    May 29 19:50:55 xerxes [42308.936794] usb 5-2: new low speed USB device using ohci_hcd and address 50
    May 29 19:50:55 xerxes [42309.076048] usb 5-2: device descriptor read/64, error -62
    May 29 19:50:56 xerxes [42309.320793] usb 5-2: device descriptor read/64, error -62
    May 29 19:50:56 xerxes [42309.560793] usb 5-2: new low speed USB device using ohci_hcd and address 51
    May 29 19:50:56 xerxes [42309.700791] usb 5-2: device descriptor read/64, error -62
    May 29 19:50:56 xerxes [42309.944048] usb 5-2: device descriptor read/64, error -62
    May 29 19:50:56 xerxes [42310.184051] usb 5-2: new low speed USB device using ohci_hcd and address 52
    May 29 19:50:57 xerxes [42310.592042] usb 5-2: device not accepting address 52, error -62
    ...

    The bootloader is still intact, If I place the jumper from GND to MISO, I can access it again.

    Long story short: if there is a firmware on the device, USB does not seem to work for me

    32 Bit Linux, Linux xerxes 2.6.32-41-generic #89-Ubuntu SMP Fri Apr 27 22:22:09 UTC 2012 i686 GNU/Linux
    gcc version 4.3.4

    Anything I could try to debug this?

    Regards, Frank

     
  • @Frank: The same question as I had for Sven: Did you use the pre-built .hex files for bootloader and firmware, or did you use self-compiled ones? It seems the files are very picky about the compiler, thus, using another version of avr-gcc will make them fail to work.

    @Sven: Did the behaviour change somehow recently? Did you have a possibility to test anymore?

     

  • Anonymous
    2012-12-02

    Hello,
    I have the same problem: when using the precompiled bootloader (bootldr-avrusb.hex) all works fine (flash, update, etc), but when i try to use a compiled version of bootloader (without any changes of code) after the firmware is flashed (using update_1541 tool) the led goes off, but the device is not recognized.

    I'm' using gcc 4.5.3 and avr-gcc 4.3.5 under natty 32 bit.
    I tired also with win-avr (gcc 3.x) with the same result.

    note: the build version of firmware works, only the bootloader has problem.

    regards, Marco

     

  • Anonymous
    2012-12-02

    Hello,
    I have the same problem: the precompiled bootldr-avrusb.hex works fine, but when try to use a re-compiled version (without any changes of code) after flashed the firmware with xu1541_update the led goes off but the the device it is not recognized.

    I'm using gcc 4.5.3. and avr-gcc 4.3.5. under natty 32 bit
    I'm also tryed win-avr (gcc 3.x) with the same result.

    Note: recompiled firmware.hex works!

    regards, Marco

     
  • @Marco: It is know that the bootloader/firmware is very picky about the compiler used to compile it.

    In the GIT repository, there is the file xu1541/misc/install_avr_gcc.sh which I used to build up my toolchain. It uses gcc 4.1.2 and avr-libc-1.4.6. I know from reports that later version of gcc do not work.

    I have had a look in some compiled versions. IIRC, all of them were bigger than with gcc 4.1.2. The problem is, the bootloader uses almost all bytes that it has (in fact, it uses more bytes than there are available for it, so it is split into two parts). Never gcc (I have had reports about 4.2.x and 4.3.x) tend to generate bigger code, that's the reason why the bootloader does not work with these.

    The firmware is not so picky, as there is much more room left, so wasting the one or the other byte does not harm it.

    I have not had time to try to build the bootloader with a newer gcc. I still hope that the above script still works (that is, the download locations are still valid.)
    If not, I have made local copies, so I could provide the necessary files.

    HTH,
    Spiro

     

  • Anonymous
    2012-12-03

    @SPiro: thanks for your reply.
    I tryed to build the toolchain (there are some misspell: md5 for some archive, etc), but finally I got the correct build system.

    Now the recompiled bootloader works!

    Thank you very much.

    Marco from Italy :)

     


Anonymous


Cancel   Add attachments