-
-
Notifications
You must be signed in to change notification settings - Fork 770
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Add support for Arterytek MCU AT32F405, F402 #1949
base: main
Are you sure you want to change the base?
Conversation
a352680
to
b18c2f1
Compare
Enhanced support detail for AT32F405. Added nominal support for AT32F423 as well. Added doc references. Not tested. |
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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