Because my problem seems unrelated to the bootloader (where is first posted a question regarding this problem) i've opened a new topic.
While trying to connect to the ;logic analyzer from my Kubuntu 10.4 x86_64 laptop i get the following error when running the pump_loader program:
root@laptop-danny:~/logicanalyzer/pump-loader# ./pump-loader -p:/dev/ttyACM0
PUMP loader
Opening serial port '/dev/ttyACM0' @ 921600 ... OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Error - unknown flash type (ff ff ff ff)
root@laptop-danny:~/logicanalyzer/pump-loader#
The "unknown flash" bit worries me. I do not have any windows systems around so i am unable to test on windows.
On http://dangerousprototypes.com/2010/02/25/prototype-open-logic-sniffer-logic-analyzer-2/ (http://http://dangerousprototypes.com/2010/02/25/prototype-open-logic-sniffer-logic-analyzer-2/) i found the following text;
If the FPGA doesn’t load after a few seconds, because of an error or blank ROM chip, the PIC will automatically enter ROM update mode and the ACT LED will illuminate
A quick check showed my ACT led does in fact stay on. Those two indications lead me to believe the flash memory is defective.
Can anybody confirm that the pump_loader program does correctly read the flash type?
I saw another earlier today that had a weird ID and it corrected by moving to another USB port. Maybe that will help. I'd guess, pending confirmation of the pirate-loader linux version functionality, that the ROM chip was damage in shipping. I'm sure Seeed will send you out a new board.
The pump-loader.pl perl app is cross-platform, is it possible to test with that? We used the .pl script during development, I'm fairly certain that it works.
The perl script gives the following output:
danny@laptop-danny:~/logicanalyzer/FPGA_ROM/bin$ perl pump-loader.pl -p /dev/ttyACM0 -i
PUMP-Loader v0.1
Using: /dev/ttyACM0
Read/write: 2048 pages
Reading firmware version:
Hardware: 1, Firmware: 0.1, Bootloader: 1
Reading JEDEC ID: 0xffffffff
Incorrect flash, or flash not found!
danny@laptop-danny:~/logicanalyzer/FPGA_ROM/bin$
So it returns the same invalid ROM id. Using another USB port does noet seam to matter, i will try another system - just to make sure. I have sent a message to Seeed regarding this problem.
Positive is that you have tested pump-loader with invalid flash and it reacts correctly ;)
You should probably check solder job on the Dataflash chip and/or short on the fpga pins (something might be wrong on the spi bus).
[quote author="robots"]
Positive is that you have tested pump-loader with invalid flash and it reacts correctly ;)
[/quote]
I would gladly have passed that honour!
You should probably check solder job on the Dataflash chip and/or short on the fpga pins (something might be wrong on the spi bus).
I cannot find anything obvious :(
What did attract my attention is the comment in in this post http://dangerousprototypes.com/forum/index.php?topic=657.msg6033#msg6033 (http://http://dangerousprototypes.com/forum/index.php?topic=657.msg6033#msg6033).
When i attach my board and start the Java client from the command line the logging (sometimes) reports "Device ID: 0x460148" which looks very much like the message "Error - unknown flash type (48 01 46 00)". I have tried the pump-loader executable with different speeds but that always returns 4 times ff, never the 48014600 address. The perl script does not offer different speeds but neither returns that address. Other ports and reboot does not change anything for me.
-- EDIT --
Even the ultimate "other USB port" (i.e. on another system) gives the exact same output :(
I'm sorry, I really do think the flash is broken, the behavior seems consistent. I'm sure Seeed will happily send you a new OLS.
When i attach my board and start the Java client from the command line the logging (sometimes) reports "Device ID: 0x460148" which looks very much like the message "Error - unknown flash type (48 01 46 00)"
When the PIC detects that the FPGA isn't working after a few seconds it goes into update mode automatically (ACT LED lights). Update mode is also a serial port, so the Java client is sending and receiving garbage from a serial device that speaks a totally different protocol.
Hi Danny,
I just tested "your" board on my windows platform, same result "Error - unknown flash type (ff ff ff ff)".
Conclusion is that it must be a problem with your board and not a driver, USB-port or Linux problem.
My board is still working fine........
Cheers,
G.
I have just recently purchased the OLS and decided to look at the status of the bootloader and ended up with the following :
C:Logic SnifferBootloader files>Bitstream-2.04updatepump-loader.exe -p:COM24
-t:115200 -status
PUMP loader
Opening serial port 'COM24' @ 115200 ... OK
Found PUMP HW: 1, FW: 2.3, Boot: 2
Error - unknown flash type (ef 30 13 00)
There are two issues with this, firstly the return for the boot is 2 instead of 1 for present and 255 for absent. the second issue is the flash type being returned.
It was noted that in http://dangerousprototypes.com/2010/02/ ... nalyzer-2/ (http://dangerousprototypes.com/2010/02/25/prototype-open-logic-sniffer-logic-analyzer-2/)
the following comment
After a reset, the ACT LED will blink while the FPGA loads the bitstream contained in the ROM chip. If the FPGA doesn’t load after a few seconds, because of an error or blank ROM chip, the PIC will automatically enter ROM update mode and the ACT LED will illuminate (see ROM updater below).
The ACT LED will turn off when the FPGA is configured and ready. The OLS then enumerates as a USB virtual serial port device. The first time you plug it in, you may need to feed Windows the .inf file in the project archive to assign driver to the device.
Once enumerated, the ACT LED blinks to indicate any USB activity.
When the board is first powered up the ACT LED flashes a few times the stops. When the client is opened and a capture is initiated the ACT LED flashes once at the beginning of the capture and a few times at the end of the capture. What is noted however that when doing multiple captures of the same waveform, ie one after the other, the first or second capture may produce a waveform but all of the others will be blank, but the ACT LED will flash correctly.
Another issue I have noticed is that quite often I have to reload the usb driver as when plugging the OLS into the usb the original
port does not always recognise the unit.
Please can anyone shed some light on these issues.
Thanks Ian
Hi IanK,
I think you are using quite some old tools (using tools from a bitstream2.0 update apparently from your command line) and firmware (2.3 vs 3.0).
The ef 30 13 (00) should be according to http://www.winbond.com/NR/rdonlyres/AEC ... 5X40BV.pdf (http://www.winbond.com/NR/rdonlyres/AEC6E481-6616-4555-B339-6E79D17810AC/0/W25X10BV_W25X20BV_W25X40BV.pdf)
a W25X40 type of chip and AFAIK has only been used on HW Ver 1.04 and older tools do not support it.
Your best bet is to use the 3.08 update package from the GadgetFactory and start from there.
http://logicsniffer.gadgetfactory.net/i ... r.Download (http://logicsniffer.gadgetfactory.net/index.php?n=LogicSniffer.Download)
You can update to firmware 3.0 and Bitstream 3.07, and recheck your problems after that.
I think I have seen a bootloader version 2 before so I would not be that worried about that for start.
Regards,
tkg
Hi tkg,
Thanks for your prompt reply. I have updated all of the firmware and bitstream and now get the following
C:Logic SnifferOBL mastertoolsols-loader>ols-loader.exe -p:COM24 -t:115200 -
status
Logic Sniffer ROM loader v0.3 (November 9, 2010)
Opening serial port 'COM24' @ 115200 ... OK
Found OLS HW: 1, FW: 3.0, Boot: 2
Found flash: WINBOND W25X40
OLS status: 00
C:Logic SnifferOBL mastertoolsols-loader>
and all the problems that I was experiencing regarding the multiple captures have been cleared up and the unit is working perfectly.
I am now going to run it through a number of tests using SPI, I2C and UART and see how it goes.
Again thanks for all your help.
Regards
Ian
Hi Ian,
Glad it worked out!
Also do not forget if you use the java OLS client to get the latest one (the version in the 3.08 update package seems oldish).
You should be able to find the latest at http://www.lxtreme.nl/ols/ (http://www.lxtreme.nl/ols/) .
Regards,
tkg
Hi thg,
I have the version 0,9,4 which was released on October 29th, 2012,
Regards
Ian
Hi Ian,
Strange!
The 0.9.4 and October 29th, 2012 does not add up.
0.9.4 was released around April 20th, 2011 and
0.9.6.1 was released on October 29th, 2012
Thus, unless you have a custom version the numbers you posted seem wrong.
If your date is right then you probably have 0.9.6.1.
Regards,
tkg
Hi tkg,
You are quite correct, the version I had was Jawis-OLs version 9.4.
I have gone to http://www.lxtreme.nl/ols/ (http://www.lxtreme.nl/ols/) and downloaded version 0.9.6....WOW this is so much better than the older version and seems to be more stable.
Thanks for your help.
Regards
Ian
Hi Ian,
Glad you got it cleared up!
Also if you still have any issues with the java OLS client or in the future, you might also want to check if somebody already had a similar issue here:
https://github.com/jawi/ols/issues (https://github.com/jawi/ols/issues)
I think version 0.9.7 might be out soonish (or else and if you have a good reason for it, you could get the current snapshot of it from github and compile it but obviously it might not be as stable as 0.9.6.1)
Happy sniffing!
Regards,
tkg
Hi tkg,
Thanks very much for your help.
Regards
Ian
I have exactly the same issue as that reported by IanK higher up this thread.
The reply from TKG says to update the firmware from 3.08 update package. As a complete newb to this, does this mean programming the PIC using a PicKit2 using the ICSP socket. I could really use a step by step instruction on how to proceed. I have the picKit but am wary of bricking the OLS.
Thanks
Andy
If you have a programmer you can recover from a bricking. First try the normal bootloader process over USB. If that doesn't work connected the programmer to ICSP socket and program the bootloader .HEX from the update package, then try the normal USB bootloader process again.
Opening serial port '/dev/ttyACM0' @ 921600 ... OK
Found OLS HW: 1, FW: 2.3, Boot: 2
Error - unknown flash type (48 01 46 02)
Trying to update a v1.04 Logic Sniffer to firmware ols-0308.
Have found at least one bug in the Linux x64 path through the ols-upgrader.sh . The check
if [ "$(arch)" == 'x86-64' ]; then is wrong, at least my system returns x86_64..
Suggestions to resolve the error above? I'm attempting to update the firmware and failing.
Cheers Harry
Sorry to follow on from my own post. :(
I have a version 1.04 Logic Sniffer.
I believe it worked when first delivered, I suspect a failed firmware upgrade left it in an unusable state.
I'm connecting to it from a 64 bit Linux environment, mint17.
I'm attempting to recover from a suspected failed firmware update, by installing the modern firmware versions from ols-0308.
The original failed update was a long time ago, possibly from a windows environment. I do not recall any useful details.
The Linux update package fails, see my previous post, looking through the code, I'm guessing that the majority of testing is under cygwin on windows.
Examining the bash script that is failing for me, it appears to be an interface to two executables, (in various versions for different host environments).
fw_update and ols-loader.
If I read the runes correctly ols-loader configures the Xilinx FPGA and fw_loader the PIC that handles comms.
I've poked about with both utilities and attach their help output in case its useful for anybody else.
First, the Linux system does recognize the ols when it is connected:
[37866.295569] usb 3-1: new full-speed USB device number 16 using ohci-pci
[37866.468765] usb 3-1: New USB device found, idVendor=04d8, idProduct=fc92
[37866.468774] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[37866.468779] usb 3-1: Product: Logic Sniffer CDC-232
[37866.468784] usb 3-1: Manufacturer: Microchip Technology Inc.
[37866.470834] cdc_acm 3-1:1.0: This device cannot do calls on its own. It is not a modem.
[37866.470869] cdc_acm 3-1:1.0: ttyACM0: USB ACM device
shoka@ShokaLaptop ~ $
Investigating the device status gives :
shoka@ShokaLaptop ~/OLS/ols-0308/OLS_Upgrader/linbin64 $ ./ols-loader -p:/dev/ttyACM0 -status
Logic Sniffer ROM loader v0.3 (November 9, 2010)
Opening serial port '/dev/ttyACM0' @ 921600 ... OK
Found OLS HW: 1, FW: 2.3, Boot: 2
Error - unknown flash type (48 01 46 02)
From examination of the bash script and substituting the parameters that the script passes to the executables, I believe what the script is trying to do is this:
./ols-loader -write -erase -p:/dev/ttyACM0 -wB:~/OLS/ols-0308/OLS_Upgrader/FPGAROM/logic_sniffer_3.07-Demon-Core.bit
./fw_update -e -w -m flash -vid 0x04d8 -pid 0xfc92 -ix ~/OLS/ols-0308/OLS_Upgrader/PIC_firmware/OLSv1.04-firmware-v2.3.hex
The first screws up, presumably because the PIC firmware is incorrect:
shoka@ShokaLaptop ~/OLS/ols-0308/OLS_Upgrader/linbin64 $ ./ols-loader -write -erase -p:/dev/ttyACM0 -wB:~/OLS/ols-0308/OLS_Upgrader/FPGAROM/logic_sniffer_3.07-Demon-Core.bit
Logic Sniffer ROM loader v0.3 (November 9, 2010)
Opening serial port '/dev/ttyACM0' @ 921600 ... OK
Found OLS HW: 1, FW: 2.3, Boot: 2
Error - unknown flash type (48 01 46 02)
shoka@ShokaLaptop ~/OLS/ols-0308/OLS_Upgrader/linbin64 $
The second also fails ...
shoka@ShokaLaptop ~/OLS/ols-0308/OLS_Upgrader/linbin64 $ ./fw_update -e -w -m flash -vid 0x04d8 -pid 0xfc92 -ix ~/OLS/ols-0308/OLS_Upgrader/PIC_firmware/OLSv1.04-firmware-v2.3.hex
U2IO flash erasing: FAILED.
Device is not found.
Operation aborted.
shoka@ShokaLaptop ~/OLS/ols-0308/OLS_Upgrader/linbin64 $
Trying a simpler command segfaults ...
shoka@ShokaLaptop ~/OLS/ols-0308/OLS_Upgrader/linbin64 $ ./fw_update -ver
fw_update Version: 0.2.0
U2IO BootLoader Version reading: FAILED.
Segmentation fault
shoka@ShokaLaptop ~/OLS/ols-0308/OLS_Upgrader/linbin64 $
Looking in the linbin and winbin directories, there is no file fw_update.
In those directories the file is called ols-fw-update, the file in the winbin directory is ols-fw-update.exe.
Is it possible that the file in linux64 is stale? The test in the bash file that calls this has a bug as I noted above, which means that that script will never execute the 64 bit code.
Does anyone know where the source for the loaders is available, possibly linux64 simply does not work.
Harry
shoka@ShokaLaptop ~/OLS/ols-0308/OLS_Upgrader/linbin64 $ ./fw_update -help
USAGE:
fw_update <COMMAND> [OPTIONS...]
COMMANDS:
-w -write
Write data to device.
-r -read
Read data from device.
-v -verify
Verify device memory.
-e -erase
Erase device memory.
-ver -version
Display versions of fw_update and BootLoader if present.
-h -help
Print this message.
OPTIONS:
-m -memory <MEMMORY TYPE>
Memory type for read, write and verify operations.
Possible values: flash, eeprom, id, all.
Default: flash
-vid -vendorid <VID>
Device vendor ID.
-pid -productid <PID>
Device product ID.
-t -reset <YES | NO>
Reset device after operation is finished.
Default: YES
-s -size <SIZE>
The data size for read, write and verify operations.
-a -address <ADDR>
The start address for read, write and verify operations.
Default: 0x800 for flash, 0x00 for other memory types.
-ix -image_hex_in <FILE_NAME>
Image file in Intel Hex Format for write and verify operations.
-ib -image_bin_in <FILE_NAME>
Image file in Binary Format for write and verify operations.
-ox -image_hex_out <FILE_NAME>
Image file in Intel Hex Format for read operation to save data.
-ob -image_bin_out <FILE_NAME>
Image file in Binary Format for read operation to save data.
-d -data [DATA]
Immediate mode - actual byte(s) specified in the command line.
Data for write and verify operations must be provided
as string of two hex digits per byte (like 01202040ac).
For read operation data is printed on screen.
shoka@ShokaLaptop ~/OLS/ols-0308/OLS_Upgrader/linbin64 $
shoka@ShokaLaptop ~/OLS/ols-0308/OLS_Upgrader/linbin64 $ ./ols-loader --help
Logic Sniffer ROM loader v0.3 (November 9, 2010)
parameters:
-p:PORT - port of Logic Sniffer, needs to be specified
-t:SPEED - sets speed of the serial port
-wH:FILE - HEX file to be uploaded to OLS
-wB:FILE - BIN file to be uploaded to OLS
-rH:FILE - HEX file to be downloaded from OLS
-rB:FILE - BIN file to be downloaded from OLS
-l:X - send only first X paged
commands:
-erase - erases Flash
-write - writes data to Flash
-read - reads data from Flash
-ignore_jedec - ignore jedec id
-run - enter run mode after finished
-status - get OLS stauts
-boot - enter bootloader mode - ignore other commands
-selftest - run self-test - ignore other commands
When no command specified, program will check FW version, and Flash ID
Usage examples:
To read Flash to HEX file 'OLS.hex' from OLS on COM2:
ols-loader -p:COM2 -rH:OLS.hex -read
To erase and write flash, data in BIN file 'OLS.bin', OLS on COM2:
ols-loader -p:COM2 -wB:OLS.hex -write -erase
To get status, and jump to run mode, OLS on COM2:
ols-loader -p:COM2 -run -status
shoka@ShokaLaptop ~/OLS/ols-0308/OLS_Upgrader/linbin64 $
I used this guide when building from scratch
viewtopic.php?f=23&t=1654&start=90#p42557 (http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=1654&start=90#p42557)
/Bingo
Edit : Ohh and maybe put these "modem manager" rules in udev , else it takes forever before the modemmanager releases the tty-port.
viewtopic.php?f=37&t=5181#p50193 (http://dangerousprototypes.com/forum/viewtopic.php?f=37&t=5181#p50193)