HP3548 / HP3457 OLED display

[hvontres]

Are the I2C pins pulled up inside the Controller? If not, I there should be a 4.7k resistor to the 3.3V rail on SCL and all of the SDA lines to make it work correctly.

[Miti]

Are the I2C pins pulled up inside the Controller? If not, I there should be a 4.7k resistor to the 3.3V rail on SCL and all of the SDA lines to make it work correctly.

Well, technically, if you have only one master on the I2C bus, you only write to de slaves and don't read back and ignore the acknowledge, you don't need pull-ups. I assume this is the case in our schematic.

[Miti]

Here's the I2C line for one of the OLEDs. It looks very clean and the ssd1306_init sequence seems to be correct, as far as I can decode since Rigol can only decode what's on the screen. Also looks like the data line is push-pull and switches to internal pull-up for the acknowledge. Very nice, very clean signal.
I've also attached some data sent after the init and the address is correct, the data I assume is correct since it needs a lot of digging through the code to understand.
The investigation continues...

[Miti]

On second look, it is not as clean as I thought. Do you see the collision? When the last bit is high, before the master SDA changes to input, the master pulls high, the slave pulls low to acknowledge, therefore it makes a 2+ uS short. Meeeeh, not big deal, whatever works. This is not my problem though.

[Miti]

Actually I can see partial segments but they seem to be in wrong orientation. Are these OLEDs duds? It is a new batch after they went zero stock. Or did they start using a different controller without changing the datasheet? Hmmm...

[robert.rozee]

please try putting the 4.7k pullup resistors on SCL and SDA lines, then report back what happens...

cheers,
rob   :-)

[Miti]

please try putting the 4.7k pullup resistors on SCL and SDA lines, then report back what happens...

cheers,
rob   :-)

Hi Rob,

Can you please explain what is your suspicion? Looking at the screen shots from the scope I don’t think it is necessary.

[eliocor]

from the last* scope capture it seems to me the pull-up is too weak and it would be a first (IMHO) that an I²C bus can work RELIABLY without the pull-up resistors!
Please post a scope capture/decode of a SINGLE byte at much higher time resolution.

*) the resolution is too low, but it seems to me that the same problem happens even on the other captures you posted

[robert.rozee]

please try putting the 4.7k pullup resistors on SCL and SDA lines, then report back what happens...

cheers,
rob   :-)

Hi Rob,

Can you please explain what is your suspicion? Looking at the screen shots from the scope I don’t think it is necessary.

it is a quick and simple test that eliminates one branch of inquiry.


cheers,
rob   :-)

[Miti]

No, it's not a first, actually other than the short collision when the last bit is 1, the implementation is ok.
I can post a better resolution screen shot but picture DS1Z_QuickPrint21 shows very clear what happens before, after and during the acknowledge.
Let me explain:
1. It is the falling edge of clock pulse #8 when the slave pulls SDA low to acknowledge the previous byte. However, the MCU SDA output is still a push-pull pulling up, hence the collision. Not ideal but it does not cause any data corruption. It doesn't happen if the last bit is 0
2. The MCU switches the SDA pin from push-pull output to digital input to read the ACK and the collision ends.
3. It is the falling edge of ACK pulse #9 and the slave releases the SDA. The SDA pin from the MCU is still digital input with weak pull-up enabled, that's why it is slow to go high but nothing happens at that time so it doesn't matter.
4. The MCU SDA pin switches from digital input to push-pull output again. See the strong pull to high (1) which was the last bit before ACK.
5. MCU pulls the SDA pin to low, the first bit from the next byte.
6. 7. The first two clocks from the next byte with SDA low.
8. The third bit with SDA high.

The CLK line also doesn't have a pull up resistor since it is push-pull as well. The CLK and SDA signal are as clean as before 1 and after 4 all the time. It works for Terra and for Xyphro so it must be good. The standard I2C architecture is for multi master, multi slave, etc. I hope it is clear now.

[eliocor]

To my knowledge, the I²C Standard tells something different:

3.1.1 SDA and SCL signals

Both SDA and SCL are bidirectional lines, connected to a positive supply voltage via a current-source or pull-up resistor (see Figure 3). When the bus is free, both lines are HIGH. The output stages of devices connected to the bus must have an open-drain or open-collector to perform the wired-AND function. Data on the I2C-bus can be transferred at rates of up to 100 kbit/s in the Standard-mode, up to 400 kbit/s in the Fast-mode, up to 1 Mbit/s in Fast-mode Plus, or up to 3.4 Mbit/s in the High-speed mode. The bus capacitance limits the number of interfaces connected to the bus.
For a single controller application, the controller’s SCL output can be a push-pull driver design if there are no devices on the bus which would stretch the clock.

[robert.rozee]

is the I²C being bit-banged by the processor?


cheers,
rob   :-)

[Miti]

is the I²C being bit-banged by the processor?


cheers,
rob   :-)

Yes, how else? Atmega8 has only one proper I2C bus. If you want 12 you’ll have to “bang” them.

[Miti]

I have an idea how to check if/ prove that the I2C is ok and the commands get to the OLEDs. There is an A5h (Entire Display ON) command which I will send, followed by a long delay. That should clear the HW question.

[robert.rozee]

is the I²C being bit-banged by the processor?

Yes

