Is HLF brand legit?

[kgavionics]

Hello
I created this custom stereo digital volume control  that I hooked to my stm32 black pill, but I'm struggling to make it work! I wrote my bare metal I2C driver, which works with other I2c peripherals, but not with this one. As a matter of fact, I get no I2C activity on my oscilloscope (Both SDA and SCL line stay high). I think that the HLF PT2258 is fake, because I soon I plug an audio source, I get a sound output, but no attenuation!
Do you think that this brand is legit ? Do you have any previous experience with this brand?
Thanks in advance

[SiliconWizard]

The reference is legit, but the vendor doesn't seem to be. The original part: http://www.princeton.com.tw/en-us/products/multimediaaudioic/electronicvolumecontroller.aspx
(PTC)

You probably got this part from Aliexpress or the like. Who knows what this part really is then.

I suppose you have the above datasheet and followed it?

[wraper]

It's made by Shenzhen honglifa Electronics, have no idea how good of a clone it is. However if it was an outright fake, you would get no audio output at all.

[wraper]

Also code2 and code2 pins must be properly connected according to how you address the chip. And your soldering and PCB are dodgy enough that you cannot be sure that pins make a proper electrical contact. I would not suspect the chip as the main possible culprit considering how dodgy your implementation is. None of decoupling capacitors are used either.

[8goran8]

What is your PT2258 power supply voltage? Which pins are you using for i2c?

[kgavionics]

All the connections where tested and are good, so maybe the pcb doesn't look good, but should work!
Regarding the decoupling cap it's there .On top of that a decoupling cap is not gonna prevent the circuit from working.Furthermore, the circuit was build on bread board and it's not working either.
The circuit is 5v  powered.
I forgot to mention that I followed the schematic on the datasheet and the IC address is 88H.
I'm using Pin 6 and 7 ( SDA and SCL).

[wraper]

Regarding the decoupling cap it's there .On top of that a decoupling cap is not gonna prevent the circuit from working.

Unless it's on the bottom side, there is none. Saying that a quite fast digital circuit should work without a decoupling cap is quite optimistic. It could, but far from guaranteed.

[kgavionics]

You think 100khz is fast?

[8goran8]

Have you complied with the i2c bus initialization time of at least 200-300ms?

"After Power is turned ON, PT2258 needs to wait for a short time in order to insure stability. The waiting
time period for PT2258 to send I 2 C Bus Signal is at least 200ms. If the waiting time period is less than
200ms, I 2 C Control may fail."

[wraper]

You think 100khz is fast?

Square wave has rise/fall times way faster than 100kHz frequency of I2C, which is not slow either.

[kgavionics]

Have you complied with the i2c bus initialization time of at least 200-300ms?

"After Power is turned ON, PT2258 needs to wait for a short time in order to insure stability. The waiting
time period for PT2258 to send I 2 C Bus Signal is at least 200ms. If the waiting time period is less than
200ms, I 2 C Control may fail."

yes, I did !
By the way, this is my code:

Code: [Select]

#include<stm32f401xc.h>
#define SLAVE_ADDR 0x88   
#define PT2258_CMD_RESET 0xc0
#define PT2258_CMD_UNMUTE 0xf8
#define PT2258_CMD_MUTE 0xf9



void delay_ms(uint16_t t);

void I2C1_init(void);
int pt2258_send_att(char saddr, char byte1, char byte2);
int pt2258_command(char saddr, char command);

int main(void)

{

    I2C1_init();
    delay_ms(300); // delay after power on to allow pt2258 to initialize properly
    pt2258_command(SLAVE_ADDR,PT2258_CMD_RESET ); // 0XC0 IS A COMMAND TO CLEAR THE INTERNAL PT2258 REGISTER
    pt2258_send_att(SLAVE_ADDR,0x84,0x80); // Send -40 dB attenuation to channel 1
   pt2258_send_att(SLAVE_ADDR,0x44,0x80); // Send -40  dB attenuation to channel 2

    while(1)
    {

    }
}

This is the pt2258 board schematic:

[SiliconWizard]

Now that reminds me of another post? Do I remember right?

Was this chip not requiring that you send the attenuation in 2 successive commands, one for a 10dB-step value and one for a 1dB-step value? Was it this chip?
If so, I do remember this point. You apparently are not sending both values for each channel, so the chip doesn't take the change into account.

