I compiled fw_update in both linux and Mac OS X. In both cases it can't find the ir toy and this is all I get:
# fw_update -e -w -v -m flash -vid 0x04d8 -pid 0xfd0b -ix USBIRToy.v22.hex
U2IO flash erasing: FAILED.
Device is not found.
I put the ir toy in to update mode with $ and the light is on. Linux does see the device. This is my current dmesg:
[31831.451058] usb 3-1: new full-speed USB device number 4 using ohci_hcd
[31831.651078] usb 3-1: New USB device found, idVendor=04d8, idProduct=fd0b
[31831.651089] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[31831.651098] usb 3-1: Product: Diolan
[31831.651103] usb 3-1: Manufacturer: Diolan
[31831.664076] generic-usb 0003:04D8:FD0B.0003: claimed by neither input, hiddev nor hidraw
I originally had hidraw enabled in the kernel and the message was slightly different and /dev/hidraw0 (or something like that) was created. It didn't see the device so I thought maybe the driver was conflicting with libusb. removing it didn't fix it.
I am currently stuck in update mode and my brand new ir toy is useless. Any ideas?
How about permissions ? Did you try to sudo ?
I tried the ols-fw-update binary from the latest open logic sniffer package and it finds the device, erases and writes the firmware but then fails at the verify step. I took away the -v option and it erased, wrote and rebooted but the irtoys serial device never shows up.So looks like the diolan's firmware_update utility linked from the irtoy docs is broken(atleast with modern linux and gcc) and the ols-fw-update doesn't work properly with the irtoy.
Yes I am running as root so that there wont be permission problems.
ols-fw-update is to OLS bootloader. Main difference is the size of page.
You will need to alter this line and compile yourself:
https://github.com/robots/ols-fwloader/ ... boot.h#L38 (https://github.com/robots/ols-fwloader/blob/master/src/ols-boot.h#L38)
I think it should be 32 for IR Toy, but i am not sure. :-)
You will also need to change line:
https://github.com/robots/ols-fwloader/ ... oot.c#L355 (https://github.com/robots/ols-fwloader/blob/master/src/ols-boot.c#L355)
#if OLS_PAGE_SIZE == 2
#if OLS_PAGE_SIZE <= 32
I knew it wasn't intended for the irtoy but it seemed to be based on the same source and more up to date so I figured that I would see if it could find it. It did. Was planning on diffing the sources but your pointers most likely just saved me a whole lot of time.
Since i am the author of the ols-fwloader, I know the internals :-).
I would like to know how it went. I could then add another target to the build process, so it would create another "flashing" binary for USB ir toy.
Based on the source of the other loader looks like 32 should be the right number:
size_t PicBootloader::page_size(PicBootloader::MemoryType memory)
Made those changes but I am getting the following error:
~user/Downloads/robots-ols-fwloader-fb4a14a/src/ols_fwloader -d -f BOOT -W -w ~user/Downloads/IRToy/firmware/USBIRToy.v22.hexBootloader version 0.2.2
Bootloader version 0.2.2
Reading file '/home/user/Downloads/IRToy/firmware/USBIRToy.v22.hex'
Data won't fit into buffer (size= 4000 want 4010)
Error reading file - skipping write
Did you try raising the Flash size ?
https://github.com/robots/ols-fwloader/ ... boot.h#L41 (https://github.com/robots/ols-fwloader/blob/master/src/ols-boot.h#L41)
Yes. I changes it to 6000 as in the origional diolan fw_updater. Didn't fix the problem. Changing OLS_FLASH_TOTSIZE to an arbitrarily large value bypasses the error but things don't work properly. Verify gives me lots of lines like this:
Diff @0x3d7d (Is 0xff should be 0xec)
Diff @0x3d7e (Is 0xff should be 0x17)
Diff @0x3d7f (Is 0xff should be 0xf0)
Diff @0x3d80 (Is 0xff should be 0xfb)
And I still don't have a working device.
Can you try to read the whole flash ? And upload the "hex" you read, and the one you are trying to flash.
I got fw_update working by taking the fixes from the version of it from the logic sniffer git tree. This means that it now compiles with newer versions of gcc and can actually find the ir toy in linux. The source is available here: http://jesshaas.com/software/IRToy-fw_update.tar.gz (http://jesshaas.com/software/IRToy-fw_update.tar.gz) This really should be put in the irtoy package and the docs should be updated.
robots-Would love to get your loader working as it would be nice if there was one loader for the various devices. Unfortunately I don't really have any more time to futz with it right now. Maybe if I get some more time later on I will try to get it working.
I was going to add this to SVN, but the source seems to have a lot of intermediate files. Any suggestions on what I can clean up? I am not a desktop programmer.
Sorry about that. Did a make clean and make distclean but didn't do a proper check of what all might be hanging around. Not a lot of free time these days so I just have a few minutes here and there to work on stuff. I will try to clean it up tomorrow and will post a new link when I do.
What would really help, is dump of flash memory when flashed correctly, dump of memory when flashed wrong. (dump made by fw_update). And probably dump of flash memory when flashed correctly (done with ols-fwloader).
Okay, I removed the cruft. Link is the same: http://jesshaas.com/software/IRToy-fw_update.tar.gz (http://jesshaas.com/software/IRToy-fw_update.tar.gz)
Will get you those firmware dumps later.
Thanks Jess, your source for fw_update worked for me.
One extra tip, in case anyone else has the same problem. I found that the source (and the original download of the source from Diolan) wouldn't configure - it complained of missing libusb. I had libusb and the development headers installed, and no amount of trying to give the right path would help. In the end I delved into the configure script and found the way it was attempting to link didn't seem to work with my copy of g++ (4.6.1 on Linux Mint). I had to:
in order to get the test program to link to get configure to run. Apart from that it worked perfectly.
It seems that jesshaas. com/software/IRToy-fw_update.tar.gz doesn't exist any more. Is there alternative location for firmware updater which works under Linux?
I'm asking this because I just received USB IR Toy v2 from seed, and it seems to be V212 which (if I understand it correctly) is v2 hardware with firmware v12 which would explain why it doesn't work for me :-)
p.s. I inserted space in URL above because forum won't let me post it otherwise. I did check correct one referenced on wiki and this forum.
Update: I extracted fw_update chages from OpenBench Logic Sniffer and applied changes required for 32k pic 18f2550. They are quite trivial, but I'm erasing just first 24k (which is enough for v22 firmware) see:
https://github.com/dpavlin/fw_update/co ... d93978ce06 (https://github.com/dpavlin/fw_update/commit/9bb8ccb24f7979d0253686772c3180d93978ce06)
I hope this will save time to next person who would like to update firmware on newly received IR Toy. It now correctly reports V222 and works with my LG remote. Thanks to everyone for this nice project.
Update 2: Current version at https://github.com/dpavlin/fw_update (https://github.com/dpavlin/fw_update) supports full 32k erase/program for 18F2550.
So you delved in and...
What did you do to fix it?
Sorry for necroposting, but I've got exactly the same issue (on Xubuntu 18.04):
I've just bought the IRToy from Seeed - and they still deliver it with outdated firmware: Selftest says version v212.
Now I'm stuck that the fw_update fails to configure/compile, complaining that:
checking for libusb... configure: error: libusb not found
I've tried compiling both: Jess' version
, as well as dpavlin/fw_update (Github)
. Same issue.
Although I've installed it libusb:
$ apt install libusb-1.0-0 libusb-1.0-0-dev
When I try charitones' suggestion (LIBS=-lusb ./configure), configure just stops earlier with this message:
configure: error: C++ compiler cannot create executables
(Which is not an issue when I omit "LIBS=-lusb", but...)
I've tried finding out how configure looks for libusb to fix why it can't find it, but failed :(
Any help would greatly be appreciated. Thanks :)
Where was the include file usb.h installed?
$ find / -iname "usb.h"
Gave a lot (>80) matches in kernel headers.
All these usb.h seemed to belong to individual hardware drivers (dvb, wimax/i2400m, snd, at76c50x, etc).
One however was in:/usr/src/linux-headers-18.104.22.168-generic/include/config/usb.h
...but none of them looked like libusb to me, but I may be wrong.
But then I also searched for "libusb.h", which returned:
Does that help?
Thanks in advance!
Hmmm... The program (pic_bootloader.cpp and pic_bootloader.h) expects a file called "usb.h", not libusb.h. On my Fedora 29 system, libusb-devel installs such a file, as /usr/include/usb.h.
How to solve this cleanly is not entirely clear. Ideally. the author of the program should check that the program compiles and works with the present libusb.
Try this: just copy your libusb.h to somewhere where the compiler finds it, using the name usb.h.
Ooooh... Will check/try that (and report back)!
Interesting that noone has previously mentioned this here...