"Error: Failed to Stop Processor" about csr-spi-ftdi HOT 40 CLOSED

Correction: MISO does appear to send back valid information -- it just takes it a few tries. I don't have a logic analyzer here, so I don't know what it is saying, but MISO is definitely responding to read commands. However, the "Could not stop processor" error remains...

from csr-spi-ftdi.

I suspect that there may be a bug in version 0.3.1, please try 0.3. I'll try to investigate that when I get home.

Reset pin does not involved in SPI communication. Host sends commands over SPI to some debug block on the chip which is responsible for CPU stop, reset, etc. SPI interface itself resets when CS# is held high for 2 SPI clock cycles.

And your project sounds very cool!

from csr-spi-ftdi.

I think I figured it out. In my test setup with HC-05 I also get errors similar to those You get. Lowering resistor value at CLK line fixed this. It seems that BC417 pins have higher capacitance, than pins of BC5 chip I usually test with.

Please try to lower resistor value at CLK line to 470 or 330 Ohm. If this helps I'll update schematic and README.

from csr-spi-ftdi.

BTW, 0.3.1 works OK, I was wrong in my suspicion.

from csr-spi-ftdi.

Thank you so much for getting back to me so quickly! It is so hard to find
good documentation on these chips. I am overjoyed to have someone to talk
to about them.

Alas, after bridging all the SPI pins, first with 220 ohm resistors, then
with wire jumpers, I find no change in the outcome. The clock pulses look
fairly sharp on my scope -- rise time is:
CLK 45 ns.
CS 43 ns
MOSI 44 ns
MISO -- only 4 ns

The clock frequency is only about 1 MHz.

Do these rise times look similar to your own? If so, do you have any other
ideas? I have tried this on two different hc-05 boards from two different
suppliers (they appear to be different batches as well).

I will try the 1.3 code to be sure.

Again, I cannot tell you how thankful I am for your attention.

-Jack

Is that sharp enough? It seems to be very sharp relative to the clock,
which is

On Tue, Jan 27, 2015 at 8:34 AM, lorf [email protected] wrote:

BTW, 0.3.1 works OK, I was wrong in my suspicion.

—
Reply to this email directly or view it on GitHub
#1 (comment).

Jack Zylkin
www.usbtypewriter.com

from csr-spi-ftdi.

I'm not sure if these images will help -- they show the resistors I used
(which I then jumpered over), the FTDI board I used, the pins on the HC-05,
and so on. Notice that I removed the 3.3V switch on the FTDI and manually
jumpered 3.3V to VCCIO -- that was so I didn't accidentally bump the switch
to 5V and fry the chip.

By the way, there is other stuff on this board -- an Atmega32u4
microcontroller -- but it does not share any pins with the HC-05 other VCC
and GND. It is connected to the HC-05 RX and TX pins as well, but it
tri-states those pins right now.

My only other thought is that it could be a bad USB cable? here's hoping.

-Jack

On Tue, Jan 27, 2015 at 1:05 PM, Jack Zylkin [email protected] wrote:

Thank you so much for getting back to me so quickly! It is so hard to
find good documentation on these chips. I am overjoyed to have someone to
talk to about them.

Alas, after bridging all the SPI pins, first with 220 ohm resistors, then
with wire jumpers, I find no change in the outcome. The clock pulses look
fairly sharp on my scope -- rise time is:
CLK 45 ns.
CS 43 ns
MOSI 44 ns
MISO -- only 4 ns

The clock frequency is only about 1 MHz.

Do these rise times look similar to your own? If so, do you have any
other ideas? I have tried this on two different hc-05 boards from two
different suppliers (they appear to be different batches as well).

I will try the 1.3 code to be sure.

Again, I cannot tell you how thankful I am for your attention.

-Jack

Is that sharp enough? It seems to be very sharp relative to the clock,
which is

On Tue, Jan 27, 2015 at 8:34 AM, lorf [email protected] wrote:

BTW, 0.3.1 works OK, I was wrong in my suspicion.

—
Reply to this email directly or view it on GitHub
#1 (comment).

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

from csr-spi-ftdi.

I removed the jumper between VCCIO and my board, then powered both boards
separately. I was able to get this output from XIDE with the run command:

Programming flash...

Running 'C:/BlueLab41/tools/bin/make -R BLUELAB=C:/BlueLab41/tools -f
hid_keyboard.release.mak flash'...

