Monday, April 2, 2012

OpenSource Sensor Node firmware for BlueCore-based Bluetooth Modules

BlueCore4-Ext is a popular Bluetooth chip used in many Bluetooth modules, some priced below $10. The idea is to create Wireless Sensor/Control Network using this modules, as Bluetooth is really ubiquitous technology nowadays, so any smartphone can be used to provide user UI/control for such network. This is especially facilitated by the fact that BlueCore4-Ext is a SoC (system-on-chip) integrating microcontroller and peripherals in one package (small too), allowing it to be programmed with a user firmware for autonomous functioning with minimum of additional components. It even has built-in temperature sensor, so just add a battery and you have ready-made wireless temperature sensor (not too precise, granted, but you can calibrate it yourself ;-) ).

(Image by robocraft.ru)


BluTuNode is a firmware for such a Bluetooth Wireless Node, which allows to control it from a host over the air.

Source code: http://github.com/pfalcon/blutunode

Features implemented:
  • Full control of GPIO: input/output, configuring direction, pullups/pulldowns, etc.
  • Reading sampled from build ADCs.
  • Reading of temperature sensor.
  • Querying other system parameters.
  • Querying Bluetooth parameters.
  • Poll mode, when module automatically reads some sensor at specified period and sends information to host.
Features planned/ideas:
  • UART control (note that this is generally not a priority, because UART is mostly used to connect to host/microcontroller, and this firmware is designed for autonomous modules).
  • SPI/I2C/1-wire support to connect external sensors.
  • More Bluetooth-level information and control.
  • OpenSource tools to program/manage BlueCore modules.
  • Flash access/writing, over-the-air firmware updates.

Appendix:

Some technical characteristics of BC4-based module:

SoC: BC417 (BC417143B full model ID)
CPU: XAP2+, 16-bit RISC (no special 8-bit data support), Harward architecture, 64Kword data space, 1Mword+ code space
Flash: 1Mbyte (512Kwords, 75% typically occupied by Bluetooth stack/OS)
RAM: 24Kword
Execution environment: Virtual machine, no native hardware access (later versions of firmware OS support "native" mode, heavily bounds-checked still).

50 comments:

Unknown said...

Hi,
I find your stuff very interesting,
What compiler are you using?, did you use the spi programming to flash the chip ?
And can you point me to some document that describes what/how much cpu/ram resources the units have for application part.

Cheers
Matias

lz3060 said...

That's great! Finally some real progress on utilizing these super cheap and very capable devices!

But ... no Makefile? What toolchain is needed to build the firmware? What programmer (hardware/software) can be used to flash it on the board?

I suspect the toolchain is proprietary and pretty expensive...

pfalcon said...

Matias: I've added some TTX. If you want more details, you can google for the chip datasheet.

Now regarding other concerns. Anything which is in the repository is written with my own hand from first byte to the last. Or, generated from what I've written with my own hand. So far, I haven't written the Makefile, hence it's not there. Makefile wouldn't help you unless you have whole toolchain, which, as you know, proprietary.

But guys, if you feel like you want an open-source compiler for this cute chip, if you want to turn it into an arduino, what can I say? If you looked how open implementations of original programmer appeared (google for it), how people work on a programmers devoid of stone-age hardware requirement, how open-source firmwares appear - and you got an idea to write an open-source compiler for it - who am I to stop you? ;-)

pfalcon said...

Ah, some insight regarding the proprietary toolchain: it is based on GCC, so I guess they just "forgot" to release it back to the open-source community.

Unknown said...

Seems that the gcc code is available by request, but not linker, guess that makes the code useless...
perhaps someone could create a bootloader, that allows loading for binaries that are compiled with the gcc part... using the code on the chip as a "library" that way avoiding usage of their linker?
anye ideas ?

pfalcon said...

Ok, if you look into that stuff, then you'll keep finding interesting things. For example, "object files" are nothing but a gzip'ped assembler source. "Linking" is nothing but uncompressing and concatenating. Open-source assembler for XAP was written by darkircop.org folks eons ago, when BlueCore was yet a novelty, and now revitalized by me: https://gitorious.org/xap-tools/xap-tools , etc., etc.

complexiity said...

Hello ,
i would like to apply this firmware to my HC05 module so that i may control the PIO,s remotely.
However i cant seem to interpret/install the data you have presented. I would really appreciate some help. Thanks PM/email/post

