Display options

[novski]

For Documentation 

 

8 of my OLED SSD1306 need 108mA @ 5V/J2.

 

 

 

[Duggle]

@KUI,

Are you powering from USB?

If not, I suggest a power supply that is rated with a higher maximum current. It may be that with the electrical load of the extra bank of displays the power rail to the displays is rising too slow and interfering with their initialisation.

[TK.]

Aside from this: could you please try following release: http://www.ucapps.de/mios32/midibox_ng_v1_027_pre5.zip

 

It re-initializes all LCDs whenever the RESET_HW command is executed in the .NGC script.

Although this is a "dirty method" (which I don't like), it will result into a delayed initialisation which could help.

 

Best Regards, Thorsten.

 

P.S.: this pre-release also supports two new fonts (see CHANGELOG.txt)

[KUI]

Duggle, no to USB power I am running a 15 amp 12 volt supply.

TK, I am traveling for work till tuesday. I will test as soon as I get home.

Thanks

KUI

[Duggle]

That's a big supply.

So the regulated 5V for the OLEDs is coming from the core?

[novski]

Hi TK.

I Tested v1.027 pre5 and had dark screens on Display 4&6:

It also didn't refresh the screens after upload. so that the demo-text (SSD1306 #1-8...) stayed while the text from my .ngc file overwrote just the necessary dots... 

Also a reset command through terminal did not change the text on the displays. After re-power it worked, but display 4&6 always stay dark in my case.

 

@Duggle, my displays work with 3,3V and have a separate LF33 for each 8 displays. Both J2 (Display 1-8 and Display 9-16) are supplied by a 5V/10A Mean Well switched supply source.

 

best regards

novski

[TK.]

Apparently it was a bad idea to change two things once: pre5 has been compiled with a newer gcc version which creates faster code. I've to review the timing dependent routines...

 

In order to confirm, if this assumption is true, could you please try following build?

-> http://www.ucapps.de/mios32/midibox_ng_v1_027_pre5_oldgcc.zip

 

Best Regards, Thorsten.

[Duggle]

Novski, are you seeing the same initialisation problem as KUI?

[KUI]

<blockquote class='ipsBlockquote'data-author="Duggle" data-cid="160643" data-time="1384050925"><p>

That's a big supply.<br />

So the regulated 5V for the OLEDs is coming from the core?</p></blockquote>

Yes Duggle 3.3v for OLED comes from the core.

[TK.]

@Novski: did you test the alternative version? Does it change anything? If not, I can switch back to the new gcc (and we have to search the issue somewhere else).

 

Best Regards, Thorsten.

[novski]

@ TK. Just tested it. sorry for delay...

i can not tell. My displays somtimes work sometimes not. I realy can't tell whats when...

 

@ Duggle. Yes and no. I tend to say my error is exactly invers. Powering off for more than 10sek. is better in my case... else i have corrupted text and dots all over...

 

@both. I will try to get a scope. that will take a day or 2... 

 

best regards

novski

[novski]

@ Duggle: back to the question about CRO. wich one wold you go for: - better to have a 150MHz @ 2 GHz or a 200MHz @ 1GHz.

Thats the choices in within my budget...  :rolleyes:

best regards

novski

[Duggle]

I'm not sure of the bandwidth specs you mention. Is the second figure the sample rate? If so the first one. Otherwise the one with the bigger bandwidth (200MHz).

But either should be sufficient.

[KUI]

Apparently it was a bad idea to change two things once: pre5 has been compiled with a newer gcc version which creates faster code. I've to review the timing dependent routines...

 

In order to confirm, if this assumption is true, could you please try following build?

-> http://www.ucapps.de/mios32/midibox_ng_v1_027_pre5_oldgcc.zip

 

Best Regards, Thorsten.

Hi All,

 

This seems to fix the initialization issues for me on displays 9-16.

I can power and re power over and over and get all 16 displays to work.

 

Novski,

I had recurring corruption on all displays until I put the 100 ohms resistors in series with D0, D1 and DC between the two 8 channel display boards.

 

TK,

 

P.S. I am only home for 18hrs between shows. Be back in the game on Nov.23rd, money calls:)

 

 

I still have a little weirdness on display 16. On boot in partially displays the same text that you show on display 1.

 

 

Thanks

KUI

[TK.]

Fine! :smile:

 

Could you please also check the firmware image that I created with the new gcc version?

-> http://www.ucapps.de...v1_027_pre5.zip

 

Display #16: the CS lines of the J28 shift register are not initialized during boot, this could be the reason.

All displays should be correctly cleared after boot once the MBNG application takes over the control - can you confirm this?

 

Best Regards, Thorsten.

[KUI]

Fine! :smile:

Could you please also check the firmware image that I created with the new gcc version?

-> http://www.ucapps.de...v1_027_pre5.zip

Display #16: the CS lines of the J28 shift register are not initialized during boot, this could be the reason.

All displays should be correctly cleared after boot once the MBNG application takes over the control - can you confirm this?

Best Regards, Thorsten.

Hi Thorsten,

I can confirm that after the mbng app takes over all display are correct.

I loaded 027 pre 5 and I get displays 9-16 initializing okay. Display 4 and 6 are not working.

I then reloaded 027 5 oldgcc and all displays work correctly.

Went back and fourth 4 times to prove to myself that there was a difference.

Thanks

KUI

Edited November 13, 2013 by KUI

[novski]

I just noticed a difference between two schematics i don't understand.

My IC2 has the serial output (pin 9) open. Do i have to connect that pin somewhere? To terminate it?

I see that this register is somehow working different than a normal DOUT. Does this usage of IC2 have a name i can google?

best regards

novski

[TK.]

