Hi Guenter,
Le 12/02/2022 à 00:53, Guenter Roeck a écrit :
Turns out the chip is by default locked, meaning all those
configuration writes
fail unless I explicitly unlock the chip. How would you suggest to
handle that
situation, and how do you handle it in your application ?
After reading the TMP464 datasheet, the device seems locked by default
indeed:
All of the configuration and limit registers may be locked for writes
(making the registers write-protected), which
decreases the chance of software runaway from issuing false changes to
these registers. The Lock column in
Table 3 identifies which registers may be locked. Lock mode does not
effect read operations. To activate the lock
mode, Lock Register C4h must be set to 0x5CA6. The lock only remains
active while the TMP464 device is
powered up. Because the TMP464 device does not contain nonvolatile
memory, the settings of the configuration
and limit registers are lost once a power cycle occurs regardless if
the registers are locked or unlocked.
In lock mode, the TMP464 device ignores a write operation to
configuration and limit registers except for Lock
Register C4h. The TMP464 device does not acknowledge the data bytes
during a write operation to a locked
register. To unlock the TMP464 registers, write 0xEB19 to register
C4h. The TMP464 device powers up in locked
mode, so the registers must be unlocked before the registers accept
writes of new data.
From my deduction, since we do not unlock it with software, I guess
that our local FPGA is doing the job of disabling the lock during
power-on procedure.
I guess we could read and unlock the device when probing, and relock it
after rmmod if it was locked during probing (store initial lock state).
We do not want to relock it if it was unlocked before probe — like in
our usecase — because other applications may use this "already unlocked"
assumption (bootloader, FPGA code, …).
What do you think?
Best regards,
Agathe.