C:/BlueLab41/tools/bin/pscli -trans 'SPITRANS=LPT SPIPORT=1' @raw
@hci_onchip -m hid_keyboard.psr_

pscli -trans "SPITRANS=LPT SPIPORT=1" @raw @hci_onchip -m hid_keyboard.psr_
: concluded with Success

*** Statistics *******************************************

Time open: 62.530 s

Time in xfer: 54.151 s (86.60% of open time)

Reads: 782 (3906 bytes, 4.99 bytes avg read size)

Writes: 681 (2191 bytes, 3.22 bytes avg write size)

Xfer data rate: 0.11 KB/s (6097 bytes in 54.151 s)

C:/BlueLab41/tools/bin/blueflashcmd -trans 'SPITRANS=LPT SPIPORT=1' merge

CSR BlueFlash Tool (Command Line) BlueSuite-2.1.1-Release

Copyright (C) 2002-2008 Cambridge Silicon Radio Ltd.

Resetting XAP

Error - unable to reset device. (no device attached?)

Failed

*** Statistics *******************************************

Time open: 5.517 s

Time in xfer: 4.684 s (84.90% of open time)

Reads: 64 (128 bytes, 2.00 bytes avg read size)

Writes: 60 (166 bytes, 2.77 bytes avg write size)

Xfer data rate: 0.06 KB/s (294 bytes in 4.684 s)

make: *** [flash] Error 1

Finished.

Does that mean my flash succeeded?

-Jack

On Tue, Jan 27, 2015 at 1:49 PM, Jack Zylkin [email protected] wrote:

I'm not sure if these images will help -- they show the resistors I used
(which I then jumpered over), the FTDI board I used, the pins on the HC-05,
and so on. Notice that I removed the 3.3V switch on the FTDI and manually
jumpered 3.3V to VCCIO -- that was so I didn't accidentally bump the switch
to 5V and fry the chip.

By the way, there is other stuff on this board -- an Atmega32u4
microcontroller -- but it does not share any pins with the HC-05 other VCC
and GND. It is connected to the HC-05 RX and TX pins as well, but it
tri-states those pins right now.

My only other thought is that it could be a bad USB cable? here's hoping.

-Jack

On Tue, Jan 27, 2015 at 1:05 PM, Jack Zylkin [email protected] wrote:

Thank you so much for getting back to me so quickly! It is so hard to
find good documentation on these chips. I am overjoyed to have someone to
talk to about them.

Alas, after bridging all the SPI pins, first with 220 ohm resistors, then
with wire jumpers, I find no change in the outcome. The clock pulses look
fairly sharp on my scope -- rise time is:
CLK 45 ns.
CS 43 ns
MOSI 44 ns
MISO -- only 4 ns

The clock frequency is only about 1 MHz.

Do these rise times look similar to your own? If so, do you have any
other ideas? I have tried this on two different hc-05 boards from two
different suppliers (they appear to be different batches as well).

I will try the 1.3 code to be sure.

Again, I cannot tell you how thankful I am for your attention.

-Jack

Is that sharp enough? It seems to be very sharp relative to the clock,
which is

On Tue, Jan 27, 2015 at 8:34 AM, lorf [email protected] wrote:

BTW, 0.3.1 works OK, I was wrong in my suspicion.

—
Reply to this email directly or view it on GitHub
#1 (comment).

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

from csr-spi-ftdi.

I don't have a scope here, sorry. I also don't see images, maybe some upload problem...

I prepared a version for You to check, if You don't mind. I added ability to set SPI clock frequency using SPI_CLOCK environment variable. Please try lowering clock frequency to, say, 200kHz (frequncy is set to 2 MHz by default). Used like this:

set SPI_CLOCK=200000
blueflashcmd -chipver
blueflashcmd -shape
blueflashcmd -dump -raw dumpfile.bin

Frequency is in Hz. Download csr-spi-ftdi-0.3.2a1-spi-clock-test.zip from here:
http://dl.bintray.com/frol/generic/

from csr-spi-ftdi.

Awesome!! I will try it right now...

Is there a way to use this option with XIDE and with BlueFlash?

On Wed, Jan 28, 2015 at 1:58 PM, lorf [email protected] wrote:

I don't have a scope here, sorry. I also don't see images, maybe some
upload problem...

