Announcement

Collapse
No announcement yet.

LockDown Parameter Issue

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • LockDown Parameter Issue

    Hi There,

    Current I have some trouble with the enable/disable lockdown parameter(ID 52) by saveNvParam().
    We used a SPI data message to trigger the enable/disable the lockdown function, then we can upgrade the script overair.
    But sometime, the saveNvParam(52, 0) does not work, after called saveNvParam(52, 0) and reboot, the lockdown bit still shows '1'.
    Did anybody meet the same issue? The synapse firmware version we used is V2.5.3 with AES-128.

    Thanks,
    Henry

  • #2
    How exactly is this "SPI data message to trigger" received?

    The one unusual thing about ID 52 is that it cannot be turned off over-the-air (OTA) - and there's no documentation on exactly how that is checked. It can't be anything as simple as checking whether the most recent OTA message was saveNvParam(), as that could be trivially worked around by indirectly invoking it via callback() or callout(). My guess is that SNAPpy tracks whether the current script invocation was triggered via an OTA RPC (versus a serial port RPC, or a @hook function), and disallows turning off ID 52 in that case. If so, and your SPI message is received by something like a checkSpiMessages() function that is called from various places in your code, and it is sometimes called during handling of a RPC, on those occasions it would look exactly like an attempt to unlock the device OTA, and be denied. If I've guessed correctly here, one possible workaround would be to just set a global flag in response to the SPI message, and do the actual unlock in a timer @hook function (which should definitely not count as OTA).

    Comment


    • #3
      Hi Jason,

      Sorry. I did not explain it detailed enough.
      There is a SRAM memory connected with Radio module by SPI bus. And the script has a timer to check the SRAM whether there is flag set to clear the ID 52, if so, then it will reboot to give us a chance to update script overair. It works sometimes but not always.

      Thanks,
      Henry

      Comment


      • #4
        So this SRAM check is only being called from a timer hook? I have no idea what's going wrong, then.

        Comment


        • #5
          Yes. The function is only called by a timer hook.
          It only works sometime which makes me confused.

          Comment

          Working...
          X