ilmenator Posted January 17, 2013 Report Share Posted January 17, 2013 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 Quote Link to comment Share on other sites More sharing options...
TK. Posted January 17, 2013 Report Share Posted January 17, 2013 Are you using a released binary, or did you build the application by yourself? (just to doublecheck, because I did some changes on the universal LCD driver in the last days) Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
ilmenator Posted January 17, 2013 Author Report Share Posted January 17, 2013 I'm using the v4.069 binary. Quote Link to comment Share on other sites More sharing options...
TK. Posted January 17, 2013 Report Share Posted January 17, 2013 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. Quote Link to comment Share on other sites More sharing options...
ilmenator Posted January 17, 2013 Author Report Share Posted January 17, 2013 The self-built binary (4.070) shows exactly the same behavior. Quote Link to comment Share on other sites More sharing options...
TK. Posted January 17, 2013 Report Share Posted January 17, 2013 ok, and what are the results with the "testlcdpin" procedure? Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
ilmenator Posted January 17, 2013 Author Report Share Posted January 17, 2013 [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? Quote Link to comment Share on other sites More sharing options...
TK. Posted January 17, 2013 Report Share Posted January 17, 2013 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. Quote Link to comment Share on other sites More sharing options...
ilmenator Posted January 17, 2013 Author Report Share Posted January 17, 2013 (edited) 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 January 17, 2013 by ilmenator Quote Link to comment Share on other sites More sharing options...
TK. Posted January 17, 2013 Report Share Posted January 17, 2013 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. Quote Link to comment Share on other sites More sharing options...
ilmenator Posted January 18, 2013 Author Report Share Posted January 18, 2013 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... 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 :-). Quote Link to comment Share on other sites More sharing options...
smashtv Posted January 18, 2013 Report Share Posted January 18, 2013 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 Quote Link to comment Share on other sites More sharing options...
ilmenator Posted January 18, 2013 Author Report Share Posted January 18, 2013 (edited) 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. Edit: added picture of the modification. Edited January 18, 2013 by ilmenator Quote Link to comment Share on other sites More sharing options...
TK. Posted January 31, 2013 Report Share Posted January 31, 2013 It would be interesting if your LCDs are working with following version: http://www.ucapps.de/mios32/midibox_seq_v4_070_pre1.zip The transfer speed to IC2 has been reduced, this solved a similar issue which has been noticed by Duggle. Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
ilmenator Posted January 31, 2013 Author Report Share Posted January 31, 2013 Beautiful - this works perfectly :hyper: . Thanks a lot! So how did you spot this one? Quote Link to comment Share on other sites More sharing options...
TK. Posted February 1, 2013 Report Share Posted February 1, 2013 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. Quote Link to comment Share on other sites More sharing options...
TK. Posted February 1, 2013 Report Share Posted February 1, 2013 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. Quote Link to comment Share on other sites More sharing options...
ilmenator Posted February 1, 2013 Author Report Share Posted February 1, 2013 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. Quote Link to comment Share on other sites More sharing options...
TK. Posted February 4, 2013 Report Share Posted February 4, 2013 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. Quote Link to comment Share on other sites More sharing options...
ilmenator Posted February 4, 2013 Author Report Share Posted February 4, 2013 Yes, I can confirm that with both versions my LCDs are working correctly, just like with the v4_070_pre1. :phone: Kind regards, ilmenator Quote Link to comment Share on other sites More sharing options...
TK. Posted February 4, 2013 Report Share Posted February 4, 2013 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. Quote Link to comment Share on other sites More sharing options...
EsotericLabs Posted February 25, 2013 Report Share Posted February 25, 2013 (edited) X Edited February 25, 2013 by Martijn Quote Link to comment Share on other sites More sharing options...
albpower2seq4sid Posted August 9, 2014 Report Share Posted August 9, 2014 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 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.