I prepared a version for You to check, if You don't mind. I added ability
to set SPI clock frequency using SPI_CLOCK environment variable. Please try
lowering clock frequency to, say, 200kHz (frequncy is set to 2 MHz by
default). Used like this:

set SPI_CLOCK=200000
blueflashcmd -chipver
blueflashcmd -shape
blueflashcmd -dump -raw dumpfile.bin

Frequency is in Hz. Download csr-spi-ftdi-0.3.2a1-spi-clock-test.zip from
here:
http://dl.bintray.com/frol/generic/

—
Reply to this email directly or view it on GitHub
#1 (comment).

Jack Zylkin
www.usbtypewriter.com

from csr-spi-ftdi.

Ahh! No luck!

I ordered some more HC-05 boards and a possibly legit CSR USB-SPI
programmer from China, just to test if it is indeed the FTDI system that is
not working. It may be that my FT232 board is no good. I will get a new
one of those as well -- I owe it to you to get to the bottom of this can of
worms I opened for you. Thank you so much for your help!!!

-Jack

On Wed, Jan 28, 2015 at 3:44 PM, Jack Zylkin [email protected] wrote:

Awesome!! I will try it right now...

Is there a way to use this option with XIDE and with BlueFlash?

On Wed, Jan 28, 2015 at 1:58 PM, lorf [email protected] wrote:

I don't have a scope here, sorry. I also don't see images, maybe some
upload problem...

I prepared a version for You to check, if You don't mind. I added ability
to set SPI clock frequency using SPI_CLOCK environment variable. Please try
lowering clock frequency to, say, 200kHz (frequncy is set to 2 MHz by
default). Used like this:

set SPI_CLOCK=200000
blueflashcmd -chipver
blueflashcmd -shape
blueflashcmd -dump -raw dumpfile.bin

Frequency is in Hz. Download csr-spi-ftdi-0.3.2a1-spi-clock-test.zip from
here:
http://dl.bintray.com/frol/generic/

—
Reply to this email directly or view it on GitHub
#1 (comment).

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

from csr-spi-ftdi.

By the way, I did confirm that the SPI_CLOCK settings affect the clock
frequency. As it is right now, the read/write clock is operating very
nearly at the SPI_CLOCK setting. However, the two reset pulses occur at
twice the SPI_CLOCK frequency. I'm sure that has nothing to do with why my
flasher is busted, but I thought I'd let you know as you are without
oscilloscope.

-Jack

On Wed, Jan 28, 2015 at 4:10 PM, Jack Zylkin [email protected] wrote:

Ahh! No luck!

I ordered some more HC-05 boards and a possibly legit CSR USB-SPI
programmer from China, just to test if it is indeed the FTDI system that is
not working. It may be that my FT232 board is no good. I will get a new
one of those as well -- I owe it to you to get to the bottom of this can of
worms I opened for you. Thank you so much for your help!!!

-Jack

On Wed, Jan 28, 2015 at 3:44 PM, Jack Zylkin [email protected] wrote:

Awesome!! I will try it right now...

Is there a way to use this option with XIDE and with BlueFlash?

On Wed, Jan 28, 2015 at 1:58 PM, lorf [email protected] wrote:

I don't have a scope here, sorry. I also don't see images, maybe some
upload problem...

I prepared a version for You to check, if You don't mind. I added
ability to set SPI clock frequency using SPI_CLOCK environment variable.
Please try lowering clock frequency to, say, 200kHz (frequncy is set to 2
MHz by default). Used like this:

set SPI_CLOCK=200000
blueflashcmd -chipver
blueflashcmd -shape
blueflashcmd -dump -raw dumpfile.bin

Frequency is in Hz. Download csr-spi-ftdi-0.3.2a1-spi-clock-test.zip
from here:
http://dl.bintray.com/frol/generic/

—
Reply to this email directly or view it on GitHub
#1 (comment).

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

from csr-spi-ftdi.

My only thought is that I somehow damaged the FT232 board by misusing the
VCCIO pin. The datasheet says it can only source 50mA -- does the HC-05
use more than that during programming? I suspect it does, so maybe I
fizzled the internals of the FT232 somehow. Anyway, I ordered a replacement
for all the components, so I can start fresh.

On Wed, Jan 28, 2015 at 4:13 PM, Jack Zylkin [email protected] wrote:

