puya: add support for PY32F002B #2000
Conversation
The PY32F002B series uses different DBGMCU IDCODE values and there does not seem to be a register containing RAM and flash size. While the procedure for preparing flash access (copying parameters from factory-programmed EPPARAx registers to flash peripheral registers) is the same, the bit allocation inside the registers is slightly different. The structure and values of the DBGMCU IDCODE register are undocumented but the vendor SDK splits it into DEV_ID and REV_ID fields. We use the DEV_ID fields of the IDCODE values observed on PY32F002AW15U and PY32F002BF15P6 to distinguish between the two families. An internet search shows that at least the PY32F002BW15 uses the same value as the PY32F002BF15P6. The full IDCODE values are retained as comments to make it easier to fix the code later if it turns out the DEV_ID/REV_ID split is incorrect.
silbe
force-pushed
the
puya-add-py32f002b-support
branch
from
92cecd5
to
6090ecd
Compare
|
Rebased on |
There was a problem hiding this comment.
We love the reduction in unnamed magic numbers! Very curious that they chose to rework several registers' layouts like that too.. seems very odd. Our main review notes are on some signed-but-should-be-unsigned constants and the other is on a further reduction of magic numbers. With those taken care of we're happy to merge this.
| flash_size = 24 * 1024; | ||
| ram_size = 3 * 1024; |
There was a problem hiding this comment.
Please suffix all these constants with U so they are defined unsigned and don't do a signed-unsigned conversion on assignment.
There was a problem hiding this comment.
Fixed locally; will push together with the other changes once they are done.
| #define PUYA_DEV_ID_PY32F002A 0x000 | ||
| /* | ||
| * On PY32F002BF15P an IDCODE value of 0x20220064 was observed. Internet search shows the same value is used on | ||
| * PY32F002BW15. | ||
| */ | ||
| #define PUYA_DEV_ID_PY32F002B 0x064 |
There was a problem hiding this comment.
Please suffix these with U so they are defined unsigned.
There was a problem hiding this comment.
Fixed locally; will push together with the other changes once they are done.
| target_mem32_write32(flash->t, PUYA_FLASH_TS0, eppara0 & 0xffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_TS1, (eppara0 >> 16U) & 0x1ffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_TS3, (eppara0 >> 8U) & 0xffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_TS2P, eppara1 & 0xffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_TPS3, (eppara1 >> 16U) & 0x7ffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_PERTPE, eppara2 & 0x1ffffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_SMERTPE, eppara3 & 0x1ffffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_PRGTPE, eppara4 & 0xffffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_PRETPE, (eppara4 >> 16U) & 0x3fffU); | ||
| break; | ||
| case PUYA_DEV_ID_PY32F002B: | ||
| target_mem32_write32(flash->t, PUYA_FLASH_TS0, eppara0 & 0x1ffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_TS1, (eppara0 >> 18U) & 0x3ffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_TS3, (eppara0 >> 9U) & 0x1ffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_TS2P, eppara1 & 0x1ffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_TPS3, (eppara1 >> 16U) & 0xfffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_PERTPE, eppara2 & 0x3ffffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_SMERTPE, eppara3 & 0x3ffffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_PRGTPE, eppara4 & 0xffffU); | ||
| target_mem32_write32(flash->t, PUYA_FLASH_PRETPE, (eppara4 >> 16U) & 0x3fffU); |
There was a problem hiding this comment.
With the number of magic numbers involved, it might make sense to name them via #defines's.
There was a problem hiding this comment.
In progress. While doing so I noticed that the existing code uses additional bits from EPPARA4 for PRETPE (datasheet says 26:16 are PRETPE so the mask should be 0x7ff but the code uses 0x3fff). @ArcaneNibble was this on purpose? If not, would you be willing to test my changes if I fix this to match the datasheet values? I don't have a PY32F002A myself.
There was a problem hiding this comment.
Changed locally to use defines named like PY32F002A_EPPARA0_TS0_SHIFT / …_MASK and tested successfully on PY32F002B. Waiting for reply from @ArcaneNibble before pushing.
There was a problem hiding this comment.
Excellent, let's hope that they get back to you on this query fairly soon then 🙂
Detailed description
The PY32F002B series uses different DBGMCU IDCODE values and there does not seem to be a register containing RAM and flash size.
While the procedure for preparing flash access (copying parameters from factory-programmed EPPARAx registers to flash peripheral registers) is the same, the bit allocation inside the registers is slightly different.
The structure and values of the DBGMCU IDCODE register are undocumented but the vendor SDK splits it into DEV_ID and REV_ID fields. We use the DEV_ID fields of the IDCODE values observed on PY32F002AW15U and PY32F002BF15P6 to distinguish between the two families. An internet search shows that at least the PY32F002BW15 uses the same value as the PY32F002BF15P6. The full IDCODE values are retained as comments to make it easier to fix the code later if it turns out the DEV_ID/REV_ID split is incorrect.
Your checklist for this pull request
Closing issues