nRF24LE1G (OTP)

Question on an older chip:

Can anyone tell me if FW originally written for the nRF24LE1E would be completely compatible with the nRF24LE1G? I have an opportunity to source the nRF24LE1G but I am worried there may be hidden implications.

PS. I am aware there are differences when flashing the chip. 

  • 0
    0 pts.
    in reply to Kenneth

    HI Kenneth,

    Thanks for this, very helpful.

    If I have understood correctly, because we currently write the pairing record to EEPROM (see below) this will be incompatible with the nRF24LE1G (OTP version)? In other words, our existing FW would constantly forget it's pairing record if flashed to a OTP IC?

    Assuming the above is correct, what are my options? Do I write the pairing parameters to Non-Volatile data memory? Or is this OTP (cannot be changed or overwritten)? Apologies if this is a very basic question, it's been a while since I've looked at the 24LE1 code.

    void gzpair_non_volatile_write(uint8_t adr, uint8_t* src, uint8_t n)
    {
      lib_eeprom255_bytes_write(GZPAIR_PAIRING_EEPROM_BASE_ADDRESS + adr, src, n);
    }

  • 0
    15611 pts.
    in reply to Simon

    Honestly speaking I don't think it's a good idea to switch from Flash to OTP if the application was not intended or tested for OTP to start with. As you write, it's been many years since many of us have worked with the nRF24L-series, so even though the application should be able to write data to an OTP address one time, it's likely that your current application also have implementations that will try to erase flash pages at some time, this will not work. If I remember back in time, I think this kind of challenge was solved by incrementingly write to OTP until memory was full, at which point the application would store the values in RAM. Writing to RAM would mean it would only work until power was cycled, but since a power cycling is not done frequently in most cases, it would only require repairing on power cycling.

    Kenneth

Related