By the way, I did confirm that the SPI_CLOCK settings affect the clock
frequency. As it is right now, the read/write clock is operating very
nearly at the SPI_CLOCK setting. However, the two reset pulses occur at
twice the SPI_CLOCK frequency. I'm sure that has nothing to do with why my
flasher is busted, but I thought I'd let you know as you are without
oscilloscope.

-Jack

On Wed, Jan 28, 2015 at 4:10 PM, Jack Zylkin [email protected] wrote:

Ahh! No luck!

I ordered some more HC-05 boards and a possibly legit CSR USB-SPI
programmer from China, just to test if it is indeed the FTDI system that is
not working. It may be that my FT232 board is no good. I will get a new
one of those as well -- I owe it to you to get to the bottom of this can of
worms I opened for you. Thank you so much for your help!!!

-Jack

On Wed, Jan 28, 2015 at 3:44 PM, Jack Zylkin [email protected] wrote:

Awesome!! I will try it right now...

Is there a way to use this option with XIDE and with BlueFlash?

On Wed, Jan 28, 2015 at 1:58 PM, lorf [email protected] wrote:

I don't have a scope here, sorry. I also don't see images, maybe some
upload problem...

I prepared a version for You to check, if You don't mind. I added
ability to set SPI clock frequency using SPI_CLOCK environment variable.
Please try lowering clock frequency to, say, 200kHz (frequncy is set to 2
MHz by default). Used like this:

set SPI_CLOCK=200000
blueflashcmd -chipver
blueflashcmd -shape
blueflashcmd -dump -raw dumpfile.bin

Frequency is in Hz. Download csr-spi-ftdi-0.3.2a1-spi-clock-test.zip
from here:
http://dl.bintray.com/frol/generic/

—
Reply to this email directly or view it on GitHub
#1 (comment).

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

from csr-spi-ftdi.

I didn't measured module load current. Max load currents per datasheets:

• BC417143B - 57.9 mA during boot, 52 mA during rx/tx;
• MX29LV800 flash - 30mA during write.

I'm currently out of ideas too, so I forged a test program that tests FT232R data transmission via loopback. To run the test You need to connect FT232R pins as follows:

TX   <-> DTR#
RX   <-> DSR#
RTS# <-> DCD#
CTS# <-> RI#

The program transmits a buffer of alternating patterns via 4 pins, receives it via other 4 pins, then does this in the other direction. It loops this sequence indefinitely (or specified number of times). If it finds any errors it shows this immediately. When the tests are completed or Ctrl-C pressed it shows statistics and exits. See included README.md.

Can You, please, run the test on your adapter? Download ftdi-syncbb-loopback-test-0.1.zip from http://dl.bintray.com/frol/generic/.

from csr-spi-ftdi.

Also, have you tried other programmers: https://github.com/lorf/csr-spi-ftdi#related-projects?

from csr-spi-ftdi.

I will try that tonight. I purchased an official CSR USB programmer from a
supplier in China, and I'm still waiting for it to arrive. That will help
narrow down what is at fault.

On Thu, Jan 29, 2015 at 10:49 AM, lorf [email protected] wrote:

Also, have you tried other programmers:
https://github.com/lorf/csr-spi-ftdi#related-projects?

—
Reply to this email directly or view it on GitHub
#1 (comment).

Jack Zylkin
www.usbtypewriter.com

from csr-spi-ftdi.

Today, I bought a brand-new ftdi board from sparkfun, and put it on a blank
circuit board with nothing but an hc-05 on it -- none of my other
circuitry. I used the VCCIO 3.3V output to power the bluetooth board. It
gives me the very same problems, so this rules out a faulty FTDI board and
a faulty HC-05 board. I can vouch that my interface board is good, because
I beeped out all the signals and made sure none of them are crossed, and
they are all connected as shown on the picture I sent you last week.

Meanwhile, I cannot try my nifty new CSR programmer from China, because I
do not have the 64-bit driver for it. My version of BlueLab appears to have
come only with the 32-bit driver (usbspi.inf and usbspi.sys are the driver
files, and they refuse to install on my 64-bit system) Would you happen to
have these files on your computer?

If not, I'm still stuck. I will run the script you sent, as a sanity check,
even though I have ruled out faulty FTDI boards.

-Jack

On Thu, Jan 29, 2015 at 2:17 PM, Jack Zylkin [email protected] wrote:

I will try that tonight. I purchased an official CSR USB programmer from
a supplier in China, and I'm still waiting for it to arrive. That will help
narrow down what is at fault.

