Display options

[novski]

Yes. i found a sample in the LPC17 schematic...

by the way, i understand this as the HCT is not compatible to 3.3V objects. Its necessary to use a HC type in our case...

source: http://www.ti.com/lit/ds/schs189c/schs189c.pdf

best regards

[TK.]

You are right. So, I guess that you can't try it out since you don't have this chip available, right?

 

Best Regards, Thorsten.

 

P.S.: I corrected the schematic

[novski]

Hi TK. we had a misunderstanding im sorry for that.

I have a HC version and tested it. But all the displays stay dark.

I can't locate my falure but im shure that there is a miss connection somewhere. Give me a day or two. I will look another time over that as soon as possible.

Because my PCB i so complicated its hard to solve it.

 

does KUI's display work now?

 

best regards

novski

[KUI]

Hi TK. we had a misunderstanding im sorry for that.

I have a HC version and tested it. But all the displays stay dark.

I can't locate my falure but im shure that there is a miss connection somewhere. Give me a day or two. I will look another time over that as soon as possible.

Because my PCB i so complicated its hard to solve it.

 

does KUI's display work now?

 

best regards

novski

Hi Novski,

 

I am out of town until nov. 25th.

 

Look back over the posts to find out where I was with the dispalys before I left to go to work.

 

thanks

KUI

[KUI]

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.

I am using 74HC595N shift registers.

 

I have not tried to distribute D0 and D1 through shift registers yet.

 

 

KUI

 

KUI

[TK.]

Hi,

 

status from my side: I created a board with 4 additional OLEDs today, and connected it in parallel to my first board (CS lines are uncritical, therefore this doesn't matter)

 

I still get very stable display output, even when I'm using an extra-long cable to J15:

Conclusions so far:

- SCLK and SDA (D0 and D1) still uncriticial when 9 OLEDs are connected in parallel

- I tested this with a "new gcc" build

- the "new gcc" build leads to the same results on two different hardware implementations (KUI & Novski)

I've still no clue what could cause such an issue :-/

How can I get direct access to the hardware?

Novski: you are located in Switzerland, I guess it would be too expensive to ship your PCB to germany.

KUI: where are you located?

Best Regards, Thorsten.

[schoko11]

Hi TK!

 

 

I ordered 16 pieces of this hardware.

Unfortunatly they will not arrive before 10.12(as far as i know).

I wouldn't mind sending you (i guess) 7 of these.. ?

 

I am from Austria.

Best Regards, Klaus.

[TK.]

Hi Klaus,

 

thanks for the offer, but I fear that this won't bring new insights.

There seems to be something special if connections are directly routed on a PCB (e.g. w/o J15 & J28 sockets between OLEDs and LPCXPRESSO module).

It's maybe possible to compensated this via software, but I've to analyze this on my bench.

 

Best Regards, Thorsten.

[novski]

Hi TK.

Im located in Switzerland. I cold send you my pcb but im afraid you woldn't understand because its a battlefield. Im not happy with my layout and with al the tests i tried to make it became worse... But as i mentioned above i made a new and more flexible layout. Its in production now. With that i will be able to make more accurate suggestions as i did until now.

It should arrive me mid. Dezember 2013. 

 

 just a view on my opstacle: https://www.dropbox.com/s/lurw2m1fln4e6z3/2013-11-30%2013.15.27.jpg

 

Do you have more than 12 OLEDs? Because i think, KUI and me, both only have this problem when trying to connect more then 12 OLEDs over an additional shift-register...

I wold be able to provide you additional 5-8 OLEDs. Much more i wold rather wait and send you a Test PCB all together with them...

 

this is it:

https://www.dropbox.com/s/8t99mgr11zbx8d4/Screenshot%202013-11-30%2012.55.53.png

 

It provides a connector to Official J15A. And a Connector with slightly different pining than J28, - witch provides DC, D0, D1, SDA, SC, RC, 3V3, GND over 10pin DIL Header proprietary. :-)

 

Are you able to wait so long?

 

best regards

novski

[KUI]

Hi TK,

 

I am in Nashville TN, USA.

