After a day or two, the IR Toy just stopped working. LED doesn't light anymore when you turn on the PC.
same... stopped working today... let me know if you find the solution. Is it a wipe and new firmware?
I upgraded the firmware to 1.04 to try the new sampling mode and was working fine yesterday, but today is dead.
Didn't change anything since.
To better understand what is going on here, can you tell us when you received your IRToys or even better on what date Seeed shipped the IRToys that are failing now?
A more precise description of 'dead/doesn't work' is also helpfull...:
- Does the OS recognize the irtoy?
- does another USB port help?
- is the USB port ok?
- reinstall of drivers?
- IR led defect?
- bootloader intact?
I received it last Friday, was bought from the last batch at the beginning of July (that long it takes to arrive), and passed the self-test.
It was working with firmware 1.02 on Friday, it was working with firmware 1.04 on Saturday, on Sunday it wouldn't turn on, no blinking and no connection to PC.
- USBIRtoy (CDC-232) is not connected, FT232R USB UART is not connected.
- Switching ports makes no difference.
- Ports work for MIDI keyboard, mouse, etc.
- Reinstalled FTDI driver, no difference.
- Is not LED defect, if it were it would still communicate with PC.
- Hard to know when there's no connection/communication with PC.
I believe if you connect pgc and pgd the bootloader becomes active.
It would be easier if IR Toys came with a ICSP header, how expensive could it be to solder a 5 pin male header?
Note:
PGC & PGD don't need to stay shorted.
I downloaded the 1.04 firmware again, bootloader was fine, any ideas what caused the firmware to stop working?
So you could short pgc and pgd withoout the header? :P
I assume a glitch (stackover/underflow? bad pointer?) that triggers a part of bootloader which writes or erase a page. Any chance that you got the contents from the chip before reflashing? Do you have a pic programmer capable of programming the pic inside the irtoy? Just in case it happens again?
I wrote to Seeed about the lack of a header, I could easily use my PICkit 2 if the IR Toy came with a ICSP header.
PGC & PGD don't need to stay shorted once the bootloader is activated, the LED stayed on after I removed the makeshift header.
I did notice the FT232R USB UART appears as not connected even when I'm using the virtual COM port.
Seeed doesn't have anything to do with placing the header. DP decides what components are placed on the board. The ICSP header is useless in most case as the chips come preprogrammed with bootloader and firmware.
After shorting the pins, you could insert a normal header into the your pickit and insert it into the holes, by bending it a little it should make contact adn give just about time to reprogram it. see also this post: http://dangerousprototypes.com/forum/in ... 37#msg5037 (http://dangerousprototypes.com/forum/index.php?topic=573.msg5037#msg5037) (the quote of hank, couldn't find the original post)
or just solder a header onto the irtoy...
Is good to know just holding the header works, but the ICSP header is not useless at all, like you said people can connect a PICkit and read the PIC or program the bootloader.
Is a matter of convenience for the user.
[quote author="liyin"]It would be easier if IR Toys came with a ICSP header, how expensive could it be to solder a 5 pin male header?[/quote]When I purchased my IR Toy, it came with a 5-pin header. I have a PICkit 2 and a couple of clones, but I have never used the ICSP header. Well, I did attach it long enough to confirm that the PIC was recognized, but I didn't program the Flash. I've never had a problem with the IR Toy, though, even after carrying it around in my laptop bag.
In other words, the header would rarely be used.
Also, I have a Mac, and it's fairly easy to tell whether a USB device is working because of the USB Prober application. I think that Windows has USBView.exe which does something similar for diagnostics.
Hi liyin - Sorry you're having a problem with the USB IR Toy.
How long was the IR Toy with v1.04 powered? Do you know what mode it was in when it stopped working?
You were able to get it going with a firmware reflash though?
I did notice the FT232R USB UART appears as not connected even when I'm using the virtual COM port.
Can you please explain this a little more? The USB IR Toy is a PIC CDC-ASM device, not a FT232-based USB UART. It just appears as a COMx port on Windows.
The ICSP header is not populated for several reasons. Over hundreds of units is it much cheaper, and to hit the $20 price point (cheapest device of this type that I've ever seen) we had to do everything possible to keep costs down. For most people the version without a header is preferable, it takes up less space and fits in smaller cases, and it's a lot easier to solder a header on than remove one.
[quote author="ian"]
How long was the IR Toy with v1.04 powered? Do you know what mode it was in when it stopped working?
You were able to get it going with a firmware reflash though?[/quote]
Hard to say, at the time I was trying different commands/modes and getting samples from remote control in sampling mode (mainly) and RC5/IRMan modes, while using Hercules and Terminal software (switching between ASCII & Hex for sending and receiving).
It was easy to spot when the IR Toy stopped working because the LED didn't turn on when starting the PC.
Can you please explain this a little more? The USB IR Toy is a PIC CDC-ASM device, not a FT232-based USB UART. It just appears as a COMx port on Windows.
Yes, I associated the virtual COM ports of the Bus Pirate (FT232) and the IR Toy (CDC-ACM) because they use the same COM port number when in use.
The ICSP header is not populated for several reasons. Over hundreds of units is it much cheaper, and to hit the $20 price point (cheapest device of this type that I've ever seen) we had to do everything possible to keep costs down. For most people the version without a header is preferable, it takes up less space and fits in smaller cases, and it's a lot easier to solder a header on than remove one.
When you say it takes less space, are you talking about the right-angle header coming off the side of the board, cause the straight header is shorter than the IR module or the IR LED.
@.@ A 40-pin male header row can be had for $0.50 (bag of 5), only 5 pins would be really cheap.
If I need to use a PICkit, I'll insert a header and pressed it against the contacts.
[quote author="liyin"]
The ICSP header is not populated for several reasons. Over hundreds of units is it much cheaper, and to hit the $20 price point (cheapest device of this type that I've ever seen) we had to do everything possible to keep costs down. For most people the version without a header is preferable, it takes up less space and fits in smaller cases, and it's a lot easier to solder a header on than remove one.
When you say it takes less space, are you talking about the right-angle header coming off the side of the board, cause the straight header is shorter than the IR module or the IR LED.
@.@ A 40-pin male header row can be had for $0.50 (bag of 5), only 5 pins would be really cheap.
If I need to use a PICkit, I'll insert a header and pressed it against the contacts.
[/quote]
You forget that just buying a header won't get you there. It needs to be soldered in and QC checked (labour is not cheap). With runs of 100s IR toys this will add significant cost to the total.
Yup, the cost to solder and inspect the header is about 5x the cost of the header.
I'll mess around with the v1.04 tomorrow and see if I can reproduce the problem. It seems like several people have had this problem. I'm trying to figure out now if it is a problem with the most recent batch, or if it is a problem with the v1.04 firmware only. Other people have written Seeed for help who go it in the most recent batch, but I don't know if they upgraded to v1.04 or not.
I found two issues.
The reset routine in IR sample mode doesn't clear timer0 on exit. It could interrupt into another mode and get stuck because the flag is never cleared. This shouldn't cause a stack overflow, at least in my experience. Fixed this right around here:
http://code.google.com/p/dangerous-prot ... /IRs.c#129 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/USBIRtoy/IRtoy-firmware/IRs.c#129)
The other issue was that the samples were being crammed into the buffer with no regard for how many bytes where there. If it was full it just kept adding. This would certainly cause a buffer overflow, maybe a stack overflow depending on what got overwritten from the buffer overflow. I added a check in the interrupt routine here:
http://code.google.com/p/dangerous-prot ... /IRs.c#248 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/USBIRtoy/IRtoy-firmware/IRs.c#248)
That's not enough though, because the whole approach is wrong. The PIC has no atomic mode, so we need to be careful about writing to the buffer in interrupt because it might be in use by the USB routine at the same time. The IRIO mode handles this by moving the bytes assembled by the interrupt routine into the buffer in the main loop:
http://code.google.com/p/dangerous-prot ... IRIO.c#228 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/USBIRtoy/IRtoy-firmware/IRIO.c#228)
This method will need to be implemented in the IR Sample mode too. I will do this now.
Ok, here's a new test version with a fix for the buffering problem and a very robust overflow detection and reporting system:
http://dangerous-prototypes-open-hardwa ... 5-test.hex (http://dangerous-prototypes-open-hardware.googlecode.com/svn/trunk/USBIRtoy/firmware/USBIRToy.v1.05-test.hex)
The interrupt now puts the samples in a primary buffer, which is moved into the USB buffer in the service loop. This prevents the interrupt from writing to the USB buffer when it's in use.
Also, I added a bunch of checks to see if the USB can't keep up with the IR data. If that happens, the IR Toy sends 0xff 0xff 0xff 0xff 0xff 0xff, three null periods. It clears everything and waits for new samples.
Updated to 1.05 without problems.
It depends on what you mean by consistent.
Hello... I am trying to utilize the Diolan bootloader under OS/X, in order to replace the current firmware on my IR Toy that stopped working recently. Does anyone have any experience using that bootloader with OS/X. per Ian, he said that it is most likely a command line sequence. I will research but was just wondering if anyone was a couple of steps ahead of me using OS/X.
Thanks Ralph.
--UPDATE: updated the IR Toy to v1.02 with the WinXP version of Diolan bootloader. I now have a functioning IR Toy again.
[quote author="ian"]It depends on what you mean by consistent.[/quote]Did this reply end up in the wrong thread? What's the context for your response (I searched for the word "consistent" and didn't see anyone use it recently in this thread).
I entered the bootloader in Terminal, then closed Terminal and opened Hercules, but the COM port was gone and couldn't get the IR Toy out of the bootloader, even after disconnecting the IR Toy from the USB port for a few seconds.
I flashed the IR Toy again to recover from the bootloader. Once it is activated, what options do you have, besides flashing the bootloader. I read in another post about a reset button in a future IR Toy.
I entered the bootloader in Terminal, then closed Terminal and opened Hercules, but the COM port was gone and couldn't get the IR Toy out of the bootloader, even after disconnecting the IR Toy from the USB port for a few seconds... Once it is activated, what options do you have, besides flashing the bootloader.
The bootloader should only enter if there is a connection between the PGC and PGD pins. Just replug the USB cable to exit. The bootloader won't even start automatically on a chip with a bootloader but no firmware. Is it possible your system is sending a modem setup string (might begin with $) when the serial port connects? I've seen something similar with Macs and a Bus Pirate before.
Did this reply end up in the wrong thread?
I guess liyin edited the post, there was a question about which protocol is more consistent.
I'm trying to understand the sequence of events when the IR Toy is powered up, what communication takes place between the IR Toy & PC.
From visual inspection, I see the LED stays on until XP starts loading drivers, is the bootloader active like in an Arduino, for a set time, or just waiting for the PC to load some driver?
This is a great bootloader, written in ASM and released under the GPL, that enumerates as an HID device.
What's the meaning of "enumerates as an HID device"? IR Toy is CDC-ACM.
Unplug the IR Toy, remove the jumper, and plug it back in.
Is it really necessary to unplug/plug IR Toy when placing/removing the jumper?
The Ir toy checks for a connection between PGC and PGD at powerup, if there is a connection then the bootloader starts. The LED is on while it waits for windows to configure it.
The IR Toy firmware is CDC-ACM (virtual serial), but the bootloader uses the HID protocol and a different USB VID/PID.
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.