On Thu, Jan 29, 2015 at 10:49 AM, lorf [email protected] wrote:

Also, have you tried other programmers:
https://github.com/lorf/csr-spi-ftdi#related-projects?

—
Reply to this email directly or view it on GitHub
#1 (comment).

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

from csr-spi-ftdi.

Hi there,

I managed to find drivers for the official CSR USP-SPI programmer, even
though they have taken all the free software off their website!!! (I
cannot imaging why they would want to keep people from using their IDE).
Anyway, after installing the usb-spi drivers, the BlueFlash was able to
stop the chip and return: "Recognized AMD-compatible device on BC4-EXT
(cyt), ManID=0xC2 DevID=0x225B"

So, it looks like the FTDI system is not working correctly somehow, but the
CSR programmer is! I will keep looking into your FTDI code -- I suspect it
may have to do with the fact that I am using 64-bit windows, and my version
of BlueLab appears to be 32 bit (judging by how some of the drivers are
32-bit only).

I downloaded a different version of BlueSuite (Ver 2.5 -- which includes
proper 64 bit drivers), but for now I can't get spilpt.dll to work with it
at all... The FTDI dongle doesn't show up as a transport option at all with
that version!

But right now I am excited to have something working, even if it is not
your solution. I will probably just play with that for the next few days
before returning to find out why the FTDI system did not work. I may never
know, but regardless I am extremely thankful for your support and advice.
Your project is very cool, even if I haven't gotten it to work on my setup.

-Jack

On Thu, Feb 5, 2015 at 2:21 PM, Jack Zylkin [email protected] wrote:

Today, I bought a brand-new ftdi board from sparkfun, and put it on a
blank circuit board with nothing but an hc-05 on it -- none of my other
circuitry. I used the VCCIO 3.3V output to power the bluetooth board. It
gives me the very same problems, so this rules out a faulty FTDI board and
a faulty HC-05 board. I can vouch that my interface board is good, because
I beeped out all the signals and made sure none of them are crossed, and
they are all connected as shown on the picture I sent you last week.

Meanwhile, I cannot try my nifty new CSR programmer from China, because I
do not have the 64-bit driver for it. My version of BlueLab appears to have
come only with the 32-bit driver (usbspi.inf and usbspi.sys are the driver
files, and they refuse to install on my 64-bit system) Would you happen to
have these files on your computer?

If not, I'm still stuck. I will run the script you sent, as a sanity
check, even though I have ruled out faulty FTDI boards.

-Jack

On Thu, Jan 29, 2015 at 2:17 PM, Jack Zylkin [email protected] wrote:

I will try that tonight. I purchased an official CSR USB programmer from
a supplier in China, and I'm still waiting for it to arrive. That will help
narrow down what is at fault.

On Thu, Jan 29, 2015 at 10:49 AM, lorf [email protected] wrote:

Also, have you tried other programmers:
https://github.com/lorf/csr-spi-ftdi#related-projects?

—
Reply to this email directly or view it on GitHub
#1 (comment).

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

from csr-spi-ftdi.

Mini-update: I just realized I had to use API 1.4 with BlueSuite 2.5.0
instead of 1.3 --- the FTDI dongle shows up now, but it still has the same
problem though... cannot stop processor.

So, my software suite is not at fault either, it would seem.

On Thu, Feb 5, 2015 at 3:42 PM, Jack Zylkin [email protected] wrote:

Hi there,

I managed to find drivers for the official CSR USP-SPI programmer, even
though they have taken all the free software off their website!!! (I
cannot imaging why they would want to keep people from using their IDE).
Anyway, after installing the usb-spi drivers, the BlueFlash was able to
stop the chip and return: "Recognized AMD-compatible device on BC4-EXT
(cyt), ManID=0xC2 DevID=0x225B"

So, it looks like the FTDI system is not working correctly somehow, but
the CSR programmer is! I will keep looking into your FTDI code -- I
suspect it may have to do with the fact that I am using 64-bit windows, and
my version of BlueLab appears to be 32 bit (judging by how some of the
drivers are 32-bit only).

I downloaded a different version of BlueSuite (Ver 2.5 -- which includes
proper 64 bit drivers), but for now I can't get spilpt.dll to work with it
at all... The FTDI dongle doesn't show up as a transport option at all with
that version!

