This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PGA900: fast programming method

Part Number: PGA900

Hello.

We've started a mass production of device based on PGA900 last year.

For further volume increasing we need to resolve the issue of slow programming process of OTP-memory for this device.

 On small volume parties we've used XDS200 device for programming.

Now we try to implement in-circuit programming by I2C interface. And we faced with significant increase of programming time.

If XDS200 downloads the program in a couple of seconds, I2C takes more than 4 minutes for this operation.

So could you please give your recommendations on the next questions:

1. Could you provide a comparison table on the programing time vs used programming interface?(I2C/JTAG/etc.)

2. Could you provide a documentation on bootloader protocol description for  PGA900?

3. Is there any "best practice" recommendations on how to program PGA900 in the shortest time for mass-production?

4. Is this datasheet on PGA900 (available here  the most updated revision?


Thank you for support in advance.

  • Hello Slava,

    1. I don't currently  have a comparison table with this information. The maximum speed of the SPI clock is 1Mhz, and the max speed of the I2C clk is 800kbps. When programming through these methods, the OTP is programmed 4 bytes at a time, which takes 7 24-bit transactions. Programming 8kb of OTP will take 14000 of these transactions, and at the max speed for each of I2C and SPI, those transactions can be completed in under 1 second. However, the actual programming time taken by the PGA900 when writing to the OTP cells is between 120 and 200us for each byte. This is an order of magnitude larger than the time for the digital interface transactions, so the timing for each of the digital interfaces is basically negligible compared to the time it takes for the internal logic to complete the OTP programming for each byte. As long as you use the fastest allowed clock speed for either I2C or SPI, they should be able to provide the same programming speed as when using the XDS200. Note that if the programming procedure is done with the EVM GUI, the fastest speeds are not used for I2C and SPI, and the transactions are spaced quite far apart in time simply because of the GUI API and the USB communication.

    2. The internal M0 always loads the program directly from the OTP on startup unless the DEVRAM remap bit is set (it still loads from the same memory location, but the DEVRAM data is remapped over the OTP space), which is usually only used for realtime debugging. Since the program instructions are stored in one-time-programmable memory there isn't much use for a bootloader protocol. You simply program the OTP once, and it cannot be changed later.

    3. The only best practice for speed is to make sure you are sending the transactions at the highest rate allowed by the PGA900 specifications. The allowed interface speeds are fast enough that the limiting factor is the OTP programming itself, which cannot be sped up. In order to avoid errors in the programming, make sure that the OTP programming was successful for each write by reading the OTP_PROG_CTRL_STAT register. This is described in the OTP Programming sections of the datasheet.

    4. The most up to date PGA900 datasheet is the one available through the datasheet request link on the PGA900 product page. It was last revised February 2018.

    Regards,