complexiity said...
This comment has been removed by the author.
JRMN said...

Any chance you going to to a video or photo tutorial.

joradom said...

Hello, I'm really interested in testing your firmware, but flashing myself the module is out of my scope ...

how much would you charge to send me a module flashed with blutunode?

thx

pfalcon said...

2 joradom: Thanks for the interest. I'm away from my HC-04 hacking setup at least until the end of summer. And I'm not sure what you'd expect from the firmware, but it's not yet user-ready. I considered calling for donations/setting up pledge on kickstarter.com or similar site, but well... I have a day job, and taking extra responsibilities may kill all fun in this hobby ;-).

So well, as I mentioned above, what this project needs is more hackers so far. If you'd like to help, please spread the word - maybe someone will pick it up, or I get motivation to continue on it if more people will pass by ;-).

Nicked said...

Have you ever attempted to use the USB interface

Unknown said...

Hi, very interesting post.

Will this firmware work as a SDR?

Sérgio Silva said...

Can it work with sensortag from TI?

Nicked said...

I think you will find that sensortag does not use a CSR core, which is priority to CSR. PFalcon is designed specifically for CSR chips.

Unknown said...

Hi, i think your project is amazing!
I now wonder if I would be able to direct send and receive baseband packet to a remote bt device.
Is that possible with your GPIO interface implementation?

Andy Hull said...

Hi

First let me say, I'm loving your work :¬)

May I suggest that we set up a forum and wiki, along the lines of say the CHDK forum, in order to share ideas. Blogs can get a bit cluttered very quickly.

If anybody wants to assist with hosting this or has any other helpful suggestions, post them here.

I was toying with the idea of using one of these modules as a bluetooth console for Canon cameras, and am in the process of hacking up a simple programmer adapter (and I do mean simple) details to be released as soon as I find time to complete it.

pfalcon said...

> send and receive baseband packet

If you're hinting towards SDR-like usage, then no. The whole idea of Bluetooth is that it's robust, realworld-useful protocol. Letting user send baseband packets on its whim can havoc Bluetooth network.
Bluetooth SIG does all due diligence to avoid that, so no product which lets user send baseband packets would get certification (and thus wouldn't be called "Bluetooth" at all).

That said, you can hack particular implementation to allow that. In case of CSR Bluecore, you would "only" need to reverse-engineer 6MB firmware for that.

RW3ACQ said...

Hi, dear all! I'm looking for step-by-step instruction to enable RTS pin on my HC-05! I need it so much!
If anyone can hear me please help



Hillel Chimowicz said...

XAP2 Open source Assembler / Deassembler

https://gitorious.org/xap-tools/xap-tools

Did anyone tried that?
Does it work?
Is the only thing missing is a C to XAP-ASM translation?

Hillel Chimowicz said...
This comment has been removed by the author.
Hillel Chimowicz said...

Ho, and everyone, U can hook (CSR's) BlueFlashCmd to backup and flash the fevice in A hackish way using an arduino+dll replacment for the lpt-spi interface, both found here:
https://github.com/Frans-Willem/CsrSpiDrivers

Works for me.

pfalcon said...

https://gitorious.org/xap-tools/xap-tools

is a git repo I set up to capture previous work on XAP asm/disasm and my hacks on it and related tools. So, yeah, "it works", depending on what you mean by "work" ;-).

Hillel Chimowicz said...

I Mean what is left in order to produce an open source toolchain;
Frans-William already figured out most of the stuff about how to read/write via SPI...

Nexus said...

The BlueCore4-Ext is cheap that why very popular Bluetooth chip used in many Bluetooth module

Anatoly Kravchenko said...

Hi! I liked your article about bluetooch. I want to get your advice. Please tell me the mail. Привет ! Мне понравились твои статьи про bluetooch. Я хочу получить твою консультацию. Пожалуйста ответь мне на почту.
kabcpc(a)gmail(.)com

Raúl de Pablos Martín said...

Hi pfalcon!

I'm looking inside your code because I want to develope a new firmware for Bluecore4 as you did, but focused on improve HC-04/05... modules.
I succedded compiling your code but I'm not able to get it running on the core. Could you give me any guideline? Thanks!!!
(raulmerlin at gmail)

Unknown said...

You mentioned future features:
I2C/1-wire support to connect external sensors.

I was wondering if this had been updated by you or anyone else? Adding support for external sensors would be amazing. If you are too busy, I would appreciate it if you let me know.
Best Regards
Carlos

Unknown said...

Hi,

From where can i get the OS documentation? Where would be the point in beginng to use I2C? Is It possible to store user Data in der flash and manipulate it from the Applikation?

Thanks for your effort!

Alex B said...

Heh, I've been working with these modules for a while, but the CSR license(s) didn't sound very friendly towards open-sourcing.

I'm using the UART for 1-wire master (as described here: http://www.maximintegrated.com/app-notes/index.mvp/id/214 ). The bluecore's delays weren't accurate enough for software bit-banging (and the VM model probably doesn't help, either).

