Hi Agathe,
On 2/15/22 05:40, Agathe Porte wrote:
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?
Yes, that is exactly what I ended up doing.
Thanks,
Guenter