I am using the original LPC17 core board. All 16 of my displays are booting and working with the old gcc. I only have one issue on display 16, slight scrolling of the second line, its scrolling left to right.

Still get two displays missing when using the new gcc you posted.

I have not tried just twelve displays. Like Novski I jumped from 8 to 16.

 

 

Cheers

 

KUI

[TK.]

Ok, then let's try to continue the debugging remotely with KUIs setup.

 

I will come back to this topic soon.

 

Best Regards, Thorsten.

[TK.]

@KUI: here a new version for testing: http://www.ucapps.de/mios32/midibox_ng_v1_027_pre6.zip

 

It has been compiled with the new GCC compile. I gave the serial shift at J15 and J28 a little bit more time in the hope that this helps.

In addion, the SCLK will now be available at J15A:E and J15B:E

Means: you get an additional clock driver "for free" which could be used instead of a buffer (if really necessary)

 

If this still doesn't help, please also try out what happens if the core is powered off for at least 5 seconds, and then powered again.

 

Best Regards, Thorsten.

[KUI]

Hi TK,

 

So that seems to fix the boot issue for all 16 displays :smile:

I have attached a video of the behavior of display 16.

 

NOTE: I still have 100ohm resistors in series with the D0 D1 and DC lines between the two 8 OLED display boards.

Should I attempt with them removed?

 

 

Thanks

 

KUI

VIDEO0020-0.zip

Edited November 30, 2013 by KUI

[TK.]

This is relieving! :)

 

Could you please check, if display 16 is working correctly with this app: http://www.ucapps.de/tmp/mios32_test_app_lcd_ssd1306_LPC1769_131201_1.zip

It has been compiled with new gcc and "relaxed SER streams" - same infrastructure that I used for the MBNG build before.

 

 

NOTE: I still have 100ohm resistors in series with the D0 D1 and DC lines between the two 8 OLED display boards.

Should I attempt with them removed?

 

Yes!

 

Best Regards, Thorsten.

[KUI]

So. . .  Same result on display 16.

Removed the 100 ohm resistors on the D0 D1 And DC lines.

Result, garbled displays on 1-8.

Added the resistors back one at a time. When D0 and D1 are isolated through the 100 ohm resistors, displays 1-8 are stable. DC seems to make no difference.

 

Hope this helps

 

Cheers

 

KUI

[TK.]

:-/

 

Are you able to swap displays?

It would be interesting, if for example display 16 behaves the same way if another OLED is plucked into the socket.

And another interesting test: how does it behave, if the CS line of display 16 is connected to the same 74HC595 pin, which is routed to display 15 (I would expect, that both displays show the same text)

 

Best Regards, Thorsten.

[KUI]

Update,

 

I can confirm that J15B SCLK works. I now have displays 1-8 off of J15A, and displays 9-16 running off of J15B and J28 through a dout module for the cs lines.

Thanks TK, that makes connecting the next 8 displays at least easier:)

 

Still have the scrolling on display 16.

 

Occasionally if I have to reboot I must do it twice with 6 seconds in between boots.

 

Cheers

KUI

[KUI]

Thanks TK!

 

KUI

[KUI]

:-/   Are you able to swap displays? It would be interesting, if for example display 16 behaves the same way if another OLED is plucked into the socket. And another interesting test: how does it behave, if the CS line of display 16 is connected to the same 74HC595 pin, which is routed to display 15 (I would expect, that both displays show the same text)   Best Regards, Thorsten.

Will test shortly. KUI

[KUI]

Hi TK,

 

I swapped display 15 and 16 physically.  No changed display 16 still showing same as video.

 

I then routed cs line for display 16 to display 15 and 16, same text and corruption on both.

I then routed cs line for display 15 to display 15 and 16, clean text no corruption on either display.

 

I noticed with the output from my SAC machine that the corruption is only there when the displays are being updated, in the case of your oled test app, they are being constantly updated, hence the continuous scrolling.

 

some kind of artifact?

 

 

Regards

 

KUI

[TK.]

I've no explanation for this.

 

Based on the picture that you sent some postings earlier, it looks like the wrong commands are sent to the 16th CS line.

Because with: 

