blueflashcmd unable to reset device. about csr-spi-ftdi HOT 14 CLOSED

Hi! Yes, this looks like a bug, thanks for your report! I'll try to look at it later this night (I'm at GMT+6).

from csr-spi-ftdi.

I've checked with BC417143 and reading MISO line while CS# is 1 gives me a garbage (probably a last state, but I'm not sure). But reading it just after setting CS# to 0 gives the actual status of the CPU. Not checked with the logic analyzer though. Also other two opensource drivers, CsrSpiDrivers and CsrUsbSpiDeviceRE, read the status after setting CS# to 0.

So I think the comment is just not entirely right and needs to be changed.

Would You describe your setup and show the actual error, please?

from csr-spi-ftdi.

I have a CSR 8670. I have a spi programmer and I can use it from windows
to interact with the chip. My real goal is to interact with the CSR chip
from an FTDI (I'm using port 0 of an ftdi 4232H that I'm not using for
anything else.).

Just eyeballing some of the differences on a scope between the csr-spi-ftdi
I notice that it only resets the spi interface on start of transaction.
But not the end of it. Just a random thought.

If you see the datasheet here:
http://www.datasheet-pdf.com/datasheet-html/C/S/R/CSR8670-CSR.pdf.html

look at section: 7.3.2.

It says:

Multi-slave Operation Avoid connecting CSR8670 BGA in a multi-slave
arrangement by simple parallel connection of slave MISO lines. When CSR8670
BGA is deselected (SPI_CS# = 1), the SPI_MISO line does not float. Instead,
CSR8670 BGA outputs 0 if the processor is running or 1 if it is stopped.

So perhaps this mechanism is chip dependant? Looking up the chip you
mentioned I found with google:

some datasheet that mentions this part: BC417143B-IQN-E4

It says:

11.7.4 Multi-Slave Operation BlueCore4-External should not be connected in
a multi-slave arrangement by simple parallel connection of slave MISO
lines. When BlueCore4-External is deselected (SPI_CSB = 1), the SPI_MISO
line does not float. Instead, BlueCore4-External outputs 0 if the processor
is running or 1 if it is stopped.

So I'm kind of surprised it results in garbage. Perhaps there is some
settling time for the measurement?

I'm also wondering if there is some pull up/pull down strength changes from
switching it since presumably internally in the chip it muxes the line from
some SPI IP over to something that is just reading an enable signal for the
processor?

-- AMH

On Wed, Sep 9, 2015 at 10:21 AM, lorf [email protected] wrote:

I've checked with BC417143 and reading MISO line while CS# is 1 gives me a
garbage (probably a last state, but I'm not sure). But reading it just
after setting CS# to 0 gives the actual status of the CPU. Not checked with
the logic analyzer though. Also other two opensource drivers,
CsrSpiDrivers
https://github.com/Frans-Willem/CsrSpiDrivers/blob/master/spilpt.fixed/basics.cpp#L528
and CsrUsbSpiDeviceRE
https://github.com/Frans-Willem/CsrUsbSpiDeviceRE/blob/master/csrspi.c#L184,
read the status after setting CS# to 0.

So I think the comment is just not entirely right and needs to be changed.

Would You describe your setup and show the actual error, please?

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

from csr-spi-ftdi.

I realized I didn't show the actual error. I'm happy to provide that an
all debugging logs, but I can't do that for another 8 hours.

In the meantime, do you have anything that intercepts the full set of DLL
calls (on the windows side). I've looked at the SPI log output, but it's
of course missing the xap_stopped api calls from it since they don't get
logged.

-- Cheers, Arnar.

On Wed, Sep 9, 2015 at 10:55 AM, Arnar Mar Hrafnkelsson <[email protected]

wrote:

I have a CSR 8670. I have a spi programmer and I can use it from windows
to interact with the chip. My real goal is to interact with the CSR chip
from an FTDI (I'm using port 0 of an ftdi 4232H that I'm not using for
anything else.).

Just eyeballing some of the differences on a scope between the
csr-spi-ftdi I notice that it only resets the spi interface on start of
transaction. But not the end of it. Just a random thought.

If you see the datasheet here:
http://www.datasheet-pdf.com/datasheet-html/C/S/R/CSR8670-CSR.pdf.html

look at section: 7.3.2.

It says:

Multi-slave Operation Avoid connecting CSR8670 BGA in a multi-slave
arrangement by simple parallel connection of slave MISO lines. When CSR8670
BGA is deselected (SPI_CS# = 1), the SPI_MISO line does not float. Instead,
CSR8670 BGA outputs 0 if the processor is running or 1 if it is stopped.

So perhaps this mechanism is chip dependant? Looking up the chip you
mentioned I found with google:

some datasheet that mentions this part: BC417143B-IQN-E4

It says:

11.7.4 Multi-Slave Operation BlueCore4-External should not be connected in
a multi-slave arrangement by simple parallel connection of slave MISO
lines. When BlueCore4-External is deselected (SPI_CSB = 1), the SPI_MISO
line does not float. Instead, BlueCore4-External outputs 0 if the processor
is running or 1 if it is stopped.

So I'm kind of surprised it results in garbage. Perhaps there is some
settling time for the measurement?

I'm also wondering if there is some pull up/pull down strength changes
from switching it since presumably internally in the chip it muxes the line
from some SPI IP over to something that is just reading an enable signal
for the processor?

-- AMH

On Wed, Sep 9, 2015 at 10:21 AM, lorf [email protected] wrote:

I've checked with BC417143 and reading MISO line while CS# is 1 gives me
a garbage (probably a last state, but I'm not sure). But reading it just
after setting CS# to 0 gives the actual status of the CPU. Not checked with
the logic analyzer though. Also other two opensource drivers,
CsrSpiDrivers
https://github.com/Frans-Willem/CsrSpiDrivers/blob/master/spilpt.fixed/basics.cpp#L528
and CsrUsbSpiDeviceRE
https://github.com/Frans-Willem/CsrUsbSpiDeviceRE/blob/master/csrspi.c#L184,
read the status after setting CS# to 0.

So I think the comment is just not entirely right and needs to be changed.

Would You describe your setup and show the actual error, please?

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

from csr-spi-ftdi.

This sentence about multi-slave SPI is stick in every Bluecore datasheet. Also the method for checking the CPU stopped state is based on the reversed CSR's drivers (links above) is the same for all kinds of Bluecores.

I tried inserting delays before reading MISO, tried to pull MISO up and down with resistor, but the result is the same. I have a CSR8645 module, I will check with it later (probably tomorrow).

The CS line only have an effect on SPI port of the CPU, it doesn't affect the CPU's state, so I don't think that anything other than SPI port sources or sinks current to/from SPI lines. SPI pins may be shared with other functions, but then muxing is done inside the chip and is hidden from outside by pin drivers.

BTW, do You writing a custom firmware for CSR8670 or You want to control CSR's firmware? In any case You may have better results doing it over UART.

from csr-spi-ftdi.

No, I don't aware of such a tool, sorry. However there is a interception library specifically for CSR's LPT programmer driver. It should work for BlueSuite <= 2.3 and should work for USB SPI programmer too, You'll just need to rename it to usbspi.dll.

from csr-spi-ftdi.

I checked with CSR8645 and it shows the same behaviour - sometimes (I've no idea why yet) correct status is output on MISO only after setting CS# to 0. I also verified this with logic analyzer:

Now I think, that the sentence about multi-slave operation in the datasheet is not about the correct way of checking the CPU status, but just a warning that MISO will not float while the CS# is 1.

If You still interested, could You collect the debug logs of the failing command, please, with the command like this:

wine blueflashcmd -trans "SPIDEBUG=ON SPIDEBUG_FILE=csr-debug.log FTDI_LOG_LEVEL=debug,dump" -identify >csr-spi-ftdi-debug.log 2>&1

and send them to me at [email protected].

from csr-spi-ftdi.

I'll get you debug logs hopefully later today, do you want me to sync to
head just before building so I get your latest changes?

One note, the identify command doesn't seem to call reset (at least
identify always works). I'll do both that and without arguments which will
reset.

Also, I recall when looking at traces like this that while the programmer
is doing the initial MOSI to send out command and address etc, that the
value on the MISO line is just the last bit that was sent on MISO in the
last reply. Is that not the case?

On Fri, Sep 11, 2015 at 9:32 PM, lorf [email protected] wrote:

I checked with CSR8645 and it shows the same behaviour - sometimes (I've
no idea why yet) correct status is output on MISO only after setting CS# to
0. I also verified this with logic analyzer:
[image: stopped-status-1]
https://cloud.githubusercontent.com/assets/536698/9829806/6c12c016-592e-11e5-8379-81aabb00ed46.png

Now I think, that the sentence about multi-slave operation in the
datasheet is not about the correct way of checking the CPU status, but just
a warning that MISO will not float while the CS# is 1.

If You still interested, could You collect the debug logs of the failing
command, please, with the command like this:

wine blueflashcmd -trans "SPIDEBUG=ON SPIDEBUG_FILE=csr-debug.log FTDI_LOG_LEVEL=debug,dump" -identify >csr-spi-ftdi-debug.log 2>&1

and send them to me at [email protected].

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

from csr-spi-ftdi.

I'll take any logs, that You have, but logs from head are preferrable :)

Identify cmd uses watchdog to reset afaik. This can be verified in SPI
logs, it should write non-zero to bit 0 of address 0xff91 (watchdog enable
bit in reset enables register).

No, it's not. MISO outputs last MISO state while the chip is deselected,
once it's selected it outputs the current CPU status. I have a sigrok trace
of identify cmd, and although it's hard to show on screenshots, it has a
number of places where it's clearly visible. I can send You a trace file if
you want.

12.09.2015 23:36 пользователь "amhis" [email protected] написал:

I'll get you debug logs hopefully later today, do you want me to sync to
head just before building so I get your latest changes?

One note, the identify command doesn't seem to call reset (at least
identify always works). I'll do both that and without arguments which will
reset.

Also, I recall when looking at traces like this that while the programmer
is doing the initial MOSI to send out command and address etc, that the
value on the MISO line is just the last bit that was sent on MISO in the
last reply. Is that not the case?

On Fri, Sep 11, 2015 at 9:32 PM, lorf [email protected] wrote:

I checked with CSR8645 and it shows the same behaviour - sometimes (I've
no idea why yet) correct status is output on MISO only after setting CS#
to
0. I also verified this with logic analyzer:
[image: stopped-status-1]
<
https://cloud.githubusercontent.com/assets/536698/9829806/6c12c016-592e-11e5-8379-81aabb00ed46.png

Now I think, that the sentence about multi-slave operation in the
datasheet is not about the correct way of checking the CPU status, but
just
a warning that MISO will not float while the CS# is 1.

If You still interested, could You collect the debug logs of the failing
command, please, with the command like this:

wine blueflashcmd -trans "SPIDEBUG=ON SPIDEBUG_FILE=csr-debug.log
FTDI_LOG_LEVEL=debug,dump" -identify >csr-spi-ftdi-debug.log 2>&1

and send them to me at [email protected].

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

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

from csr-spi-ftdi.

Ok. I'm questioning my sanity here.

I synced a fresh client to head. And made an attempt to use the USB dll in
the new way of doing things... That didn't seem to work out of the box...
so I tried the old setup with all my local patches... And out of the box
the thing seemed to to dump the FW... albeit at a glacial pace, like it's
taking an hour to run dump.

But then I started looking into why the new one didn't work and I
remembered that I had to update the pinout to match my board and I think
I've discovered the problem when I looked at the diff for spi.c:

/* Pinout. Change it at will. Beware that FTDI adapters provide 5V or 3V3
I/O

• levels, but CSR chips require 3V3 or 1V8 I/O level. /
  -#define PIN_nCS (1 << 4) / FT232RL pin 2 (DTR#/D4), output /
  -#define PIN_CLK (1 << 2) / FT232RL pin 3 (RTS#/D2), output /
  -#define PIN_MOSI (1 << 7) / FT232RL pin 6 (RI#/D7), output /
  -#define PIN_MISO (1 << 5) / FT232RL pin 9 (DSR#/D5), input /
  +#define PIN_nCS (1 << 3) / FT232RL pin 2 (DTR#/D4), output /
  +#define PIN_CLK (1 << 0) / FT232RL pin 3 (RTS#/D2), output /
  +#define PIN_MOSI (1 << 1) / FT232RL pin 6 (RI#/D7), output /
  +#define PIN_MISO (1 << 2) / FT232RL pin 9 (DSR#/D5), input /
  #define PIN_nLED_RD (1 << 6) / FT232RL pin 10 (DCD#/D6), output /
  #define PIN_nLED_WR (1 << 3) / FT232RL pin 11 (CTS#/D3), output */
  #define PINS_OUTPUT (PIN_MOSI | PIN_CLK | PIN_nCS | PIN_nLED_RD |
  PIN_nLED_WR)

I left PIN_nLED_WR at 1<<3 which is what I have CS at! So that seems like
a likely cause for my problems.

I'll run some tests and report back if I can reliably reset after fixing
this...

Btw, I chose that pinout to be compatible with the MPSSE mode on the 4232h
module. Do you think any sort of speedup would be possible by using the
native MPSSE mode?

-- AMH

On Sat, Sep 12, 2015 at 9:17 PM, lorf [email protected] wrote:

I'll take any logs, that You have, but logs from head are preferrable :)

Identify cmd uses watchdog to reset afaik. This can be verified in SPI
logs, it should write non-zero to bit 0 of address 0xff91 (watchdog enable
bit in reset enables register).

No, it's not. MISO outputs last MISO state while the chip is deselected,
once it's selected it outputs the current CPU status. I have a sigrok trace
of identify cmd, and although it's hard to show on screenshots, it has a
number of places where it's clearly visible. I can send You a trace file if
you want.

12.09.2015 23:36 пользователь "amhis" [email protected] написал:

I'll get you debug logs hopefully later today, do you want me to sync to
head just before building so I get your latest changes?

One note, the identify command doesn't seem to call reset (at least
identify always works). I'll do both that and without arguments which
will
reset.

Also, I recall when looking at traces like this that while the programmer
is doing the initial MOSI to send out command and address etc, that the
value on the MISO line is just the last bit that was sent on MISO in the
last reply. Is that not the case?

On Fri, Sep 11, 2015 at 9:32 PM, lorf [email protected] wrote:

I checked with CSR8645 and it shows the same behaviour - sometimes
(I've
no idea why yet) correct status is output on MISO only after setting
CS#
to
0. I also verified this with logic analyzer:
[image: stopped-status-1]
<

https://cloud.githubusercontent.com/assets/536698/9829806/6c12c016-592e-11e5-8379-81aabb00ed46.png

Now I think, that the sentence about multi-slave operation in the
datasheet is not about the correct way of checking the CPU status, but
just
a warning that MISO will not float while the CS# is 1.

If You still interested, could You collect the debug logs of the
failing
command, please, with the command like this:

wine blueflashcmd -trans "SPIDEBUG=ON SPIDEBUG_FILE=csr-debug.log
FTDI_LOG_LEVEL=debug,dump" -identify >csr-spi-ftdi-debug.log 2>&1

and send them to me at [email protected].

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

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

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

from csr-spi-ftdi.

Lager buffer size of 4232 should already give significant speedup (and 0.5.0 should detect and use that). But using MPSSE should additionaly give around 16x speedup for HW SPI. I'm, however, have no MPSSE-capable chips, and also they are more expensive and less popular.

from csr-spi-ftdi.

Ok, updating the pin configuration on what I just synced works pretty
great, -dump completed well under a minute.

0.5.0 will use the larger buffer dynamically?

I either have to pass FTDI_BASE_CLOCK=500000

or the logging options to prevent the spiclock down stepping from kicking
in. That seems a little surprising.

Do you have 3.3V to 1.8V level shifters handy (assuming most of your
modules use 1.8V) if a ftdi 4232h mini module were to show up randomly
(that part speaks 3.3V only)?

http://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_FT4232H_Mini_Module.pdf

-- AMH

On Sun, Sep 13, 2015 at 4:04 AM, lorf [email protected] wrote:

Lager buffer size of 4232 should already give significant speedup (and
0.5.0 should detect and use that). But using MPSSE should additionaly give
around 16x speedup for HW SPI. I'm, however, have no MPSSE-capable chips,
and also they are more expensive and less popular.

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

from csr-spi-ftdi.

Yes, 0.5.0 should detect and use larger buffer according to the FTDI chip type (4KB for 4232 wrt to 384 bytes for FT232R). It should be printed in the statistics before exit like this:

FTDI chip: FT232R (3), buffer size: 384 bytes

However it was not tested on the chips other than FT232R.

Well, I don't currently have an idea why logging affects SPI stability.

I have a simple MOSFET-based level shifter module handy, but never tried it with this setup.

from csr-spi-ftdi.

Looks like problem was addressed so I'm closing it

from csr-spi-ftdi.