Close

Reflashing I2C EEPROMs while hacking an OVC3860 Bluetooth adapter

A project log for Raspberry Pi portable workbench(Project Christoph)

Raspberry Pi+prototyping shield+sockets&cables&software to hold it all together to do all sorts of EE things.

aryaArya 03/14/2016 at 19:303 Comments

I've got a friend who makes a living making custom speaker systems/headphones/laser cut things, and as with many fields today, it's got a lot to do with electronics. Many of the things he does are one-offs, thus, it makes sense to re-purpose some Chinese boards sometimes just for the sake of adding a feature. Think "Hey, maybe you could add Bluetooth to those speakers of mine?" And that's exactly what one of my "workdays" was about recently.

There it is. A board he had spare, from an adapter which plugs into one of those iPod/iPhone docks which have built-in speakers, receives audio through Bluetooth and streams it to the said dock. Some of those docks have decent enough sound quality, thus it makes sense to add adapters, and some of those are just lacking Bluetooth, as we know, everything's better with Bluetooth. In the end, why have a dock that's suitable for your iPod but not for your Android phone?

Anyway, he didn't need that adapter and it was suitable for the task. Normally, it would just be a simple job of soldering a couple of wires and leaving it inside the speaker - just look at these testpoints!

But then, it wouldn't need me if it were so easy. He also wanted the adapter Bluetooth name replaced, since, you know, he's producing one-offs and putting his brand name on them so that people come and see - he's put a lot of work in these, and he really does - except for BT adapters, where it's no sense to reinvent the wheel. It'd be all good, but "I-WAVE" is not really his brand name, and it's not even nice-looking. Moreover, there wasn't really any process for changing it - as you can imagine with a custom product not even intended to be disassembled, not to mention soldered to.

Yes, that chip on the left side has all the markings erased. Those dicks, why'd you do that? I don't even understand what it does. It doesn't seem to work with USB, and yet it seems to be connected to the 30-pin connector. It seems to be some kind of PIC, Chinese manufacturers love thise and placement of VCC/GND pins seems like it. Also, it might be connected to the OVC3860's UART.
The OVC3860 seems to have been featured on Hackaday one time, and it seems it accepts custom AT commands. It also is available on more hackable modules that are intended to be connected to *duinos and such - here's one guy doing basically the same hack as me, and there seemed to be a nice forum thread ot two about it too. But whatever, I discovered them only later somehow, that's why you do your Google homework properly before hacking =D
I had to take a closer look:

Sorry for bad pics (that's the best camera I have). Anyway, if you don't see a 24C08 EEPROM, you'll have to take my word for it. And what's the best place for storing such things other than EEPROM?

Now, let's return to my workbench. As you can see, the shield has the I2C pins broken out (this is not my shield, it's an exact copy though):

Great. The only problem is alleged 5V-only operation, but AFAIK some 5V devices like this work on 3.3V, they just aren't tested on this. Anyway, I'll plug a male header in the 3V3-UART-I2C 2.54 female header and just solder wires to it:

That way, I can plug/unplug this chip whenever I want. I also can add a female header to the board the EEPROM was soldered to, to avoid soldering the chip to the board every time I need to test a new firmware image:

Now let's load dev-i2c, deadbug the EEPROM on wires the same way it was connected on the board, connect its VCC to the 3V3 supply and see if it's OK with 3V3, at least for basic operation:

root@raspberrypi:~# i2cdetect -y -a 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Yes, it is. There are 4 addresses, and, funnily enough, each of them is mapped to a 256-byte section of this 1 Kilobyte EEPROM.
Now, there are nice tutorials for RPi+I2C EEPROMs. I used this one with great success, and that means using eeprog software. I had to make&make install it, but it went great.
That's what I found out after half an hour of searching the BT address in the first section, which read like this:

.????.?????? ??.
.???.??.?&?X?.??
???.??$?.../.>?v
??? ? ..?`.?????
'??|.?.....?.???
????????"?.B X$Y
(Z.z.?.?.?????.|
?7?Yf...0???..??
???..?.?9?@.??(f
??.?@r??.??.??x?
?.0._???.???????
????wwww???@?..?
.????????? 0%.Q?
... ?????P ???0?
??.....???Z??.??
"&?.???.????"2?.

After the realisation about the address-to-space mapping, I read data from all of the addresses and pieced the dump together:

.????.?????? ??.
.???.??.?&?X?.??
???.??$?.../.>?v
??? ? ..?`.?????
'??|.?.....?.???
????????"?.B X$Y
(Z.z.?.?.?????.|
?7?Yf...0???..??
???..?.?9?@.??(f
??.?@r??.??.??x?
?.0._???.???????
????wwww???@?..?
.????????? 0%.Q?
... ?????P ???0?
??.....???Z??.??
"&?.???.????"2?.
??&(?.??????????
?.???.?.???.?.??
?.?.???<?.???<?.
???????..??...??
?..????.????.???
..????.???..????
.???...???.?????
c??? ??5????.???
.?????.????,????
? ????..???X.???
???.???????#?.?{
.2.??? ?=?.UU..0
000....I-WAVE.xx
.?????? ???.??.?
..?.?.}..?...QRR
Q..?@.?.????????
.????fU.-?AJ????
?@???l?{??.???.x
}??w?E??????P???
l??2?????t???^-1
B`+?????#J?Q4??+
.^??,???X?[ea?0?
?1????????????"?
M????(e???.j.??;
-??8>\(?4???a}??
????n?????eb??X@
??..............
.........a}????!
??9911`.??.i.?..
......?i.??.?.9i
.??.?...........
................
................
................
................
..........!??...
................
................
................
................
................
..xG?F.????./???
?.???h?(???h?(??
?H.x?(??? .??.??
???G..??.???Hy??
???(???*??? .??.
????. ?G..?????.
..    ..........

Much better. You see that bit with I-WAVE? Here's how it looks like in binary:

c0: 30 30 30 00 ff ff ff 49 2d 57 41 56 45 00 78 78    000....I-WAVE.xx

Unless there are checksums (well, who needs them on a freaking cheap BT adapter?), we've got at least 6 characters we can change as we wish - and maybe more, depends on how the bytes in front of the name and after it can be treated. So I decided to test it with a shorter name (Russian-speaking people reading this, forgive me for an immature name):

Wonderful. Friend was happy too. Then I decided to check if the two following bytes (reading 78 78) could be overwritten:

Yes, they could. Erasing those two 78 bytes could have broken some aspect of this chip's firmware (I didn't yet test the audio, after all), but that proves it's searching for the null terminator, as @charliex suggested in the #Hacker Channel. I also wonder if preceding FF bytes can be erased... Yet to be tested. Names longer than 6 ASCII characters are still more like POC for me, but it's nevertheless a fun hack. I look forward to branding one in my nickname, making it more universal with i.e. a 3.5mm socket and similar features and making it a part of my toolkit - if only I had a necessity... =D There's even an article from which you can get general tips on improving this module's efficiency. Also, UART of this adapter are still unused - but I don't need them as for now, too. Maybe someday later.
My setup - I was not at home while doing all of this, I just bring all the tools with me:

One more capability to my Raspberry Pi programmer. Maybe one day I can start selling those as kits/full units on eBay =)

Discussions

evan07 wrote 09/15/2018 at 17:30 point

Some description to the transfer protocol described above. I send AT#MX commads and there was no reply. Then I used OVC3860 Programming tool. First of all this programm works only with COM1. It don't work with any adapters - so only straight COM1. I hacked transfer protocol (see it above). The point is that device send <04 0F 04 00 01 00 00> and waiting for some miliseconds (IMPORTANT!! - U cannot do it by hands - delay will be very big and device will skip enterening programm mode) for reply from PC <C5 C7 C7 C9 D0 D7 C9 D1 CD>. Then it enters programming mode and time is no matter after that. Now U can change NAME, PASSWORD, and all other parameters.  Transfer speed is 115200.

  Are you sure? yes | no

evan07 wrote 09/15/2018 at 13:43 point

Real protocol:  HEX values:

From OVC: 2018-09-15 15:55:00,6266275 +5,4945292

 04 0F 04 00 01 00 00
 
From PC: 2018-09-15 15:55:00,9013496 +0,0000120

 C5 C7 C7 C9 D0 D7 C9 D1 CD 
 
Answer from OVC: 2018-09-15 15:55:00,9032590 +0,0018052

 04 0F 04 01 01 00 00

----------------------------------------------------------------

From PC (read NAME): 2018-09-15 15:55:34,3838654 +33,4730967

 11 C7 00 10  

Answer from OVC (NAME is “LPAIS_blue”): 2018-09-15 15:55:34,3914584 +0,0000377

 21 C7 00 10 4C 50 41 49 53 5F 62 6C 75 65 00 FF FF FF FF FF

----------------------------------------------------------------

From PC (write NAME “LpaisBlue”): 2018-09-15 16:09:58,9552702 +43,6714309

 31 C7 00 10 4C 70 61 69 73 42 6C 75 65 00 FF FF FF FF FF

Answer from OVC: 2018-09-15 16:09:58,9779393 +0,0053315

 41 C7 00 10 

----------------------------------------------------------------

From PC (read PASSWORD): 2018-09-15 15:55:59,8614883 +25,4570789

 11 BF 00 08  

Answer from OVC (PASSWORD is “0000”):  2018-09-15 15:55:59,8689466 +0,0000080

 21 BF 00 08 30 30 30 30 00 FF FF FF 

----------------------------------------------------------------

From PC (write PASSWORD “1234”): 2018-09-15 15:56:29,8251861 +29,9446977

 31 BF 00 08 31 32 33 34 00 FF FF FF

Answer from OVC: 2018-09-15 15:56:29,8446201 +0,0140072

 41 BF 00 08

----------------------------------------------------------------

From PC (read PASSWORD): 000071: 2018-09-15 15:56:43,4235981 +13,5768873

 11 BF 00 08

Answer from OVC (PASSWORD is “1234”):   2018-09-15 15:56:43,4288520 +0,0000031

 21 BF 00 08 31 32 33 34 00 FF FF FF

 

 

 

 

 

 

  Are you sure? yes | no

Phillip Remaker wrote 10/08/2017 at 16:14 point

Thank you for taking the time to write this up! This was extremely useful to me. While your direct programming method was effective, you could have also changed the name by using the OVC 3860 toolkit and the 3.3V RS-232 interface. Using the data from this blog and the data from https://kovo-blog.blogspot.com/2016/01/ovc3860-how-to-change-name.html and your superbly detailed writeup, I was able to change the name of my device and write up my own experience at  http://lab.remaker.com/2017/10/i-link-bluetooth-change-bluetooth-name.html. I pointed to your blog and borrowed your photos. Let me know if you have any problem with that. 

Thanks again for the work!

  Are you sure? yes | no