But right now I am excited to have something working, even if it is not
your solution. I will probably just play with that for the next few days
before returning to find out why the FTDI system did not work. I may never
know, but regardless I am extremely thankful for your support and advice.
Your project is very cool, even if I haven't gotten it to work on my setup.

-Jack

On Thu, Feb 5, 2015 at 2:21 PM, Jack Zylkin [email protected] wrote:

Today, I bought a brand-new ftdi board from sparkfun, and put it on a
blank circuit board with nothing but an hc-05 on it -- none of my other
circuitry. I used the VCCIO 3.3V output to power the bluetooth board. It
gives me the very same problems, so this rules out a faulty FTDI board and
a faulty HC-05 board. I can vouch that my interface board is good, because
I beeped out all the signals and made sure none of them are crossed, and
they are all connected as shown on the picture I sent you last week.

Meanwhile, I cannot try my nifty new CSR programmer from China, because I
do not have the 64-bit driver for it. My version of BlueLab appears to have
come only with the 32-bit driver (usbspi.inf and usbspi.sys are the driver
files, and they refuse to install on my 64-bit system) Would you happen to
have these files on your computer?

If not, I'm still stuck. I will run the script you sent, as a sanity
check, even though I have ruled out faulty FTDI boards.

-Jack

On Thu, Jan 29, 2015 at 2:17 PM, Jack Zylkin [email protected] wrote:

I will try that tonight. I purchased an official CSR USB programmer
from a supplier in China, and I'm still waiting for it to arrive. That will
help narrow down what is at fault.

On Thu, Jan 29, 2015 at 10:49 AM, lorf [email protected] wrote:

Also, have you tried other programmers:
https://github.com/lorf/csr-spi-ftdi#related-projects?

—
Reply to this email directly or view it on GitHub
#1 (comment).

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

Jack Zylkin
www.usbtypewriter.com

from csr-spi-ftdi.

Hi. I'm experiencing similar problems.