I loaded 027 pre 5 and I get displays 9-16 initializing okay. Display 4 and 6 are not working.

I then reloaded 027 5 oldgcc and all displays work correctly.

Went back and fourth 4 times to prove to myself that there was a difference.

 

Thanks!

Interesting that these are exactly the same displays which are failing at Novski's side. On the other hand they don't fail at my side. But: I've only 5 OLEDs connected, and use the CS line of the 5th display on CS 4..16 to test the driver. The remaining four displays are always connected to CS0..3.

 

Seems that I've to change my hardware to allow more sophisticated tests. I will do this next week (not enough time this week)

 

 

My IC2 has the serial output (pin 9) open. Do i have to connect that pin somewhere? To terminate it?

 

no, this is just an unused output

 

 

 I see that this register is somehow working different than a normal DOUT. Does this usage of IC2 have a name i can google?

 

I'm just using it as a shift register... ;-)

 

Best Regards, Thorsten.

[novski]

TK. how did you make test? I tryed to look at the D0,D1,DC signals as you did by the core and at the end of the line. But i cant isolate a pulse like i see it on your fotos...

In not sure what app i need to load to test the signals, or even what signals are relevant...

Im sorry for my amateur questions..

best regards

novski

[TK.]

I made this test with DIN/DOUT modules and superlong cables.

It isn't directly related to your issue, I only wanted to visualize what could happen (although I'm not sure if this is really a problem at your side).

 

The biggest problem is, that you are describing symptoms which I can't reproduce at my side (e.g. because I don't have your hardware), and therefore I've to try to find parts of the puzzle with assumptions and experiments... :-/

 

Meanwhile I can't exclude anymore, that my specified circuit is too criticial due to potential electrical issues.

Counter measures would be to spend more hardware, e.g. buffers for the D0 and D1 lines (e.g. for each pair of 4 OLEDs)

 

I can't say if this will really help - it would be worth a try, on the other hand your possibilities are limited since the components are soldered on a PCB.

 

But i cant isolate a pulse like i see it on your fotos...

 

so, actually these are good news. No termination issue?

 

I need some more time to think about other causes, and probably I've to do some more exotic experiments with my hardware.

Meanwhile I also hope that somebody of you makes an observation which brings us into the right direction.

 

Best Regards, Thorsten.

[TK.]

2 new ideas:
 
1) check if buffered SCLK/SDA makes a difference: http://www.ucapps.de/mbhp/mbhp_lcd_ssd1306_buffer_idea.pdf as mentioned above.
You could use a 74HCT541 for this experiment, because you probably already have this chip available for J8/9 and J19.
/edit: 74HC541 required for 3.3V
 
Each buffer output should be connected to D0/D1 of 4 OLEDs
 
2) question to KUI and Novski: are you using a 74HC595, or 74HCT595 as shift register?
I'm using a 74HC595 (without T) as recommended in the MBHP_CORE_LPC17 schematic. I don't remember the exact reason anymore, but I remember that some people had problems with driving LCDs when they used 74HCT595.
I only want to ensure, that you are using exactly the same HW components...
 
Best Regards, Thorsten.

[novski]

well yes. Im almost done with a better layoutet pcb. I will send it to manufactory this weekend. so i will have to put down working on this and wait for the new pcb wich i think will give me answers about those always changing problems. I don't get rid of the thought that this is caused by my bad layout.The new one will be more broad in all. 

 

Some things i done today:

The termination issue was gone as i connected the DSO probe so i tried to reproduce a probe with a 1M and Parallel 33pF and that helped for about 2 times re-powering. Then i had the same again. So i tried to solder big wires to the GND of the Displays witch did not help. I tried to put 33pF in parallel to GND on several lines what helped by DC but just for a certain operation time... after about 2min i have those werd spreading and flip over again. Thats why i started over with a new Layout.

I will take up this thread as soon as i have the new layout.

 

Thanks for your effort.

best regards

novski

 

update: im using a 74HC595B1 i will test that buffer soon.

Edited November 14, 2013 by novski

[TK.]

Please don't order a new PCB until the issues have been fully understood!

 

See also my previous post

 

Best Regards, Thorsten.

[novski]

Hi. I did this test as you mentioned.

 

1) check if buffered SCLK/SDA makes a difference: http://www.ucapps.de/mbhp/mbhp_lcd_ssd1306_buffer_idea.pdf as mentioned above.

You could use a 74HCT541 for this experiment, because you probably already have this chip available for J8/9 and J19.

 

Each buffer output should be connected to D0/D1 of 4 OLEDs

 

First. The schematic is wrong.

if i measure between VSS and VDD like it is drawn the Resistance is 490 Ohm. Not possible.

so i looked at the data sheet and assume Pin 10 is GND, Pin 20 supply voltage. Pin 1&19 has to go to GND.

like that no display works at my side. all are dark. i disconnected display 9-16.

it cold be that my 74HC541N is not the same as you mentioned (74HCT541)

 

TK. can you verify me the schematic?

 

 

2) question to KUI and Novski: are you using a 74HC595, or 74HCT595 as shift register?

I'm using a 74HC595 (without T) as recommended in the MBHP_CORE_LPC17 schematic. I don't remember the exact reason anymore, but I remember that some people had problems with driving LCDs when they used 74HCT595.

I only want to ensure, that you are using exactly the same HW components...

 

i use 74HC595B1

 

best regards

novski

[TK.]

Shame on me - of course I connected the 3.3V (Vdd) and GND (Vss) line to the wrong J15 pins (I was too much focused to show you how to buffer D0/D1)

 

I can't update the schematic till next week, but I guess that you know what has to be changed, right?

 

Best Regards, Thorsten.