Feature: Add support for Arterytek MCU AT32F405, F402 #1949
Conversation
ALTracer
force-pushed
the
feature/at32f405
branch
4 times, most recently
from
a352680
to
b18c2f1
Compare
|
Enhanced support detail for AT32F405. Added nominal support for AT32F423 as well. Added doc references. Not tested. |
ALTracer
force-pushed
the
feature/at32f405
branch
from
b18c2f1
to
3acb590
Compare
* All of SRAM is declared regardless of parity checking * Two flash sizes are detected from idcode * DEBUG sleep and watchdog bits handling is enabled
ALTracer
force-pushed
the
feature/at32f405
branch
from
3acb590
to
93cc477
Compare
|
Tested to detect an AT32F437ZM device even under read protection level 1. That renders not just internal flash but also UID, F_SIZE, and option bytes, readable as 0xFF, but DEBUG_SER_ID can still be used on these three families for identification. |
| const bool read_protected = (flash_usd & AT32F43x_FLASH_USD_RDP) == AT32F43x_FLASH_USD_RDP; | ||
| if (read_protected) | ||
| DEBUG_TARGET("%s: Flash Access Protection enabled, UID reads as 0x%02x\n", __func__, uid_byte); | ||
| const uint8_t project_id = !read_protected ? uid_byte : (debug_ser_id >> 8U) & 0xffU; |
There was a problem hiding this comment.
If debug_ser_id is always readable, does it not make more sense (for simpler code) to just always use its value rather than uid_byte? - still report the UID value in the DEBUG_TARGET statement below just in case this assumption that they're always the same fails, but until that is ever found to be the case, just use it anyway so there's less logic and so Flash usage.
There was a problem hiding this comment.
No, it is not always present and readable, I have only confirmed it on the one F437 part I tested live on. DEBUG->SER_ID is absent from other Mainstream/Value Line/High Performance lineups, which I intended to migrate away from stm32f1.c into here once this driver learns to use FPEC_BASE, USD_BASE and size, etc.
However, speaking strictly per refmans, you're right that it should work for the three declared families like this, and I can drop the all-Arterytek-generic UID byte read for now (hide behind DEBUG_TARGET) in favor of 0xe0042020 which, when present, is guaranteed to be non-0xFF. I only really trust powered and scanned silicon (what if errata) but it's not on me to maintain this code. It can be re-added in the next refactor with scope widening. Initially here I only wanted F405 in tree.
Detailed description
at32f43_probe.I do not have any chips accessible for that target and cannot test live, only read refmans. FPEC is at 0x40023C00, which is promising. USD and DBGMCU support not considered yet.
The generic F_SIZE method was used to not carry yet another table of Part IDs.
Your checklist for this pull request
Closing issues