I'm using a FT232RL module hooked up with 220 ohm resistors on all 4 pins (tried several different values on the CLK pin). The BT module I'm attempting to reflash is a typical H05/H06/Linvor type module (http://wiki.pinguino.cc/index.php/SPP_Bluetooth_Modules).

Everything is connected perfectly fine and pscli / PSTool works (can sometimes take a few attempts to get initialized) and I can read out all parameters.

BlueTest3 (from BlueSuite 2.5.8) reads the module as:
BC4-EXT (cyt) (Hardware ID 0x26) firmware version 3296.

The problem is BlueFlashCmd / BlueFlash, which just refuses to reset XAP / stop the processor.

I've tried BlueSuite version 2.3 (api1.3), 2.4, 2.5 and 2.5.8 (all api1.4) and tested with several version of your spilpt driver, 0.2, 0.3, 0.31 and also 0.3.2a1 with different SPI_CLOCK settings. The driver used for the FT232RL is libusbK (v3.0.7.0) installed using Zadig.

BlueFlashCmd either fails completely with error (most of the time):
Error detecting chip type (Unable to start read (invalid control data))
or it can fail after hanging a few seconds on (after a few attempts):
Resetting XAP

Output (running BlueFlashCmd -dump):

blueflashcmd, version 2.5.8.667 Release
Copyright (C) 2002-2014, Cambridge Silicon Radio Ltd.

Resetting XAP
==============================================================================
ERROR: Error - unable to reset device. (no device attached?)
==============================================================================
*** Statistics *******************************************
Time open: 5.437 s
Time in xfer: 4.640 s (85.34% of open time)
Reads: 60 (120 bytes, 2.00 bytes avg read size)
Writes: 58 (160 bytes, 2.76 bytes avg write size)
Xfer data rate: 0.06 KB/s (280 bytes in 4.640 s)
**********************************************************
Failed

Output (running BlueFlashCmd -chipver):

blueflashcmd, version 2.5.0.93 Release
Copyright (C) 2002-2012, Cambridge Silicon Radio Ltd.

GBL_CHIP_VERSION = 0x4826
Result:
*** Statistics *******************************************
Time open: 0.312 s
Time in xfer: 0.234 s (75.00% of open time)
Reads: 4 (8 bytes, 2.00 bytes avg read size)
Writes: 2 (6 bytes, 3.00 bytes avg write size)
Xfer data rate: 0.06 KB/s (14 bytes in 0.234 s)
**********************************************************
Success

I'm running WinXP in VMWare, but should not make any difference.

from csr-spi-ftdi.

I cannot reproduce the fault here, sorry. Could You please reproduce the fault with command like this:

blueflashcmd -trans "SPIDEBUG=ON SPIDEBUG_FILE=out.txt" identify

and send me the output of the command and out.txt file to [email protected]?

from csr-spi-ftdi.

Anders, according to the logs You sent, something goes wrong just a bit after the start of communication with the module. Can You please share, from what source bluethooth module is powered, is there voltage regulator on the module, from what source FT232RL VCCIO is powered?

from csr-spi-ftdi.

The bluetooth module itself is soldered to a JY-MCU BT_BOARD v1.02 that has a pin that takes 3.6 to 6V VCC (which is regulated down to 3.3V and goes into pin 12 on the module, even probed it just to check and pin 12 do get 3.32V). I've tried powering the board input using different power sources. Either 5V from the FT232RL module or 5V directly from another USB port. The issue remains the same unfortunately.

from csr-spi-ftdi.

Anders, I've implemented SPI clock control and automatic slowdown in the DLL, which I thought were not really necessary. I'm not sure if it will help but it worth a try. Can You please try csr-spi-ftdi-0.3.2a3.zip from http://dl.bintray.com/frol/generic/

from csr-spi-ftdi.

For starters, it's a lot more stable when it comes to detecting the module, works pretty much every time. BlueTest3 and PSTool works every time now and the module is more or less always detected when running BlueFlashCmd. However, the issue persist. It hangs on Resetting XAP a few secs and then fails.

blueflashcmd, version 2.5.8.667 Release
Copyright (C) 2002-2014, Cambridge Silicon Radio Ltd.

Resetting XAP
============================================================
ERROR: Error - unable to reset device. (no device attached?)
============================================================
*** Statistics *******************************************
Time open: 5.453 s
Time in xfer: 4.687 s (85.95% of open time)
Reads: 60 (120 bytes, 2.00 bytes avg read size)
Writes: 58 (160 bytes, 2.76 bytes avg write size)
Xfer data rate: 0.06 KB/s (280 bytes in 4.687 s)
FTDI base clock: 800000 Hz
**********************************************************
Failed

I can send you new logs if that would help you any further debugging?

from csr-spi-ftdi.

Yes, send me the logs, please.

from csr-spi-ftdi.

Anders, thanks for the logs, things are more clear now. Looking at the logs, just before the end:

...
verified write 0076 - 0002
write ff91 - 0005
verified write 0077 - 0001
verified write 006a - 0000
read ff91 - 0001

and then transaction stops.

When testing on my HC05 module, it looks like this:

...
verified write 0076 - 0002
write ff91 - 0005
verified write 0077 - 0001
verified write 006a - 0000
read ff91 - 0000
read ff91 - 0000
...

and transaction continues (see my full log here).

According to https://gitorious.org/csrprogrammer/csrprogrammer/source/d6e9493f538d8b2677d5e1dcba7e1fc608dd27dd:bc_def.h#L565

• 0xff91 is the GBL_RST_ENABLES control register address
• 0x0005 is (RST_WATCHDOG_EN_MASK | RST_FULL_CHIP_RESET)
• 0x0001 is RST_WATCHDOG_EN_MASK
• 0x0076 is RSTGEN_WATCHDOG_DELAY control register
• 0x0077 is RSTGEN_WATCHDOG_KICK control register

I don't know what these commands mean exactly, but it looks like watchdog isn't disabled during reset in your case, or reset just doesn't occur.

So it looks like there is a real reset problem in Your case. It may or may not be related to csr-spi-ftdi. It's also not the same as original @jzylkin issue.

Do You have any clue why it may happen? May be some obscure PS keys were set?

from csr-spi-ftdi.

I'm now dumping the firmware as I'm writing this. The watchdog timeout (0x01f7 PSKEY_WD_TIMEOUT) was set to 5000000. I tried setting it to 0 (which disables the watchdog entirely) and that seemed to do the trick. What is the value on this timeout set to in your module? And how fast is a full flash dump supposed to be? It seems it's going to take some time here, currently at 10% after about 2-3 minutes or so.

BTW: Thanks for pointing me in the right direction and for your support and development of this FTDI hack. Good work.

from csr-spi-ftdi.

Good to hear. In my module PSKEY_WD_TIMEOUT is also set to 5000000, but is resets OK nonetheless. See complete PSR dump of my HC05 here.

Here, on bare HW (not VM) dump of 1 MB flash on HC05 takes about 1-2 minutes depending on FTDI clock rate. I think, it's VMware that slows USB transactions down in your case. It's also visible if You compare timings in the SPIDEBUG logs with mine.

from csr-spi-ftdi.

@ajdalshov, just to clarify - I was able to reproduce your issue by inserting a 10ms delay after each USB transaction. So it's definitely a timing issue. I think it may be VMware that cause timing problems by slowing USB transactions down. You may try running on bare HW, or try VirtualBox VM. I tested csr-spi-ftdi in WinXP running in VirtualBox on Linux x64 - the dump command is about 4 times slower than on bare HW, but otherwise works fine.

from csr-spi-ftdi.

@ajdalshov, confirmed problem with VMware player - running "blueflashcmd dump" produces "unable to reset device" error. After disabling watchdog - dump runs, but is awfully slow. Switching to different driver in Zadig didn't help.

from csr-spi-ftdi.

@jzylkin can You, please, clarify if You use csr-spi-ftdi under VMware or other VM?

@jzylkin and others having similar issues, please try out version 0.4. It has a couple of changes improving stability.

from csr-spi-ftdi.

Found a workaround for VMware. Adding this line to VM's .vmx file restores normal operation and reasonable speed:

usb.quirks.device0 = "0x0403:0x6001 skip-reset"

from csr-spi-ftdi.

No, I was not using VMware. However, I think the real problem was that I
am running a 64-bit computer, and my version of the CSR software and
drivers -- including your driver -- appear to be 32 bit.

If not that, then I think that the power consumption used during
programming may have been the culprit -- my board can only supply 100mA,
and the FT232 can only supply 50, whereas the official CSR programmer has a
1A regulator on board.

I am currently using the official CSR programmer, and a new 64-bit
installation of BlueSuite, and it is working very well. I'm sorry I wasn't
able to get your system working, but I'm sure it is no fault of yours.

Jack

On Thu, Mar 19, 2015 at 1:03 PM, lorf [email protected] wrote:

Found a workaround for VMware. Adding this line to VM's .vmx file restores
normal operation and reasonable speed:

usb.quirks.device0 = "0x0403:0x6001 skip-reset"

—
Reply to this email directly or view it on GitHub
#1 (comment).

Jack Zylkin
www.usbtypewriter.com

from csr-spi-ftdi.

Hi! Have same problem on win 7 (x86 and x64) with flasing my CSR BC212015 BT module (D-Link DBT-120).
Can't stop processor in BlueFlash (when press on button "stop processor" - BlueFlash don't stop it and goes to not answering).
Also can't read chip in Pstool.
If this is possible, cause i solder SPI interface to FTDI board WITHOUT 220 Ohm resistors?