i'm sure it couldn't possibly be so simple, but... is the SCL line inverted?

i'm assuming here that there is just the one SCL line driving all 12 displays simultaneously.

cheers,
rob   :-)

[Miti]

Ok, as expected, if I send pari2c_writebyte_bc(0xa5); right before pari2c_stop(); in the oled.c ssd1306_init() function, I get half screen on. If I also change the offset to 0x30, the entire display turns on. That means that the I2C goes through. Can anybody with experience in displays figure out what is happening or I need to study the CH1115 datasheet and try to understand how to address the memory? Why doesn't it work the same as for Xyphro or TERRA? Does it need all 12 OLEDs, otherwise it detects missing ACK?
Why am I special? My mom told me, my wife tells me that I'm special... and now LCSC? I need a hug...

Edit: @ TERRA Operative, this is a good way to illuminate all the display to check the maximum current.

[Miti]

It's the stupid OLED! I've connected another type and it shows something. It is mirrored and shifted but at least I get something. Now I have to figure out how to change the program to match the hardware.  And considering how shitty the data sheet for CH1115 is... good luck!
I wonder how many different 0.87" OLEDs are there and how in the world TERRA's panel, from the same source as mine, works with Xyphro's code and mine doesn't?
Also, if you buy from Aliexpress, how can you figure out the hardware connections? I don't see a datasheet. Trial and error ad nauseam?

[TERRA Operative]

These are the exact displays I bought:

https://www.aliexpress.com/item/1005006718368237.html

I bought 125 of them and they all arrived fine. I haven't used them all, but the 3 or 4 displays I've made have all worked ok.

[Miti]

These are the exact displays I bought:

https://www.aliexpress.com/item/1005006718368237.html

I bought 125 of them and they all arrived fine. I haven't used them all, but the 3 or 4 displays I've made have all worked ok.

Ok, that explains it. They look alike but they are not. Why would you put in the BOM an LCSC part number when you used an AliExpress one?

[Kean]

These are the ones I bought (60 pcs).  Photo of the back of one is attached.
https://www.aliexpress.com/item/1005005770683719.html

The FPC specifically says "LT1316P02C JY" (so likely SSD1316) which you can almost make out in the listing photo, but the listing has the text on the back of the glass blurred out.

I will try assemble a PCB tonight and report back.  These have been on my to-do list for far too long.

Unfortunately it is always risky to put a Chinese source on the BOM, but LCSC are generally pretty good.  I didn't even see a mention of that part until you mentioned it.

[Miti]

These are the ones I bought (60 pcs).  Photo of the back of one is attached.
https://www.aliexpress.com/item/1005005770683719.html

The FPC specifically says "LT1316P02C JY" (so likely SSD1316) which you can almost make out in the listing photo, but the listing has the text on the back of the glass blurred out.

I will try assemble a PCB tonight and report back.  These have been on my to-do list for far too long.

Unfortunately it is always risky to put a Chinese source on the BOM, but LCSC are generally pretty good.  I didn't even see a mention of that part until you mentioned it.

I bought 25 pcs that I can’t return so first I will try the initi code recommended in the datasheet instead of buying new ones and writing off 48$. The initial project was coded for SSD1306, my OLEDs use CH1115. However, even with the same driver, different manufacturers may connect the OLEDs panel differently.

[Miti]

A little progress, I've tried the init sequence in the OLED manual and even though it needs more work, the current with all display fully on went down from 260mA, and most of it through 3.3V regulator  which was burning hot pretty fast, to 121mA. The explanation is that the POR status of the charge pump is internal and the command to disable it is different between chips, so the internal charge pump was sucking from 3.3V like crazy. Now both my regulators are cool and comfy. 

[TERRA Operative]

These are the exact displays I bought:

https://www.aliexpress.com/item/1005006718368237.html

I bought 125 of them and they all arrived fine. I haven't used them all, but the 3 or 4 displays I've made have all worked ok.

Ok, that explains it. They look alike but they are not. Why would you put in the BOM an LCSC part number when you used an AliExpress one?

I was planning to use the LCSC ones, but they didn't have enough in stock, so I randomly bought the Aliexpress ones which turned out to be the right type by coincidence.

[Kean]

Well, it looks like I am seeing the same random pattern on the OLEDs as Miti showed.
Voltages look OK, but current draw seems high as Miti mentioned.
Still diagnosing... but going to bed very soon.

[Kean]

OK, I fixed it.  It was the fuses.
After changing them as shown in the attached image, the 2 displays I had connected showed some beautiful digits.

I originally just flashed the hex file called HP3457Oled_HP3478_ICONS.hex - and then tried adjusting some fuses suitable for 8MHz and 3.3V, but didn't have any luck.

Opening the project in Atmel Studio (I have 7.0 installed), I noticed it started in the Debug configuration.  Compiling failed with an error that F_CPU wasn't defined.
I then changed to Release configuration where F_CPU was defined to 8000000 (under Project Properties, Toolchain, C Compiler, Symbols).

Building the Release config worked without error, and I then flashed the ATmega8L on my board using the generated elf file.
I then didn't seen any random dots on the display on power up, and after plugging into the 3478A display cable it worked.

Miti, maybe this will work for you too.  Let me know if you need any tips, but I'll be offline for at least 8 hours.

Edit: Updated image with new fuse values of DE A4 per Miti's comments.