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
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:
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!
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).
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!
> 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.
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 :)
> 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.
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 ;-)
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 ;-) ).
Post a Comment