The Notebook Review forums were hosted by TechTarget, who shut down them down on January 31, 2022. This static read-only archive was pulled by NBR forum users between January 20 and January 31, 2022, in an effort to make sure that the valuable technical information that had been posted on the forums is preserved. For current discussions, many NBR forum users moved over to NotebookTalk.net after the shutdown.
Problems? See this thread at archive.org.

    Where is the lid closure sensor on a Series 5 Ultra NP530U3C?

    Discussion in 'Samsung' started by fknelite, Aug 16, 2012.

  1. fknelite

    fknelite Notebook Consultant

    Reputations:
    13
    Messages:
    107
    Likes Received:
    0
    Trophy Points:
    30
    I haven't had my Samsung Series 5 NP530U3C-A01US for a week yet but it appears that it no longer responds to the lid being shut. I have checked the Windows settings and they are all correct. I am pretty sure it is a hardware issue since it doesn't work in Ubuntu either where it previously worked.

    Anyone else had a similar problem?
     
  2. marquis

    marquis Newbie

    Reputations:
    0
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    5
    I'm experiencing exactly the same type of problem since a couple of days with this NB. I also have Windows and Linux installed on it and, for this reason, I can be sure that it is not a software problem. Did you meanwhile find a solution?
     
  3. notepadfan

    notepadfan Newbie

    Reputations:
    0
    Messages:
    2
    Likes Received:
    3
    Trophy Points:
    6

    TL;DR: " Force a reflash to the BIOS, even if you already have the newest BIOS, and you will be able to suspend on lid close and autodetect unplug/replug"


    I bought my Samsung NP530U3C-AB1AR a week ago, and everything was working smoothly, until yesterday, when I noticed two things:

    1. Closing the LID was not detected by either Windows or Linux, and it lost the capability to suspend by closing the lid.
    2. Unplugging the power supply was not detected anymore by linux. And in windows it wasn't auto detected, though it detected it several seconds after unplugging, as if by polling.
    It was obvious that this was a hardware/bios issue, since both OS's had the symptoms.

    The lid sensor was working fine, so it wasn't a purely hardware issue (you could see the screen turn off when lowering it, and then ON again when opening the lid).

    Clearly, the BIOS wasn't sending events such as power Unplugged/Replugged or LID closed/opened to the OS.

    Of course, being familiar with the articles that described the bugginess of this laptop's BIOS, I wasn't surprised. I decided that it was a BIOS issue. I tried toggling all options I could find sensible to toggle in the BIOS, to see if the original behaviour was restored. It didn't, toggling options was useless.

    I decided to reflash the BIOS so that its internal options would be reset to defaults. THIS FIXED ALL ISSUES.

    But, but.. it wasn't that easy. This is because I already had the latest BIOS version, and the update tool refused to update the BIOS saying that I already had the "latest version or newer".
    This didn't stop me.
    I found a forum thread by searching for "samsung downgrade bios".
    And then I did the following:

    1) Open the BIOS update tool from Samsung (go to samsung.com, support, select your model, and look under Firmware). Click on 'Download' instead of 'Update'. It offered to save a file named "ITEM_20130423_1110_WIN_P14AAJ.exe". (My current BIOS version is "P14AAJ", so it is the same version).

    2) Run the file "ITEM_20130423_1110_WIN_P14AAJ.exe". The program decompresses several files to "C:\Users\<myuser>\AppData\Local\Temp\__Samsung_Update" The program refuses to update the BIOS because it is the latest version, and then deletes the files.
    I copy the files before closing the program. They contain the ROM and the SFlash64.exe utility, and some other files required for flashing.

    3) I notice a file there, named "DebugAppLog.txt". That file is not deleted between runs. In it, it contains the log of the time I updated the BIOS the day I bought it, and most importantly, the full command line for the SFlash64.exe utility. Which is:
    Bios command : SFlash64 /n /s /sa /ips /exit /file P14AAJ.rom ​

    I try "SFlash64 -help" and see the meaning of the flags. I particularly liked "/n" which says that it clears bios internal options to factory default, which is what I need.

    4) I close all the opened programs. With the task manager, I close Samsung's "Easy Settings" and all Samsung programs so that they don't interact with the BIOS while it is flashing.

    5) Start a console right clicking and "Run as administrator". Go to the directory where I saved the uncompressed files and run:

    SFlash64 /n /s /sa /ips /exit /file P14AAJ.rom ​

    6) Shutdown windows. Start hitting the "F2" key until I get in the BIOS. Inside the BIOS screen, hit "F9" to load defaults. Fix options to my liking because they were all default now.

    7) Start Windows. Test lid close, It works!!!!
    Start Linux, Test lid close, It Works!!! Test unplug power cord:
    It is detected!!! Also, when unplugging the power cord in windows
    it now detects it instantly, instead of several seconds later.

    PROBLEM SOLVED!



    FINAL NOTES: What caused the issue? Will it happen again? I have a few guesses: 1) The bios might have gotten confused when changing states, and enabled some internal option to not inform the OS of power events, perhaps while plugging/unplugging power while in S3 at the wrong time, who knows, Or 2) Some Samsung software in Windows messed up some internal option in the BIOS (Samsung software does change bios options, for example, one can toggle "Battery Life Extension" from windows, and the option will appear respectively toggled in the BIOS screen.). I might uninstall all the Samsung software, I won't for the time being, to see if it happens again. If it happens again, I'll just reflash. Or 3) I read that these Samsung BIOSes have limited memory for variables (in Jakob Heinemann: blog), so maybe entering the BIOS screen and saving bios options too many times is what caused it, which is what one does the first days of setup, changing boot order, etc (maybe the BIOS stores a backup of changed options internally until it runs out of space, and things go wrong then, luckily, reflashing the BIOS seems to restore everything to factory).
    I hope that it doesn't happen again, but I'll pay more attention to what I do, and try to remember what could have caused it.

    I spent the whole saturday debugging this issue, and I'm happy that I can share the solution!
    --
    Juan Manuel
     
    Gabuzomeuh, MeGuinness and Dannemand like this.
  4. John Ratsey

    John Ratsey Moderately inquisitive Super Moderator

    Reputations:
    7,197
    Messages:
    28,841
    Likes Received:
    2,165
    Trophy Points:
    581
    Thanks for this very useful post which is relevant to most (all?) recent Samsung notebooks (my NP900X4C also uses SFlash).

    I've dumped the full help contents into the attached file.

    View attachment SFlash help.txt

    And I am putting a link to your post in the BIOS update problems thread.

    John
     
  5. SScratch

    SScratch Newbie

    Reputations:
    0
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    5
    I want to ask!
    Does SFlash also updates micom? or only bios?
    my current bios P09ABH, newest P12ABH. I cant downgrade and after update bios because Biosupdater give error about battery <30% (battery dead i think). Also i cant find P09ABH distro to reflash only bios. Any ideas?
     
  6. John Ratsey

    John Ratsey Moderately inquisitive Super Moderator

    Reputations:
    7,197
    Messages:
    28,841
    Likes Received:
    2,165
    Trophy Points:
    581
    See this thread about my experience with the P09ABK BIOS update for the NP900X4C. I had to jump through some hoops to get the battery capacity reported correctly after the update.

    There is also this thread http://forum.notebookreview.com/samsung/698094-samsung-bios-update-problems.html.

    John
     
  7. notepadfan

    notepadfan Newbie

    Reputations:
    0
    Messages:
    2
    Likes Received:
    3
    Trophy Points:
    6
    Hi Again!!

    I found a much better workaround by reading this thread:

    https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/971061?comments=all

    The workaround consists of:
    1. Turn off and unplug the laptop.
    2. With a paper clip, push the button through the small hole in the back (it would be below the touchpad, in the back). Count to two.
    3. Now plug the laptop, so that it can turn on.
    After this, the LID close/open events are produced again. So do the AC plug/unplug events.

    This is what they recommend to do to reset the "Embedded Controller" which is the motherboard component responsible of detecting LID close/open events, and plug/unplug events, and battery percentage drop/increase. Hitting that small reset button in the back has the same effect as removing the battery would have, in a laptop which has a removable battery.

    This also explains why flashing the bios (any bios version), gets the computer out of the "problem state", because the Embedded Controller is reset while flashing any bios.

    I also found out, after many, many tests, that the problem happens again when the laptop is suspended and no less than 16 Embedded Controller events would be produced. (% battery drop or increase is one event. Plugging or unplugging produces each two events (so you can unplug or replug 8 times at most, LID close or open is one event).

    So, if I leave the laptop suspended with 100% battery, plugged to the wall, and without closing or openinng the lid, then the problem never happens.
    If I never suspend the laptop, the problem never happens.

    (by "problem state" I mean the state in which the laptop doesn't report LID events anymore, nor AC plug/unplug events, and this state is persistant between reboots and shutdowns).

    My guess is that either some internal buffer of the Embedded Controller gets full when it cannot report events to the sleeping OS, or that Linux gets the system into a race condition trying to respond to too many events at a critical stage while the system is resuming from sleep.

    If you think you got a fix, and want to try to see if it worked, the quickest way to reproduce the problem is to:
    1. Suspend the computer
    2. Unplug PSU, plug, unplug, plug, unplug, plug, unplug, plug (8 actions each produces 2 GPE events).
    3. Resume. Then, you can see that plugging or unplugging the PSU isn't detected, and LID close is ignored.

    --
    Juan Manuel
     
  8. John Ratsey

    John Ratsey Moderately inquisitive Super Moderator

    Reputations:
    7,197
    Messages:
    28,841
    Likes Received:
    2,165
    Trophy Points:
    581
    I would clarify that the hole in the bottom of the computer is a battery disconnect switch (which gets automatically reconnected when mains power is plugged in). The reset is happening because the battery is disconnected and the time to hold the switch down is irrelevant.

    Sometimes it is also necessary to hold the power button down for a little while to drain any residual power.

    John
     
  9. oled

    oled Notebook Evangelist

    Reputations:
    221
    Messages:
    587
    Likes Received:
    33
    Trophy Points:
    41
    It seems like OP might have indeed ran into the same bug the Series / Ativ Book 9 suffers. This bug messes up the whole ACPI functions like lid close, AC / battery load, Fn keys and whatnot.
    This is a serious bug reported many many times, but Samsung does not seem to care to fix it.