search

lorf / csr-spi-ftdi

USB SPI programmer/debugger for CSR BlueCore bluetooth chips, based on FTDI USB to UART converter, for Linux and Windows
562 stars 102 forks source link

blueflashcmd unable to reset device. #5

Closed amhis closed 8 years ago

amhis commented 9 years ago

This feels really similar to the issue just closed. I'm pretty sure the CSR side of things works as I've tested it with a regular windows setup and a CSR programmer.

I seem to be able to do chipver until the cows come home without problems. I've slowed the clock down considerably which hasn't made much of a change.

The code for spifns_bluecore_xap_stopped() is strange:

/* Check the response to read command */
/* From CSR8645 datasheet: "When CSR8645 BGA is deselected (SPI_CS# = 1),
 * the SPI_MISO line does not float. Instead, CSR8645 BGA outputs 0 if the
 * processor is running or 1 if it is stopped. */
if (xferbuf[0])
    return SPIFNS_XAP_STOPPED;
return SPIFNS_XAP_RUNNING;

but afaict xferbuf[0] is read right after spi_xfer_begin(). That has the chip deselected for most of it, but ends by selecting it. So perhaps it only works most of the time due to a race condition?

The setup I'm running is under wine. I've looked at most of this on a scope and on a salea, but haven't zoomed in on the reset sequence yet.

Figured I'd send this if anything here seemed useful already.

lorf commented 9 years ago

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).

lorf commented 9 years ago

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?

amhis commented 9 years ago

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 notifications@github.com 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 https://github.com/lorf/csr-spi-ftdi/issues/5#issuecomment-138982264.

amhis commented 9 years ago

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 <arnar.mar@gmail.com

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 notifications@github.com 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 https://github.com/lorf/csr-spi-ftdi/issues/5#issuecomment-138982264.

lorf commented 9 years ago

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.

lorf commented 9 years ago

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.

lorf commented 9 years ago

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: stopped-status-1

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 dmitry.frolov@gmail.com.

amhis commented 9 years ago

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 notifications@github.com 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

  1. 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 dmitry.frolov@gmail.com.

— Reply to this email directly or view it on GitHub https://github.com/lorf/csr-spi-ftdi/issues/5#issuecomment-139714145.

lorf commented 9 years ago

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" notifications@github.com написал:

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 notifications@github.com 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

  1. 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 dmitry.frolov@gmail.com.

— Reply to this email directly or view it on GitHub https://github.com/lorf/csr-spi-ftdi/issues/5#issuecomment-139714145.

— Reply to this email directly or view it on GitHub https://github.com/lorf/csr-spi-ftdi/issues/5#issuecomment-139799346.

amhis commented 9 years ago

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

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 notifications@github.com 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" notifications@github.com написал:

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 notifications@github.com 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

  1. 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 dmitry.frolov@gmail.com.

— Reply to this email directly or view it on GitHub <https://github.com/lorf/csr-spi-ftdi/issues/5#issuecomment-139714145 .

— Reply to this email directly or view it on GitHub https://github.com/lorf/csr-spi-ftdi/issues/5#issuecomment-139799346.

— Reply to this email directly or view it on GitHub https://github.com/lorf/csr-spi-ftdi/issues/5#issuecomment-139843409.

lorf commented 9 years ago

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.

amhis commented 9 years ago

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 notifications@github.com 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 https://github.com/lorf/csr-spi-ftdi/issues/5#issuecomment-139860397.

lorf commented 9 years ago

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.

lorf commented 8 years ago

Looks like problem was addressed so I'm closing it