Why is my code sometimes running sometimes not ?

[antonius]

Posted on October 08, 2013 at 01:50

Guys,

Why is my code sometimes running sometimes not ? When I plug in J-Link, it's stable but if I plug it out, it's not stable ?? Is it because a power supply from USB ? Any ideas ? Thanks

[antonius]

Posted on October 18, 2013 at 08:41

the solution I have now, is push the reset button for few seconds even until almost 10 seconds to make it on....

From no power ==> power supply connected, LCD is blank forever if I'm not pushing the reset button.... Is it because of reset circuit ? I'm not using J-Link anymore now, it's only LCD, STM32 and power supply...

[frankmeyer9]

Posted on October 18, 2013 at 10:31

From no power ==> power supply connected, LCD is blank forever if I'm not pushing the reset button....

Is it because of reset circuit ? My guess, this is caused by basing your application on crappy LCD driver code. I have a few boards working, with different MCU/LCD driver chip combinations, where I had to port/rewrite the driver initialization sequence and the low-level driver code, sometimes based on PIC18 or AVR XMEGA examples. Or perhaps, your code is not for exactly the same driver chip revision. It took me some time to get these things to work, and included reading the (LCD driver) datasheet, and comparing/extending existing code to your requirements.

[Tesla DeLorean]

Posted on October 18, 2013 at 14:01

I'm really not a fan of R-C based reset circuits, you should consider a POR chip like the

http://ww1.microchip.com/downloads/en/devicedoc/11184d.pdf

which should give a several hundred ms RESET pulse, and is robust against slow rising power supplies, and brown outs.Something like this should be more than adequate to reset the PROCESSOR reliably.You should then turn your attention to the LCD and it's drivers, you should make sure it is using adequate delays in terms of waiting for it to come ready, or between register or status use. If the LCD requires a long RESET of it's own, then you should probably use a specific pin for that, and drive it with a signal that meets the specifications for the panel.But it really seems you need to separate the reset of the CPU and the LCD in resolving this problem.

[jj2]

Posted on October 18, 2013 at 16:05

Two here now have questioned/suggested that MCU and Lcd Controller should be reset separately - at least until this abnormal start-up issue is cured.

It remains unclear if all other aspects of your program code perform correctly - minus that abnormally long reset application.  Simple toggling of Port driven Led - just after MCU set-up/config - will identify the MCU's emergence from reset & set-up initialization.  With the info thus far provided - it is unclear if this reset issue afflicts other portions of your program - or just the Lcd. Indeed mistakes in Lcd driver code abound - but the fact that this prolonged reset seems to regularly yield correct Lcd operation - argues against such Lcd driver issue.  (if indeed - the Lcd always restores after the prolonged reset) Should multiple program areas (i.e. the specific Led test just described) be improved via your long reset - then Clive1's suggestion of a formal/proper reset device seems ideal.  But - if only the Lcd requires that long reset - it is likely that MCU -> Lcd transactions should be delayed until the Lcd truly is, ''ready.'' Your clear description of the board's routing of Reset (i.e. list all chips/devices which receive that reset...) would aid this diagnosis...

[frankmeyer9]

Posted on October 18, 2013 at 16:52

Indeed mistakes in Lcd driver code abound - but the fact that this prolonged reset seems to regularly yield correct Lcd operation - argues against such Lcd driver issue.  (if indeed - the Lcd always restores after the prolonged reset)

Some debugging effort on the side of the OP might yield better results than plain ''black-box power cycling'' tests. Power issues could possibly be involved, so a scope at the supply - in addition to debug/instrumentation output - might be helpful.