from csr-spi-ftdi.

@DJ-URAN can You, please, try 0.4.1 and see if it works? https://github.com/lorf/csr-spi-ftdi/releases/tag/0.4.1

from csr-spi-ftdi.

Oh! My problem is resolved!! I install BlueLab 4.1 instead Bluesuite 2.5.8 and Pstool now can read chip via SPI (FTDI) and operate with pskeys in module! (of course, i insert spilpt.dll with api 1.3 version instead original in BlueLab folder).

from csr-spi-ftdi.

Now i have other problem: make run my BT keyboard in HID mode before OS starting. Sorry, offtop...

from csr-spi-ftdi.

Also i try 0.4.1 spilpt.dll in Bluesuite 2.5.8: nothing results, can't connect with chip.
But 0.4.1 for BlueLab 4.1 work perfectly!

from csr-spi-ftdi.

@DJ-URAN Nice to hear. Thanks for reporting!

@jzylkin Anyway, thanks for your reports and help!

from csr-spi-ftdi.

I think I finally fixed the issue. The reason for the timing problems was FT232R internal buffer timeout (called latency timer), which is set to 16 ms by default. See AN232B-04 for explanation.

I'm sorry for such an issue, which wouldn't happen if I read the docs carefully.

The fix is in 0.4.2. Tested in WinXP on VMware and in Windows 8 x64 on bare hardware.

Anyone experiencing similar or any other problems, please open new issue on github.

from csr-spi-ftdi.