[kgavionics]

Now that reminds me of another post? Do I remember right?

Was this chip not requiring that you send the attenuation in 2 successive commands, one for a 10dB-step value and one for a 1dB-step value? Was it this chip?
If so, I do remember this point. You apparently are not sending both values for each channel, so the chip doesn't take the change into account.

   pt2258_send_att(SLAVE_ADDR,0x84,0x80); // Send -40 dB attenuation to channel 1
You're right man! But I'm sending -40 dB in the first byte which is 0x84 then I'm sending a 0 dB  (0x80) in the second byte  then I'm sending a stop bit. See attached image
According to datasheet, there's no command to send an attenuation value to more than one channel in the same time (except mute command), so you have to send the attenuation separately to each channel.

[SiliconWizard]

OK, so that was "hidden" in your pt2258_send_att() function.

Can you try the "MUTE" command - which should mute all channels - to see if the chip reacts at all to the commands you send?

Ideally, if you have a scope, you should take a look at the I2C signals and see what happens on the bus. In particular, whether the chip does acknowledge anything you send.

[kgavionics]

OK, so that was "hidden" in your pt2258_send_att() function.

Can you try the "MUTE" command - which should mute all channels - to see if the chip reacts at all to the commands you send?

I already tried that, but It didn't work!
what surprises me, that the board it's outputting sound even  if I disconnect the SCL and SDA lines! It's like there is no I2C communication at all between the MCU and the PT2258. I even checked single connection on the board and I didn't find any fault! On top of that, the I2C driver code it's working with the other I2C peripherals (with a little modification of course)  , like the PCF8574 IC.
I'm going to hook my scope again and see what's going on!

[SiliconWizard]

Double-check the I2C address. It's sometimes confusing depending on what you're using for driving I2C (a vendor library, your own access to registers, ...) It's a 7-bit address but that needs to be left-shifted, and then add the R/W bit in position 0. Might be obvious to you, but that's a common issue.

[8goran8]

I'm going to hook my scope again and see what's going on!

Please, check bus activity on your scope regarding PT2258 power on. Maybe your delay_ms routine is not good.

[kgavionics]

This is the signal I got! It looks weird to me. I sent 0x88 address, but it looks like is 0x10 according to the screenshot( shot right after startup or reset state) !
Honestly, I have no clue, why I'm getting this!!
The delay routine is not the culprit, because I increased the delay up to 2s and I have still the same issue!

[ebclr]

Apparently the no legit thing is the piece behind the solder 

[kgavionics]

If you are trying to be funny,you're  not!
As I said before, the PCB doesn't look good because, it was made for fast prototyping purpose,but the finl product will be different!
Furthermore, every single connection was tested and it's good! Do you understand that?

[8goran8]

Can you post the code for I2C1_init()?
I think the pt2258 address is not written correctly in the OAR1 register.

[newbrain]

This is the signal I got! It looks weird to me. I sent 0x88 address, but it looks like is 0x10 according to the screenshot

Then try sending 0x44 as address - 0x10 looks very much like 0x88 << 1, doesn't it?

Heed the advice that SiliconWizard provided!

Double-check the I2C address. It's sometimes confusing depending on what you're using for driving I2C (a vendor library, your own access to registers, ...) It's a 7-bit address but that needs to be left-shifted, and then add the R/W bit in position 0. Might be obvious to you, but that's a common issue.

[kgavionics]

This is the signal I got! It looks weird to me. I sent 0x88 address, but it looks like is 0x10 according to the screenshot

Then try sending 0x44 as address - 0x10 looks very much like 0x88 << 1, doesn't it?

Heed the advice that SiliconWizard provided!

As it may sound weird, sending the address to 0x44, got the circuit working (the IC address is still 0x88). I have no idea why it's happening yet, though!
Thank you very much newbrain for the trick! but I have to figure out why this is happening, because it's only happening for the address, not the data!

[SiliconWizard]

You need to show us the code that handles the I2C peripheral. It probably shifts the I2C address by 1, as I hinted earlier, since I2C addresses are 7-bit but the actual transmitted *byte* is the address (MSb first) and the R/W bit.

And glad you got it to work.

[gamalot]

Read this: https://www.i2c-bus.org/addressing/