puya: add support for PY32F002B, PY32F003, PY32F030, PY32x07x #2000

Please suffix these with U so they are defined unsigned.

Please suffix all these constants with U so they are defined unsigned and don't do a signed-unsigned conversion on assignment.

With the number of magic numbers involved, it might make sense to name them via #defines's.

Fixed locally; will push together with the other changes once they are done.

Fixed locally; will push together with the other changes once they are done.

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.

Changed locally to use defines named like PY32F002A_EPPARA0_TS0_SHIFT / ..._MASK and tested successfully on PY32F002B. Waiting for reply from @ArcaneNibble before pushing.

Excellent, let's hope that they get back to you on this query fairly soon then 🙂

It's been a week without feedback from @ArcaneNibble so we'll probably need to continue without their assistance.

I've had a closer look at this and it's quite a mess. The PY32F002A Reference Manual says EPPARA4 26:16 (11 bit) contain the PRETPE value but that it's 12 bit wide (11:0). Also FLASH_PRETPE is 14 bit wide (13:0) and must be initialised from the value in EPPARA4. So there are 3 different bit widths documented for what should be the same value. In addition the PY32F002A flash driver (PY32F0xx_20.FLM) contained in the Keil Device Family Pack v1.2.1 (archive.org copy) provided by Puya stores the full upper 16 bits of EPPARA4 into FLASH_PRETPE. So I'm going to assume that the reserved bits are 0 and will keep the 0x3fff mask which matches the documented FLASH_PRETPE size (14 bits) and has been tested before.

Given the conflicting documentation and such, that seems like a solid plan. If it turns out to be wrong in some way, a further PR can be opened and merged to fix it - so no worries there.

Hi, our personal life has been a bit on fire. Apologies. I hope to review this in a few hours.

cc our partner @jediminer543 to see if she has any spoons to look at it

Ah, thanks for getting back to this - sorry to hear you're having personal life troubles and thank you for putting time in to this despite that.

Okay, we've gone and double-checked:

• the mask 0x3fff (14 bits) is what the vendor HAL uses (in py32f0xx_hal_flash.h)
• the mask 0xffff (16 bits) is what the vendor DFP uses (in FlashPrg.c), but we did not look in this code or notice it when originally implementing support
• the "PY32F030 Reference Manual V1.1" (English) indeed has all of the inconsistencies pointed out above. This appears to be the only source floating around on my hard drive which indicates anything fewer than 14 bits
• the "PY32F002A 参考手册 V1.1" (Chinese) is internally consistent, indicating 14 bits everywhere

This appears... most consistent with keeping the mask as 0x3fff for now?

As a separate issue, the PY32F002A is widely suspected to contain the same die as the PY32F030. It's not clear whether or not the 002A and the 030 would have different DEV_ID in the IDCODE (i.e. does IDCODE identify the die? the final packaged part? something else entirely?). I wouldn't be entirely confident in asserting that 0x60001000 is definitely the 002A, but I don't know how you'd want to handle this without additional information (I don't have any 030 around)

Incidentally, the 002A seems to have disappeared from the vendor's website entirely (the 002B is still there, but the 002B is suspected to be a different die). I can't find any PCNs regarding it (or any PCNs at all), so I don't know what to make of this.

Some hardware tests on a PY32F002A that happened to be on hand:

• FLASH_PRETPE contains 14 settable bits, with the rest being ignored

(gdb) set *(int*)0x40022120 = 0xffffffff
(gdb) x/1xw 0x40022120
0x40022120:	0x00003fff

• the calibration value at 0x1fff0f7c (aka EPPARA4 for 24 MHz) contains the value 0x12c05dc0. This means that 11 or 12 bits is probably not correct

In conclusion, 14 bits is likely the correct width for the PRETPE calibration value.

That's excellent - hopefully that gets silbe sorted out on what needs to happen here so this PR can get finished up then 😄

@ArcaneNibble Thanks a lot for spending the time and all the information! Good to know that there are differences between the English and Chinese versions of the datasheet even regarding bit assignments in the registers. I just checked for the PY32F002B and indeed the Chinese version is more consistent. 😕

Agree that we should stick with 14 bits for the PY32F002A. Regarding the chip/driver identification string, until somebody tries this with a PY32F030 we won't know a) what its ID code is and b) whether it will actually work with the current code. So displaying "PY32F002A" would be the best match for now IMO (but I don't feel strongly about it). It also has the highest chance of getting reports from users when PY32F030 happens to work (which means we can ask them for the ID code that was matched).

FYI: After adding the comment regarding EPPARA4 for PY32F002A I retested mostly pro forma and ran into lots of trouble. Even the previous version which worked fine last week now shows intermittent failures. Of course, the less debug output is provided, the more likely it is to fail, with direct usage of the "serial" interface from GDB failing quite often (so I guess it's timing related in some way).
Configuring the SWD frequency to around 100kHz (actual frequency around 190kHz) did not help.
I also tried not writing the timing parameters in puya_flash_prepare() as both PY32F002Bxx_24.FLM and CMSIS/Flash/PY32F002Bxx/FlashPrg.c in the Puya Keil DFP don't do this either, but the effects are the same.

Guess I need to attach a logic analyser to find out what failed. It'll probably be a while until I get around to that so I will mark this MR as draft and push the current code in case somebody else wants to pick it up in the meantime.

BTW, thanks for the review so far!