I also use a custom spilpt.dll which talks MPSSE to a FTDI FT2232 for programming the modules. This can be done from wine under Linux (and the IDE mostly runs fine there, too). I wasn't aware of the CsrSpiDrivers project on github (thanks, Hillel!) which looks similar, even more polished. I'll see if can get my stuff published.

Alan Carvalho de Assis said...

Hi pfalcon,

Did you notice that CSR ships the BlueLab with gcc-3.3 patches inside it?

I installed BlueLab 4.1 using wine on Linux and notice it put the gcc patch inside BlueLab41/src/gcc/csr-gcc-3.3.3-29-xap-patch.tar.gz

In this patch has a README file explaning how to compile. Unfortunately some files like ld.exe and ar.exe are binary only and you need to copy it to install_dir.

Then even if CSR didn't release it to the public in a formal way, at least it was always there.

BR,

Alan

pfalcon said...

Alan:

Surely it always has been there, and everyone always knew that. Those who didn't, could read about it on internets, e.g. here: https://github.com/pfalcon/blutunode/wiki

Please bring us some real news, like that someone exercised rights given to him/her by GPL and released those sources to the public. Thanks.

Alan Carvalho de Assis said...

pfalcon,

Thank you for this info.

I was aware of your wiki, but there is not any hint explaining the gcc toolchain source code was accessible just after installing the BlueLab.

Do you think there is some legal issue if I put this source code of gcc toolchain in the internet (github)?

It needs some fixes to compile with new gcc (i.e 4.8).

BR,

Alan

pfalcon said...

If you got your copy of BlueLab legally, I don't think there can be any (reasonable) legal issues. For example, I had a quick exchange with a guy who, while wondering a hardware flee market, found a box with Bluecore devel board and CD, and legally bought it for some $20. I encouraged that guy to extract gcc archive and put it online, but never heard back from him.

I personally had access to BlueLab via my friends, and don't think it would have been ethical to "release" anything behind their backs, and they were not interested in that as they paid full price for it and possibly had private contracts with a supplier.

Alan Carvalho de Assis said...

Hi pfalcon,

I uploaded the toolchain source code to github:

https://github.com/acassis/xap-gcc

I'm releasing the GPL code that CSR "forgot" to release.

Now I need to fix compilation when using a recent gcc version and try to use xap-tools as assembler.

BR,

Alan

Nicked said...

thanks for the tool chain, I am not sure how useful it is without the libraries, the CSR architecture is kind of persnickety, it has a quasi protected mode that isolated the Bluetooth stack from the user stack, and with access to the event handler I would not be sure how to get the thing to work.

pfalcon said...

Alan: thanks for that git repo, I added link to my wiki page. So, we made another incremental step towards better open-source support for XAP/BlueCore MCUs, but yes, as pointed by Nicked, there would be much more work before one could "just use it". Let's hope that more people will get interested in that though, and progress will continue.

Unknown said...

Hey pfalcon, how did you get started with programming these BC417 modules? I have Bluelab and a SPI progammer. I've tried flashing the examples provided but I have no idea how to proceed from there: how to use HCI, UART to communicate with the flashed chip, how to write Bluecore applications... Any suggestions on how to get started?

Unknown said...

Hi,

I got a Raspberry PI / HC05 hook up working
and seem to be able to read the flash. I started a very crude page on
this:

http://members.efn.org/~rick/work/rpi.csr.html

The only thing is, I have no
clue if what I'm reading is correct. Here is the first chunk

root@raspberrypi:/home/pi/scripts# hexdump dump.bin
0000000 0000 0300 0000 1800 0f10 f0ff 0000 0000
0000010 0000 0000 0000 0000 0002 0000 0000 1c50
0000020 49b7 0036 0000 0002 0024 0024 0024 0024
0000030 0024 0000 aa0a 20dc 0414 1110 1e19 006a
0000040 0000 0006 8b9e 0033 ab0a 0014 0001 0000
0000050 0000 0000 8b9e 0033 0001 006e 0000 0000

Note that I'm including the first 5 bytes that make up the
1. command 2 address (2 bytes) and check word (2 bytes) so really the
first byte of the flash is at offset 5.

One thing I'm confused about is the address, it's only 16 bits but
the range of the flash is 0-0x100000 (1 MB) which takes 3 bytes. So
does that mean you need to stream out the whole 1MB in one chunk?

Thanks,

Rick

Hillel Chimowicz said...

Hi rick, awesome project! GL!,
I Think you'd better compare your dump results with the result using an arduino+CSR BlueCore flashing tools + Frans-william dll replacment for the LPT...
https://github.com/Frans-Willem/CsrSpiDrivers

Unknown said...

Rather than go through all the effort I was hoping someone could tell me if the first few words of the dump above looks correct. Here is the dump of just the flash contents. Thanks for any help.

Rick

root@raspberrypi:/home/pi/scripts# hexdump dump7.bin | head
0000000 0000 1018 ff0f 00f0 0000 0000 0000 0000
0000010 0000 0200 0000 0000 5000 b71c 3649 0000
0000020 0200 2400 2400 2400 2400 2400 0000 0200
0000030 c0aa 1420 1004 1911 6a1e 0000 0600 9e00

Nicked said...

If you post some code I will compile and run it. then send you the complete binaries .

Unknown said...

Okay, thanks much for the offer. At this point I'd just like to be able to read the contents of the flash.

Does anyone know what the memory map of the flash looks like? There are two files, the xpv (program space) and xdv (data space) that make up the flash. Is the data space stored at offset 0 of the flash and the program space at offset 64Kwords? Thanks.

pfalcon said...

> I was hoping someone could tell me if the first few words of the dump above looks correct.

I looked thru the dumps I have, and nope, your bytes don't resemble beginning of anything I have.

I hope you also understand that xpv and xdv is pretty high-level stuff and don't represent entire flash physical structure.

I have entire flash dump, and FYI, first 512 bytes are 0xff. Anyway, these comments are not good way to do research/communication, so if you're seriously into wasting your time on that, I suggest setting up wiki and/or maillist.

Seventh Synergy said...

Thanks Paul

This is a really interesting project.

I built the parallel port programmer some time ago, but have not tested flashing your code onto my module yet.

Keep up the good work ;-)

Cheers

Roger Clark
www.rogerclark.net

gu222 said...

Keep this alive! Lets make wiki! Let me know how I can help...

pfalcon said...

If you read previous comments, you know about importance of having open-source compiler for XAP. Feel free to help with that.

Davide Depau said...

Hi pfalcon,
I came to this article looking for an open source firmware for HC-05 bluetooth module. I'm not sure whether it works for that chip, however I was wondering if it could be used to make it behave like a bluetooth keyboard. I have an old laptop keyboard and some microcontrollers, I wanted to make the microcontroller receive input from the keyboard and send it to a computer over Bluetooth.

Do you think this is possible? I haven't looked at the code yet.

Hillel Chimowicz said...

Davideddu, What you need is a Module with a supporting bluetooth stack able to serve a HID (Human interface device) bluetooth profile. Hardware-wise, the HC-05 Is completly capable of running such service. But unfortunotly, softare cirtually all of these devices only produce SPP (Serial port profile).
You might be able to 'hack it around' using BlueLab41(CSR BlueLab 4.1) environment and achieve what you're looking to do with processes similar to described here (Hebrew :/) ( http://www.makers.co.il/mfs/showthread.php?t=91 ) Utilizing Frans-williams SPI drivers (https://github.com/Frans-Willem/CsrSpiDrivers) to flash the chip once developed under BlueLab or some other derivative.

Unknown said...

It is enough just to change the corresponding key through PSTools marked as UART.