Who know the protocol between MSP430F2013 and DM365 for IR remote controller decode result?

Willy Chen said:

I need to replace the MSP430F2013 MCU on DM365EVM to another MCU for IR remote controller decode

I am hoping you are replacing it with another type of MSP430? That will certainly make your job easier as the sources are somewhat tied to MSP430 since they are so low level and there are many other MSP430 options out there that might be more suitable to your needs if the F2013 is not.

Willy Chen said:

Is there anyone know the protocol between MSP430 and DM365? or any descriptions for the encoded data meanings over I2C?

For starters you could examine the MSP430 sources that are available at the bottom of this page which are being used on the DM365 EVM. You can find some more information about how the MSP430 was implemented on the original DM6446 Davinci EVM here, I believe most of it still applies to the DM365 implementation, if not all of it.

Dear Bernie,

Thanks for your kindly reply, that's help a lot. Actually, I want to replace the MSP430 MCU to another brand of MCU because of the cost and also I had been used to that MCU for many IR remote controller's decoder ( most NEC code ). The descriptions I found in "DM6446 Davinci EVM MSP430 I2C COMMAND" look different to the data I checked in my MD365EVM. When I use a Digital Storage Scope to check the I2C signal between MPS430 and DM365EVM while I press the Philips IR RC "Play" key, the MSP430 got a Write command with only one data field "01" without any other data followed . And then MSP430 respond to a Read command for only 2 byte data "75 31" or "75 39". But I check the RC code by scope, if it is the RC5 coded, it look like "11000101110101"; When I press "Pause" key, the I2C got read data "B4 38" for the "01" write command, But the RC code on scope, I got "11000101101001". So I am all confused to the encoded method by MSP430, what it do to the RC code. If I do not know the method, then I even can not replace the MCU and change the IR RC to NEC code format.

By the way, the descriptions on "Davinci EVM Support Home" about the RC5, there are differences between "RC5 format" and "RC5 codes" these 2 links. On "RC5 format" link, it says "2 start bits, 1 toggle bit, 5 address bits, 6 command bits"; but in the "RC5 codes" link, it says 13 bit code, 5 bits group, 6 bits command, 2 stop bit". that's a big different, which one is correct? Should I count from start bit then the others in receive sequence or start from group bits and ended by stop bits in receive sequence?

Willy

Dear all,

Now I found the problem, it should be the bug in MSP430 firmware. I think the firmware(the one on DM365EVM) is only for demo use, not for commercial usage. The program can only decode RC5 IR code, but not NEC code. The IR remote controller come along with the DM365EVM can switch to NEC code if press "SAT" button. In this mode, MSP430 will decode and send wrong I2C data back to DM365. After that, press "DVD" button to switch back to RC5 mode, but the MSP430 still continue decode to wrong data and send back. After some "training", I press key again and again and again, finally the MSP430 firmware decode a correct data. But I found even not switch to NEC code, if you do not press any key for a while, MSP430 still decode wrong data for the first several keys you press. You can check this by digital storage scope, watch the IR signal and I2C bus at the same time, you will find that sometimes I2C data was sent out before the IR signal ended. It means the MSP430 firmware not work correctly, it should be some initial state not complete before the IR first bit come in, so it count wrong bits. And also it will be affected by NEC or other format IR code and also daylight, MSP430 firmware did not check it out and filter them. So the firmware of MSP430 should be re-write for commercial usage, or replaced to another "cheaper" MCU for cost down.

Willy

Willy Chen said:

I think the firmware(the one on DM365EVM) is only for demo use, not for commercial usage.

This is generally true for the Davinci EVMs like the DM365 EVM, they are put together early in the chip development process to have a platform as early as possible and prove the device works, they are not meant to be formal hardened reference designs. This being said, the MSP430 code is not formally supported, however the sources used are provided, so if you want to modify its operation or fix any problems you can do so. I would not be surprised if there are bugs in the code (one could say that about any significant code base), however I have only used it with the remote in 'DVD' mode of the remote which generally works for me.