atPKI is not available in main repository

[MaJerle]

Answers checklist.

• I have read the documentation ESP-AT Programming Guide and the issue is not addressed there.
• I have used the latest released firmware or have updated my ESP-AT branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Why not? While it is advertised here: https://docs.espressif.com/projects/esp-at/en/release-v2.4.0.0/esp32/Compile_and_Develop/how_to_generate_pki_files.html#generate-certificate-bin-files

https://github.com/espressif/esp-at/blob/f64aa352/tools/AtPKI.py

[ustccw]

@MaJerle Hello~
The ATPKI.py is a deprecated script in master branch, and it's still available in release/v2.4.0.0 branch: ATPTK.py.
In short, the recommended version of the document is consistent with the version of the code repository. If you use release/v2.4.0.0 branch, then you should read the release-v2.4.0.0 document.

1. Why was ATPKI.py deleted on the master branch?

Because the parameter storage mode changed from old partition way (old version) to manufacturing nvs way (new version). The ATPKI.py is only applicable for the old partition storage mode. So we removed it on master branch.

2. Why are we using manufacturing nvs way on the master?

Before manufacturing nvs storage method, AT uses different partitions for storage configurations. It has the following drawbacks (including but not limited to):

• Low usage rate of flash
  The partition occupies is large, resulting in low effective utilization of this portion of the flash.
  For example 1: The certificate partitions are planned with a size of 8KB or 4KB each, but in reality, only 1KB+ is needed.
  For example 2: Some partitions are not used by customers but still occupy a significant amount of flash, such as certificates for connecting to enterprise-ap routers.
• Lack flexibility
  For example 1: For mass-produced products, different modules may have different configurations (different certificates, private keys, etc.), making it impossible to directly generate differentiated firmware binaries for different modules.
  For example 2: If a customer wants to expand the configuration, they must reorganize the secondary partition table and recompile.
• Risk of over-erasure
  For example: Due to non-robust code, frequent updates to a specific configuration result in erasing and writing a sector every time through partition read/write at a fixed address, which reduces the lifespan of the flash. However, if the new nvs way is used for read/write operations, the number of sector erasures can be significantly reduced, thereby extending the lifespan of the flash.

Based on the above considerations, starting from v3.1.0.0 and later versions, the manufacturing nvs way will be used instead of the partition way to store configurations in the secondary partitions. This allows for dynamic flash allocation and facilitates scalability requirements.

3. Is it compatible with older versions?

Yes, in almost cases. The firmware will prioritize reading the mfg_nvs partition. If the partition is found, the firmware will read the parameters using the new manufacturing nvs storage method. If the partition is not found, the firmware will fall back to the old partition storage method for reading.
There is just a known breaking change, described here: https://github.com/espressif/esp-at/releases/tag/v3.1.0.0#breaking-changes

Please know, thanks.
~

[MaJerle]

When we can expect 3.1 for all ESP32xx modukes?

[ustccw]

When we can expect 3.1 for all ESP32xx modukes?

Yes, we are preparing version v3.2.0.0 for ESP32 and ESP32-C3. It is currently in testing phase and expected to be released in early July.

[MaJerle]

I've seen the release v3.2 for ESP32. How shall we now setup the custom certificate file to be loaded to the device? Any tutorial on that available? Just raw data as-is, without having to setup header around the data, like it was in the atPKY.py ?

[ustccw]

Hello @MaJerle,

1). In the runtime, MCU sends AT+SYSMFG command to update certificates or keys, or any other configurable parameters. In terms of functionality, a crude understanding would be like: AT+SYSMFG ~= (AT+SYSFLASH + ATPKI.py)

This way requires MCU to send AT command, beside it, users could consider more ways to update this kind of parameters:

2). Modify the released firmware by using at.py tool, refer to Detailed Steps for more details.

3). In the compile stage, users can refer to How to Update PKI Configuration to update these configurations.

[MaJerle]

3. What about at runtime? So that we can keep offi ual AT firmware release as is?

[ustccw]

sorry that I didn't catch up your point, could you please describe it in details?