-
-
Notifications
You must be signed in to change notification settings - Fork 7
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 suggestion: read chip UID and self testing functions? #5
Comments
If you are happy to take some PRs like this, I will start working on it and submit the changes. :) |
I would love a solution for this. |
Hi @Yatekii For that self-test function, I believe that might be a per-project basis thing that each firmware project needs its own test scheme. Thus they need to implement their own flash algorithm based on this template. The function signature can be For the UID reading function, that's easy - just need to return the value at the UID. However, how and where to return that UID is a problem. Maybe I guess the function signature can be Regards, |
@Yatekii I think it might be more worth it to implement the I will see if I can get a PR submitted later for adding this function into this project. |
Hi,
I'm wondering if you guys would like to have some sort of self-testing or reading chip UID functions. I can implement something like that but I'm not sure if that might be out of scope for this project or not. But I believe it may be quite useful for mass production purposes.
For example, I implement some functions (in C symbol, not Rust, that exposes to some customized offline programming probe or host-side debug program like
probe-rs
's YAML configs) like:ReadChipUID()
: read out the chip's unique ID (for STM32 it's 96-bit + some STM32s have an additional 64-bit unique MAC)SelfTest()
: do a simple, custom self-test, e.g. check if the UART/I2C/SPI communications with other external peripherals on the boards are working or not; return a zero result if successful, otherwise returns some non-zero values to indicate what has gone wrong.For
ReadChipUID()
, it can be done by asking the probe to read out the memory address directly (like STM32WL that's 0x1fff7590) but it's more for some sort of unification. Different chips have different UID addresses, and the host-side debug/mass production programs only need to call the sameReadChipUID()
to retrieve the UID number without knowing where the address is.Regards,
Jackson
The text was updated successfully, but these errors were encountered: