imx27L based Smart Thermostat Design

[Beam]

Having trouble with software hanging up either at Redboot or Kernel or Lenux program running. Out of 60 prototypes, 10 to 15 shows this symptom. All I/Os are properly terminated. It does not change when temperature cycled (hot and cold). Any feedback or similar experience and how resolved would be dearly appreciated.

Baha Erturk

[Beam]

Dear Robert,

Thank you very much again for your kind response and contribution. We are indeed using Freescale imz27L ADS development kernel. I will send this to out team in India and ask any possibilty. On  the other hand, we do not see this in most of the PNT (Programmable-Networkable Thermostats) controllers. Including a lot of temperature testing, different LCDs, differnt power suppliers etc. Maybe we may try to get the system to not lock up with a minimal kernel, by a process of elimination this may give us better understanding of where root cause is.

Once we have some idea of what modules or subystems are producing the problems-issues, then we may start instrumenting those systems to localize the lockup and start pulling things out the same way were doing above.

I do not know if there is any other way to do this. Unfortunately, we have to go to a show and I do not trust at this moment the PNTs that worked well.

Thank you again for your help.

[RobertSchwebel]

Dear Baha,

What you describe looks like you have badly messed up your board support code. One question: which kernel are you using, the one supplied by Freescale, or the mainline kernel? The official kernel has a proper abstraction for boards, which makes it much easier to customize Linux for your own hardware. What you describe can be a bug, but it very much looks like what happens if someone beats on the demo kit board until it works on other hardware :-) It usually can be avoided by Just Doing Things Right (TM). That's not really helpful, I know, but it's not possible to say more without actually having access to the hardware and board support code. Feel free to contact me directly if we can help you with our support team at Pengutronix. We ported the MX27 into the mainline kernel, so we have quite some experience with it.

rsc

[Beam]

Dear Robert,

Thank you very much for your feedback and suggestion. I came in to the office and send your serponse yo our development team in India.

We do have the smart thermostats in our labs.

We were able to verify that when the display gets messed up with lots of distortion that accesses to the RAM stops working.

When the display distorts a little, the RAM test still works but as the distortion increases, a simple RAM test fails every time.

Major LCD Distortion = Broken RAM Access

Minor LCD Distortion = OK RAM Access

We don't think the LCD distortion is related to bad timing on the LCD connector but something being shifted in the graphics frame buffer in the RAM. We need to collect more info on why the RAM is going bad.

One interesting thing to note is that if you stop the PNT from booting complete and only run a length RAM test the accesses don't go bad over time. I am wondering if a heavy usage of the RAM resources is causing the RAM operating to crash. Maybe enabling graphics to the display stresses the memory some how.

Any inputs and suggestions would be appreciated much.

[RobertSchwebel]

Baha,

without having seen your design and code it is pretty difficult to say something about your problem.

Btw: The boot process on MX27 can be heavily boosted by using a modern boot loader. We have acieved 800 ms boot time into a standard mainline Linux kernel with the MX27 and the Barebox bootloader, without any uggly hacks on the kernel side. The actual boot time depends on the hardware, but something below 1 s is possible.

Is your smart thermostat available somewhere?

Best regards,

Robert