Jump to content

MBSEQv4 LPC17 display problem


ilmenator
 Share

Recommended Posts

Hi,

 

I have a rather strange (?) problem with the two displays in my MBSEQ. I tried to exchange the STM32 core with the LPC17 one, and now it seems that the initialization of the two displays goes wrong. I get garbled screens, sometimes just a few letters are wrong, sometimes there is nothing at all on the screens. When I disconnect one of them, the other is fine - this holds for both, the left and the right display. When I switch back to the STM32 core, both displays work as they should. My PSU is beefy enough, it's a Meanwell RPT-60B. Any ideas?

 

Thanks, ilmenator

Link to comment
Share on other sites

ok, should be reliable (ah: and very good - I've a tester for the most recent app_lcd updates - could you please also test a selfbuilt binary based on the latest SVN revision? :))

 

The effect that you notice would happen, if the D7 feedback input line isn't working correctly.

You can test it - together with the remaining LCD control/data outputs - with the new "testlcdpin" command from the MIOS Terminal (also only available when you compile the latest sources by yourself)

 

Best Regards, Thorsten.

Link to comment
Share on other sites

[19343.834] testlcdpin rs 0
[19343.836] J15A.RS and J15B.RS set to ca. 0V
[19376.329] testlcdpin d7 0
[19376.331] J15A.D7 and J15B.D7 set to ca. 0V
[19376.332] D7 input pin correctly shows logic-0
[19401.689] testlcdpin d7 1
[19401.691] J15A.D7 and J15B.D7 set to ca. 5V (resp. 3.3V)
[19401.691] D7 input pin correctly shows logic-1
[19422.440] testlcdpin d6 0
[19422.442] J15A.D6 and J15B.D6 set to ca. 0V
[19422.442] D7 input pin correctly shows logic-0
[19430.008] testlcdpin d6 1
[19430.011] J15A.D6 and J15B.D6 set to ca. 5V (resp. 3.3V)
[19430.011] D7 input pin correctly shows logic-0
[19462.688] testlcdpin d0 1
[19462.690] J15A.D0 and J15B.D0 set to ca. 5V (resp. 3.3V)
[19462.690] D7 input pin correctly shows logic-0
[19471.711] testlcdpin d0 0
[19471.713] J15A.D0 and J15B.D0 set to ca. 0V
[19471.713] D7 input pin correctly shows logic-0
[19552.046] testlcdpin e1 0
[19552.048] J15A.E set to ca. 0V
[19587.157] testlcdpin e1 1
[19587.159] J15A.E set to ca. 3.3V

I'm not exactly sure what I am supposed to test here. I can set pins high and low, but am I supposed to measure on the pins directly?

Link to comment
Share on other sites

Yes, the voltages should be measured at the LCD.

 

It's interesting, that the feedback is working: D7 input pin is logic-0 when D7 outputs 0V, and it's logic-1 when D7 outputs 5V

So: my assumption wasn't correct.

 

Another reason could be, that you've a short somewhere... direct measurements at each data/control line help to clarify this!

 

Best Regards, Thorsten.

Link to comment
Share on other sites

I can set all data lines to "1" manually, and individually. However, whenever I issue a set command to any other data line, the one that was previously set to "1" goes to "0" again - i.e. there is only ever one single data line at "1" simultaneously, all others are always "0". Is that how it is supposed to be?

 

Edit: Also, I just checked the LPC17 board for shorts - it is good, no shorts, and all connections are there, as they should be. I also exchanged IC2 (the 595), but nothing has changed. Unconnecting one display from the cable does not help either. Only if I unplug one cable from the LPC17 core board, the remaining display works fine. One cable is about 25cm long, the other about 45cm.

 

As the cables and displays are the same as for the Core32 board I really don't know what could be the problem.

Edited by ilmenator
Link to comment
Share on other sites

I can set all data lines to "1" manually, and individually. However, whenever I issue a set command to any other data line, the one that was previously set to "1" goes to "0" again - i.e. there is only ever one single data line at "1" simultaneously, all others are always "0". Is that how it is supposed to be?

 

of course, otherwise we wouldn't be able to detect a short.

Since the usage of this testmode seems to be confusing: could you please do me a favor and write a documentation for it, so that they usage is clearly specified?

Or alternatively improve the messages which are print out?

 

 

 

Edit: Also, I just checked the LPC17 board for shorts - it is good, no shorts, and all connections are there, as they should be. I also exchanged IC2 (the 595), but nothing has changed. Unconnecting one display from the cable does not help either. Only if I unplug one cable from the LPC17 core board, the remaining display works fine. One cable is about 25cm long, the other about 45cm.

 

Such a cable length shouldn't be problematic.

Are you using a 74HC595 or 74HCT595?

The recommended chip is a 74HC595.

If you are using a 74HCT595 - are you using a 74HC595 on your MBHP_CORE_STM32 module? Then swap it and check if this makes a change.

 

Best Regards, Thorsten.

Link to comment
Share on other sites

It's a 74HC595 on both boards.

 

I guess I'm just giving up on this and use the Core32 - I am probably never using OSC after all, so I could better spend my time starting with the design of the TPC board instead. There are some holes in my front panel that need to be filled...

 

post-3442-0-07282200-1358520864_thumb.jp

 

I know it's kind of lame, and usually I would want to find out why things are happening the way they do (I guess engineers have a tendency to do this), but here I'll just go for the easy fix. There are more issues to solve along the way with this box :-).

 

 

Link to comment
Share on other sites

When I disconnect one of them, the other is fine - this holds for both, the left and the right display.

 

My first guess would be the R33 resistor array...... accidentally using a 10k "103" part here instead of the 1k "102" array can cause this.  (both values are in a LPC kit/BOM)

Wrong polarity on the array or an open connection on one pin can also generate the same symptom(s).

 

Best regards

 

Tim

Link to comment
Share on other sites

Thanks for your input, Tim. But the polarity of R33 is fine, as well as its value. I even measured the individual resistances, all good. This is a v1.0 board that had a wrong trace between the 5V pin of J15_S and the common pin of R33, but that has been fixed with a trace cutter and a short wire between the middle pin and the common pin of R33. It is now exactly as in the schematic.

post-3442-0-54677100-1358531815_thumb.jp

 

Edit: added picture of the modification.

Edited by ilmenator
Link to comment
Share on other sites

  • 2 weeks later...

Great! :smile:

 

To be honest: I've no plausible answer why this is the solution for the issue.

Actually it was the last (un)likely reason why such a failure could happen. The serial input pins of a 74HC595, which are now driven at a slower rate, are not directly connected to the LCDs - the load shouldn't change if more than one LCD is connected to a 74HC595 - but somehow we've an unexpected dependency which isn't understood.

Duggle helped a lot by giving the right details at the right moment - but I'm still not able to reproduce this at my side.

 

Best Regards, Thorsten.

Link to comment
Share on other sites

Maybe a plausible answer: do you supply your MBHP_CORE_LPC17 module directly from your PC, or are you using an external PSU, resp. an USB hub with PSU?

The LPC17 consumes more power than a STM32 due to the higher clock rate.

The backlight of the second LCD will increase the power consumption as well, which could lead to an unwanted voltage drop.

 

Best Regards, Thorsten.

Link to comment
Share on other sites

Maybe a plausible answer: do you supply your MBHP_CORE_LPC17 module directly from your PC, or are you using an external PSU, resp. an USB hub with PSU?

The LPC17 consumes more power than a STM32 due to the higher clock rate.

The backlight of the second LCD will increase the power consumption as well, which could lead to an unwanted voltage drop.

 

I think that is highly improbable in my case, as I am using the MeanWell RPT-60B from NorthernLightX's bulk order - which supplies up to 4A on the 5V rail...

 

One thing that I suspected was that the displays might not get enough power during the init phase, because I had added the 2200uF capacitor to the secondary side (5V) instead of putting it before the Vreg which is not used any longer. This is recommended somewhere on ucapps.de. My reasoning was that it might take a little too long to charge the capacitor, and that that would drop the voltage just long enough for the display init to fail. However, when I removed the capacitor nothing changed.

Link to comment
Share on other sites

I've a new hypothesis which has to be proven - could you please check the following two firmwares at your side:

 

http://www.ucapps.de/mios32/midibox_seq_v4_070_j15pp.zip

http://www.ucapps.de/mios32/midibox_seq_v4_070_j15pp_fastsr.zip

 
With both versions Duggle was able to get 18 CLCDs connected in parallel (!) running - my hope is, that it also helps to solve the issue with your LCDs
 
Best Regards, Thorsten.
 
Link to comment
Share on other sites

Thank you!

 

this problem seems to be related to an undocumented silicon issue: the pins which are used to drive the E1/E2/RW/RS line are 5V tolerant (according the the user manual), but the voltage level is limited to 3.3V in open drain mode, probably because of internal protection diodes.

 

Actually the external pull-up resistors should pull the level to 5V - and this causes a short circuit, which gets worse (and also affects neighbored pins) than more displays are connected.

 

Configuring these pins for push-pull mode helps to avoid the shorts - and fortunately the 3.3V output voltage at logic-1 is still high enough for the LCDs! :)

 

Best Regards, Thorsten.

Link to comment
Share on other sites

  • 3 weeks later...
  • 1 year later...

Hi ilmenator,  I had the same issue but with a smt32,  one LCD works fine, both -> garbage. It appears when suply voltage with the PC through USB cable, and fix it changing a 74HC595 with a 74HCT595 instead. so now it's working fine, but what you wrote ( and what Thorsten wrote ) is very important to me to understand the problem, may be a voltage level problem? in my case it seems i think due to the use of a 74HCT595, I'm not sure

 

 

 

Thanks to Thorsten and you for this contribution

 

 

Albert

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...