Requirement of specifying the "ERASE" option during programming?

[Anonymous]

It is my understanding the SIP modules come from Broadcom with a test program pre-programmed into them.  If an end-customer program is subsequently programmed into these parts using chipload.exe *without* specifying the "ERASE" option, the parts exhibit unwanted behavior, specifically the GPIO P1/Write Protect pin tied to the internal EEPROM appears to be left floating.  As Broadcom generally recommends putting a pull-up resistor on this pin it effectively write protects the NVRAM, preventing any data from being written.

If "ERASE" is specified during programming, P1/Write Protect behaves normally.

In either case, the "VERIFY" option runs successfully after programming.

Question:  Why does P1/Write Protect misbehave when "ERASE" isn't specified, despite the readback/VERIFY returning successfully?  Is it necessary to ERASE the parts during the programming process?

[MichaelF_56 · Accepted solution]

I spoke to the developers and they are not certain what specific firmware our packaging house loads into the modules before shipping.

However, they said that if the NVRAM layout in the btp file is different from what they use, and what the customer uses, then it is possible that results could occur if the device is not first erased.

Ultimately, it is never a good idea to *not* erase during factory programming, especially when something is loaded onto the part at the factory..