> I then routed cs line for display 16 to display 15 and 16, same text and corruption on both.

> I then routed cs line for display 15 to display 15 and 16, clean text no corruption on either display.

 

you proved that the remaining signals (especially SCLK and SDA) are clean.

 

Display 16 is handled correctly at my side.

 

So, let's assume that there is an issue with the 74HC595 output at your side.

CS16 has to be connected to pin 15 of the 74HC595, please check this first.

Check also another 74HC595, who knows... :-/

 

Best Regards, Thorsten.

[KUI]

Hi TK, For clarity, I have display 9-16's clock coming from J15B. The cs lines are coming from a smashTV 4xdout module. All oleds have a 100uf between 3.3v and gnd. Displays1-8 have a 240ohm resistor in series with the cs lines. KUI

[KUI]

So I have confirmed that cs line 16 is connected to pin 15 of the 74HC595.

 

Tried three different 74HC595s no change, even changed the one on the core.:^/

 

With the clock coming from J15B. I am unable to get the bootloader store function to access displays 9-16.

 

In the past display 16 mimics, erroneously though, some of display 1's text.  See my pic half way down this page 

 

KUI

[TK.]

I'm using a (best quality) SmashTV MBHP_DOUTX4 module as well for the tests, which makes it even more mysterious.

 

> With the clock coming from J15B. I am unable to get the bootloader store function to access displays 9-16.

 

That's plausible, because the bootloader update application ($MIOS32_PATH/bootloader/updater) has been compiled with an older lcd driver which doesn't support J15B. You could re-compile it (now where you are able to do this) to get the change.

 

I can't give you additional debugging hints today (it's 0:30 in germany...), but for the case that you would like to continue with some software changes:

- the test application is located under $MIOS32_PATH/apps/mios32_test/app_lcd/ssd1306

- the driver under $MIOS32_PATH/modules/app_lcd/universal

 

in $MIOS32_PATH/modules/app_lcd/universal/app_lcd.c you will find the APP_LCD_SERGLCD_CS_Set() function which sets the CS lines.

MIOS32_BOARD_J28_SerDataShift() is used to update the 74HC595 SR connected to J28

 

E.g. an interesting SW change would be following modification at !all branch in APP_LCD_SERGLCD_CS_Set()

        int selected_lcd = mios32_lcd_device - 8;
 
// BEGIN mod: swap CS lines of 15th and 16th LCD
if( selected_lcd == 7 ) selected_lcd = 6; else if( selected_lcd == 6 ) selected_lcd = 7;
// END mod

        int selected_lcd_sr = selected_lcd / 8;
        u8 selected_lcd_mask = value ? ~(1 << (selected_lcd % 8)) : 0xff;

 

This would swap the CS lines of the 15th and 16th display in the software

 

If now display 16 still outputs incorrect data, you know that the problem is located at the hardware side.

 

Best Regards, Thorsten.

[KUI]

in $MIOS32_PATH/modules/app_lcd/universal/app_lcd.c you will find the APP_LCD_SERGLCD_CS_Set() function which sets the CS lines.

MIOS32_BOARD_J28_SerDataShift() is used to update the 74HC595 SR connected to J28

E.g. an interesting SW change would be following modification at !all branch in APP_LCD_SERGLCD_CS_Set()

int selected_lcd = mios32_lcd_device - 8; // BEGIN mod: swap CS lines of 15th and 16th LCDif( selected_lcd == 7 ) selected_lcd = 6; else if( selected_lcd == 6 ) selected_lcd = 7;// END mod        int selected_lcd_sr = selected_lcd / 8;        u8 selected_lcd_mask = value ? ~(1 << (selected_lcd % 8)) : 0xff;

This would swap the CS lines of the 15th and 16th display in the software

If now display 16 still outputs incorrect data, you know that the problem is located at the hardware side.

Best Regards, Thorsten.

Hi TK,

Successfully changed the code to swap cs lines in the software. The problems stays with socket 16. So the problem is in my hardware?

I will inspect my boards. The really strange thing is that I have 2 lp17 core boards they both do the same thing.

I will report back soon.

Thanks

KUI

 

Edited December 2, 2013 by KUI