Hi everyone. I'm having some experiences similar to Grant's http://dangerousprototypes.com/forum/index.php?topic=740.0 (http://http://dangerousprototypes.com/forum/index.php?topic=740.0) - just in Linux instead.
I decided to update the USB IR Toy to FW version 1.05 (just done updating my BP to fw 5.4) . I connected with screen and entered "$". after that, my /dev/ttyACM01 entry disapeared, and I got the HID device.
I read Grant's post, and the apparent solution - to plug it in several times, and hope for the mode to switch. so far I have had no luck. I havde tried rebooting, plugging the device into a "usb power outlet" - so that it should just power up, but wouldn't have an OS to interfere, plugging it into a windows 7 machine, but to no avail.
I even tried booting it up with a jumper on the PGD,PGC pins, waiting a while, and then disconnecting the device, removing the jumper and trying again. no luck.
I have included a dump from one of my attempts below. any suggestions would be much appreciated.
best regards,
Jonas
[font=courier:]root@flaptop:~# lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 029: ID 04d8:fd0b Microchip Technology, Inc.
Bus 003 Device 005: ID 046d:c313 Logitech, Inc.
Bus 003 Device 004: ID 046d:c525 Logitech, Inc.
Bus 003 Device 002: ID 058f:9254 Alcor Micro Corp. Hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@flaptop:~# fw_update -e -w -v -m all -vid 0x04D8 -pid 0xFD0B -ix USBIRToy.v1.05.hex
U2IO flash erasing: FAILED.
Device is not found.
Operation aborted.
root@flaptop:~# dmesg|tail
[ 3766.048104] usb 3-2: USB disconnect, address 27
[ 3766.060641] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 3766.060671] ftdi_sio 3-2:1.0: device disconnected
[ 3804.976094] usb 3-2: new full speed USB device using uhci_hcd and address 28
[ 3805.140739] usb 3-2: configuration #1 chosen from 1 choice
[ 3805.151538] generic-usb 0003:04D8:FD0B.0006: hidraw0: USB HID v1.01 Device [Diolan Diolan] on usb-0000:00:1d.1-2/input0
[ 4154.664107] usb 3-2: USB disconnect, address 28
[ 4159.120077] usb 3-2: new full speed USB device using uhci_hcd and address 29
[ 4159.283526] usb 3-2: configuration #1 chosen from 1 choice
[ 4159.297602] generic-usb 0003:04D8:FD0B.0007: hidraw0: USB HID v1.01 Device [Diolan Diolan] on usb-0000:00:1d.1-2/input0
root@flaptop:~# dmesg|tail
[ 4338.091712] usb 3-2: configuration #1 chosen from 1 choice
[ 4338.106918] generic-usb 0003:04D8:FD0B.000F: hidraw0: USB HID v1.01 Device [Diolan Diolan] on usb-0000:00:1d.1-2/input0
[ 4338.680113] usb 3-2: USB disconnect, address 37
[ 4340.160076] usb 3-2: new full speed USB device using uhci_hcd and address 38
[ 4340.329336] usb 3-2: configuration #1 chosen from 1 choice
[ 4340.343023] generic-usb 0003:04D8:FD0B.0010: hidraw0: USB HID v1.01 Device [Diolan Diolan] on usb-0000:00:1d.1-2/input0
[ 4341.408110] usb 3-2: USB disconnect, address 38
[ 4437.136088] usb 3-2: new full speed USB device using uhci_hcd and address 39
[ 4437.321047] usb 3-2: configuration #1 chosen from 1 choice
[ 4437.329585] generic-usb 0003:04D8:FD0B.0011: hidraw0: USB HID v1.01 Device [Diolan Diolan] on usb-0000:00:1d.1-2/input0
root@flaptop:~#[/font:]
I was playing with the IR Toy and sent "$$", and once in the bootloader I couldn't get the IR Toy out of it, even after I reconnected the IR Toy.
IR Toy Stopped Working (Firmware v1.04 bugs?)http://dangerousprototypes.com/forum/index.php?topic=770.msg7409#msg7409 (http://http://dangerousprototypes.com/forum/index.php?topic=770.msg7409#msg7409)
Some ideas ...
Me:
Is it really necessary to unplug/plug IR Toy when placing/removing the jumper?
Ian:
Yes, it is needed to reset the IR Toy to leave the bootloader and enter the main firmware. The exception to this is if you used the -run flag on the programmer and removed the jumper before programming finishes, then the bootloader will run the reset command and jump to the firmware.
The jumper goes between the PGC and PGD pins in the ICSP header, but in new IR Toys the header is missing, so just insert a temp header to short PGC & PGD, or short the contacts until you see the LED turn on/off.
UPDATE:
I tried flashing from my windows 7 machine, with the jumper set. Apparently it worked. I unplugged the jumper and checked the device. it is still registered as a HID device.
I then tried flashing it without the jumper. No Go. I then refitted the jumper and flashed it with fw 1.02 - Success again, and now when I plug it in to my linux box without a header, the LED is off, and I get the ACM port as expected:
[font=courier:][10963.992078] usb 3-2: new full speed USB device using uhci_hcd and address 59
[10964.177922] usb 3-2: configuration #1 chosen from 1 choice
[10964.180800] cdc_acm 3-2:1.0: This device cannot do calls on its own. It is not a modem.
[10964.180864] cdc_acm 3-2:1.0: ttyACM0: USB ACM device[/font:]
I then reconnected the header and upgraded to fw v 1.05 via the win7 machine. I must have compiled the fw_update utility wrong.
Oddly enough, the LED is still constantly on on the windows 7 machine.
I haven't tried to connect to the IR_toy with a terminal in windows 7 - that will be another day.
Hi Jonas - I'm sorry you're having a problem with the IR Toy. I thought the stuck bootloader problem was fixed in v1.05, but it looks like it's still giving us problems. Thanks for your report, it gave me enough data to identify what's going on (see below).
So I have to get a PiCkit to reflash the IR toy with 1.05 fw?
So far nobody has had to reflash the PIC to get it back, a simple upgrade over USB has been sufficient. Most people have downgraded back to 1.02, as described here:
http://dangerousprototypes.com/2010/07/ ... mware-bug/ (http://dangerousprototypes.com/2010/07/27/usb-ir-toy-v1-04-fimware-bug/)
I decided to update the USB IR Toy to FW version 1.05. I connected with screen and entered "$". after that, my /dev/ttyACM01 entry disapeared, and I got the HID device.
Was every upgrade unsuccessful? Did you get the same error shown above the first time you tried? Did you try to upgrade before this (was it at 'stock' 1.02 firmware)?
It seems like there's two problems. The first is that the IR Toy is stuck in the bootloader after the first jump to it. The second is that you cannot connect to the bootloader with the Linux application.
You mention that the production date is 29/04/2010 - how can you tell? When did you buy/receive this IR Toy?
My recommendation is to try to use the bootloader application under Windows, preferably Windows XP because Windows 7 is a non-stop headache for hardware devices.
--------------------------------------
Issue analysis:
I did think that there was a problem in firmware v1.04/1.05, but it looks like it's actually a problem jumping to the bootloader with $ and not clearing the bootloader EEPROM mark. I think if you don't complete an update after jumping with $ then the bootloader stays active. This is a safety measure to prevent a 'bricked' IR Toy.
The jump to bootloader ($) command goes to this instruction at 0x16 in the PIC flash:
http://code.google.com/p/dangerous-prot ... ors.asm#54 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/USBIRtoy/bootloader/firmware/vectors.asm#54)
Which runs the bootloader soft-reset. The soft resets writes a magic values to the first byte of the EEPROM and then resets:
http://code.google.com/p/dangerous-prot ... sm.asm#366 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/USBIRtoy/bootloader/firmware/boot_asm.asm#366)
Now any time the IR Toy is reset it looks for the EEPROM mark and enters the bootloader if it's 0x5a:
http://code.google.com/p/dangerous-prot ... ot.asm#131 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/USBIRtoy/bootloader/firmware/boot.asm#131)
The only way to clear the EEPROM mark is to successfully program the IR Toy and exit the bootloader with the -reset flag:
http://code.google.com/p/dangerous-prot ... sm.asm#331 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/USBIRtoy/bootloader/firmware/boot_asm.asm#331)
Which clears the EEPROM mark in the softreset routine:
http://code.google.com/p/dangerous-prot ... sm.asm#384 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/USBIRtoy/bootloader/firmware/boot_asm.asm#384)
Honesty I forgot that the jump to bootloader with $ was based on the EEPROM mark. I recalled removing all that, but I guess it was for the OLS (which has no EEPROM).
I guess
the bottom line is once you jump to the bootloader with $ you must complete an upgrade (or exit with the fw_update application) or it will stick in the bootloader. This is to prevent the IR Toy from being accidentally bricked. It would be hard to brick the IR Toy because you can always enter the bootloader by connecting the PGC and PGD pins. But some designs might use entry from the main program only (like with $), and if the main program is erased and not reprogrammed, then there would be no way to enter the bootloader again.
I think the reason we're seeing this now is that 1) there is a reason to upgrade, and 2) the latest batch of IR Toys is (finally) shipping without ICSP headers so $ is required. The EEPROM mark isn't made when entering with the jumper (magic happens here:)
http://code.google.com/p/dangerous-prot ... ot.asm#142 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/USBIRtoy/bootloader/firmware/boot.asm#142)
This is consistent with all reported cases so far. It effects the bootlaoder, not the firmware, and effects all releases. It is not an error, but a safety mechanism that might be a little too strong in practice. liyin entered $$, got to the bootloader, and couldn't get out. Similarly, JoSSte entered the bootloader with $, couldn't complete the upgrade, and now it's stuck. This could also explain Ralph's problem on v1.02 that seemed like a weird corner case (it doesn't help that some MAC terminals send $at.... commands on opening, as has been an issue with the Bus Pirate). It also explains why we never see this in the lab: 1) we enter with jumper and $ equally, depending on the task, but 2) we usually develop with a debugger, not bootloaded firmware, and 3)
we always complete a bootloader update after jumping to the bootloader...
I'm guessing this IR Toy will be rescued by completing an update to any firmware version. I'm not sure why it's not working on Linux, but I'd guess it's a separate 'problem' from the stuck bootloader.
Is this a generally acceptable issue analysis? I'll post it on the blog if we can confirm this case and nobody has strong objections.
This part summarizes it well:
I guess the bottom line is once you jump to the bootloader with $ you must complete an upgrade (or exit with the fw_update application) or it will stick in the bootloader. This is to prevent the IR Toy from being accidentally bricked. It would be hard to brick the IR Toy because you can always enter the bootloader by connecting the PGC and PGD pins. But some designs might use entry from the main program only (like with $), and if the main program is erased and not reprogrammed, then there would be no way to enter the bootloader again.
I think the reason we're seeing this now is that 1) there is a reason to upgrade, and 2) the latest batch of IR Toys is (finally) shipping without ICSP headers so $ is required.
Yup, this is entirely a poor support from Ian mistake, I'm sorry about that. I didn't help by back-porting the 18f24J50 version for development. The newer version of the bootloader uses a different jump technique and doesn't use the EEPROM mark, but that's not actually what's out there. I spent hours this week tracing through the code to see what could be wrong, and the version I used was the development version with no EEPROM mark. As soon as I looked at the google code version I realized (reluctantly) that the IR Toy uses the EEPROM mark. I swore that it didn't! I'm really sorry for the confusion.
Thanks to everyone who reported a problem, it's the only way we would have found the issue.
Hi Ian - thanks for the very detailed response. This has actually been kind of a nice learning experience.
Regarding the production date - It was stamped on a sticker on the bag I got the device in - I purchased it from a danish store who brought it home from seeed. (www.let-elektronik.dk (http://www.let-elektronik.dk)). I believe it was the second batch to ship (not entirely sure though).
With respect to the firmware upgrades; The only successful firmware upgrades were with the jumper attached to the header. And I believe that this was the first FW update I attempted. I don't remember having a reason to update it immediately after reception.
as I've written in my update - I have now got fw v. 1.05 and it seems to be working fine.
cheers
Jonas
Thanks Jonas - I'm glad you got it working. I didn't know anyone was reselling the IR Toy, that's great news.
I encountered the same problem with the latest firmware (v21). the computer (windows 7 ultimate 64x) refused to recognize the toy as com port and insisted on HID. the yellow LED was on. the only way out was to reload the firmware (without applying the short).
in a broader view, the card gives me lots of headache. even though I see it in the device manager as a com port, winlirc refuses to communicate with it. even if I manage to communicate, after a long session of voodoo steps including turning the computer off (really off), the connection is lost once the computer is waken from sleep.
Hi shmulik,
I'm sorry about the problems, thanks for the report. The new USB stack may have some problems with the suspend and waking from sleep, or maybe we didn't implement those features properly. You could try down grading to firmware v13 or so, it may be more stable for you.
I understand there is a new version of the USB stack coming eventually, it may solve some of these issues.