Sunday, January 29, 2012

Enabling SPI logging in BlueSuite tools CSR BlueCore chips

BlueFlashCmd.exe and other tools, part of CSR BlueSuite toolset to program BlueCore Bluetooth chips, has support for logging SPI communication with a chip. To enable it:

BlueFlashCmd.exe -trans "SPIDEBUG_FILE=spi.log SPIDEBUG=ON" -chipver

The key parameter here is SPIDEBUG_FILE - logging is activated when it's specified, and thus logging is always done to a file. One way to have logging go to a console is to use SPIDEBUG_FILE=con: , but then it won't be possible to redirect it.

Besides SPIDEBUG=ON, there're other logging levels/features:
  • SPIDEBUG
  • SPIDEBUG_REPRODUCIBLE
  • SPIDEBUG_WRITES
  • SPIDEBUG_READS
  • SPIDEBUG_WIRE
The keys may be also specified in the environment instead of -trans switch arguments.

Looking at the output produced, it turns out it spends a lot in calibrating SPI speed, a way to that down is to use SPISLOW=ON setting right away.

8 comments:

lz3060 said...

Hi There!

I've been fiddling with one of these modules for some time now, but mine has the limited linvorV1.5 firmware. I don't have a windows machine or access to the CSR tools. So, 2 questions:

Have you tried replaying the log to see if the module can be reprogrammed without the official tools? How much logic is there on the host side? I'd be willing to give it a try if I get my hands on an SPI dump :)

Does the upgraded firmware support setting the CTS/RTS pins? If none of them does, why would they name them as such on the pinout? How hard would it be for someone to create a firmware which does support setRTS and setCTS?

Thanks!

pfalcon said...

Well, it doesn't matter what firmware a module has - SPI interface drives CPU directly (just the same as for AVR chips for example).

I didn't try to replay the logs myself, but I know of projects/people dedicated to make module programming possible with alternative environments (under Linux, using Arduino). If you're keen to get ahold of logs, here're logs captured externally via logic analyzer:
http://www.farthen.de/?p=131

Of course, those are less structured than what could be generated by method described in this article. I've switched to other projects for now, but feel free if you're interested in this stuff and can wait.

As for CTS/RTS pins, I'm not sure what you mean - do you want to use them for hardware control, or as kind of GPIO (setting yourself)? In either case, 1st for sure should work, and even 2nd might be possible in a limited form. It might depend to some extend on module's virtual machine application (what most people call firmware, though it's just part of it), but mostly that handling should be controlled by PSKEYs of the underlying module's software stack (other part of firmware).

lz3060 said...

Thanks for replying so promptly!

I want to use RTS as GPO (iRobot Roomba needs a 500ms pulse on its DD pin to wake up), but I'm afraid neither this, nor using HW flow control is possible, at least with my module (linvorV1.5). It didn't work for me, then I read somewhere none of RTS, CTS, DTR, and DSR work.

I found the dumps minutes after I posted the previous comment, but I'm having trouble parsing the contents :) If you can point me to an explanation about the format and contents of the files it'd be great.

I will look for the people trying to make these programmable without the proprietary toolkit, I may even be able to help. Thanks once again!

pfalcon said...

> I want to use RTS as GPO ...

I hope you remember that there're plenty of other GPIO pins you can control... And again, it doesn't matter is you module is "linvor" or know, what matters is that it's BlueCore4-Ext and specific Bluetooth stack it uses.

> If you can point me to an explanation about the format and contents of the files it'd be great.

That's exactly the problem - it's SPI logs, but go datamine something useful from them. That's why I personally why I went to investigate BlueFlash builtin logging - it's order of magnitude easier to grasp than raw SPI logs, but it's still few orders to get something useful out of it.

lz3060 said...

I don't have any knowledge on programming (in the sense of writing the software for) the chipset. I dont't have a copy of BlueLab, not even a proper Windows machine :) Frankly, I don't even want to go there.

My goal is to get one additional output pin on the device, controllable via the BT serial link, preferrably using the standartized RTS or DTR pins.

I'm hoping to make this work:

#!/usr/bin/python2
import serial, time
s = serial.Serial('/dev/rfcomm0')
s.setRTS(0)
time.sleep(0.25)
s.setRTS(1)

So this brings 2 questions:

1) Is the "better" firmware available out there able to control those pins?

2) If the answer to the above is yes, is it somehow possible to flush the "better" firmware onto the chip without the proprietary toolkit?

Thanks a lot for bearing with me :)

pfalcon said...

> s.setRTS(0)

Neat idea how to (ab)use RFCOMM to control GPO on a module ;-). But is that supported by the official RFCOMM protocol at all? You can read and judge for yourself: https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=40909

My reading says that supporting such usage is optional, so if CSR didn't implement it in their stack, no wonder...

> 1) Is the "better" firmware available out there able to control those pins?

Thus RTS and friends possibly no. But what I'd like to write myself is open-source firmware which would allow to control first-class GPIO pins via BT. I might even get to that one sweet day ;-)

> to flush the "better" firmware onto the chip without the proprietary toolkit?

There're only 2 method to flash new firmware: 1) via SPI; 2) via USB DFU for the modules which have USB bootloader - out modules unlikely have it.

pfalcon said...

Ah, yep, there's also "UART DFU" thingy, but again, it's unclear which modules support it and which don't.

All in all, you always need to solder something, that's the most complicated part of it IMHO ;-)

pfalcon said...

FYI, I've released that open-source firmware I mentioned: http://pfalcon-oe.blogspot.com/2012/04/opensource-sensor-node-firmware-for.html

I made sure it includes means to control CTS/RTS pins (but well, it allows to control any normal GPIO either ;-) ).