Project Logs

Collapse

• Interrupt & voltage levels

  Stefkuhb • 11/21/2018 at 08:03 • 0 comments

  I hooked up my logic analyser and found the trigger source for the controller, it is GDO0 which I found to be connected to TP306! As you can see in the image below it (GDO0 at channel 4) becomes high and after 28 microseconds the controller starts to act.

  Great! now I can start to think of when the ESP should be listening or when the ESP should be talking. When the system gets powered the MSP configures the CC. when this is done the system goes to idle until data is received from the remote. When data is received GDO0 on the CC becomes high and the MSP responds by making the SS line low and "asking" for data.

  So the SS and INT line must be disconnected and fed through the ESP to control something. the other lines MISO, MOSI and SCK can be shared. WAIT! one little problem left: the ESP is running on 3V3 and the CC and the MSP are running on 2V8. 

  For inputs like MOSI and the CLK we are lucky because the ESP datasheet states that the voltage needed for a high level (Vih) is 0,75 times the supply voltage. 3V3 * 0,75 = 2,475 which is way lower than 2V8 so it can read the inputs. 

  The outputs like MISO, SS and INT must be lowered to 2V8 and this can be done with a voltage divider. The formula is Vout = (Vsource * R2) / (R1 + R2). To make things simple I choose R1 to be 10K and I want to know R2 so to rewrite the formula to figure out R2. R2 = (Vout * R1) / (Vsource - Vout). So R2 = (2.8 * 10000) / (3.3 - 2.8) = 28000 / 0.5 = 56000. Lucky me an 56K resistor is pretty standard!

• Initialisation

  Stefkuhb • 11/13/2018 at 18:35 • 0 comments

  So I found the lines I soldered the wires and hooked up my logic analyser. lets see what is on those lines. I turn on the livingcolors, turn the LEDs on with the remote and start logging, no data. than I start logging and I use the remote to change the color, yes data!

  This means that the controller is not polling the CC2500 for data but how does the controller know there is any data to read? The CC2500 is a slave and cant start to send data on its own, It must let the controller know it has any data. Probably there is an extra line to trigger the controller to read the data.

  In the datasheet of the CC2500 it states that there are 3 configurable pins GDO0, GDO1 and GDO2 that can be used to give a signal to the controller. The function of these pins must be configured and this probebly happens when the system is powered. So I start logging and apply power to the LivingColors, again data but now its different. The datasheet of the CC2500 explains how to read and write a register. 

  All transactions on the SPI interface start with a header byte containing a R/W bit, a burst access bit (B), and a 6-bit address (A5 – A0).
  The CSn pin must be kept low during transfers on the SPI bus. If CSn goes high during the transfer of a header byte or during read/write from/to a register, the transfer will be cancelled.

  This means when the SS (CSn) line goes low the controller sends a header byte containing an address of the register, if it is a read or write command and a burst access bit.

  The addresses for the function of GDO0, GDO1 and GDO2 are 0x00, 0x01 and 0x02. When I look at the data of my logic analyser it contains the data I'm looking for, 0x00 and 0x02, so GDO1 is not used.

  The controller writes 0x00 which is a header byte to write register 0x00 and then writes 0x06, the data for in the register. after that it writes 0x80 which means read register 0x00 and the MISO line shows 0x06 so its successfully written. 0x01 is written to register 0x02. The description of the value 0x06 for the GDOx_CFG of GDO0 is:

   Asserts when sync word has been sent / received, and de-asserts at the end of the packet. In RX, the pin will de-assert when the optional address check fails or the RX FIFO overflows. In TX the pin will de-assert if the TX FIFO underflows.

  The description of the value 0x01 for the GDOx_CFG of GDO2 is:

  Associated to the RX FIFO: Asserts when RX FIFO is filled at or above the RX FIFO threshold or the end of packet is reached. De-asserts when the RX FIFO is empty.

  I want to see if there is any signal on both GDO0 and GDO2, so I follow the signal lines on the PCB and see that both these signals have a testpad! GDO0 is connected to TP306 and GDO2 is connected to TP307. Next up: lets see when there is any signal present with my logic analyser.

• Starting to communicate

  Stefkuhb • 11/12/2018 at 15:56 • 0 comments

  Before we can start adding components I have to find out how this system works. I took apart the LivingColors gen1 and found the PCB. It looks like Phillips used a Texas Instruments CC2500 for the wireless communication with the remote and a Texas Instruments MSP430F135 as main controller. It also has 4 high power LED's and each of them has a dedicated driver.

  These IC's must be communicating somehow so lets look at the datasheet of the CC2500 which states in the product description "CC2500 can be controlled via an SPI interface". SPI often uses 4 signal lines: MOSI, MISO, SCLK and SS. If I find these lines and hook up a logic analyzer I can look at the data being send and received.

  If I look at the PCB I see that there is a pad where no part is mounted named H301 close to the MSP430F135. When I follow these lines to the controller I get the following pins:

  DVss (GND)	P3.5/URXD0
  RST	P3.3/UCLK0 (with a 330R resistor)
  TCK	P3.1/SIMO0
  TMS	P3.2/SOMI0
  TDI/TCLK	P1.7/TA2
  TDO/TDI	DVcc (2.8Vdc)

  The pins RST, TCK, TMS, TDI/TCLK and TDO,TDI are used for JTAG probebly to flash and debug the controller. 

  The UCLK, SIMO0 and SOMI0 pins are the MSP430F135 dedicated SPI pins. but I am missing the SS pin! In the datasheet it states that the STE0 pin (28) is used for SS but its not on the pads of H301.

  Lets look at the CC2500 datasheet, it states that pin 7 is the CSn (SS) line. if I follow the pcb trace of pin 7  of the  CC2500 it goes to R704 and after that to TP308.

  Great! I can solder some wire to the pads to hook up my logic analyzer!

View all 3 project logs