Skip to content
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

Open
huming2207 opened this issue Feb 27, 2023 · 4 comments
Open

Feature suggestion: read chip UID and self testing functions? #5

huming2207 opened this issue Feb 27, 2023 · 4 comments

Comments

@huming2207
Copy link

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 same ReadChipUID() to retrieve the UID number without knowing where the address is.

Regards,
Jackson

@huming2207
Copy link
Author

If you are happy to take some PRs like this, I will start working on it and submit the changes. :)

@Yatekii
Copy link
Member

Yatekii commented Feb 27, 2023

I would love a solution for this.
But it's a tricky thing to get right I think. Because every chip has completely different features/properties. So I am not sure how to approach this best or make such an interface.
Do you have any specific ideas?

@huming2207
Copy link
Author

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 int32_t SelfTest() I guess, and return a signed 32-bit value to indicate the test result.

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 uint32_t ReadChipID(uint32_t addr), and it returns the length of chip ID, and the addr is an unused RAM address on the chip, and the debug probe can read out that RAM address after this function is executed.

Regards,
Jackson

@huming2207
Copy link
Author

@Yatekii I think it might be more worth it to implement the Verify() function first. This is a standard flash algorithm function but it seems like it hasn't been implemented in this template project yet. If I have this function, I can customise the behaviour and let it test out the peripherals I want after verifying the flash, and return the status afterwards.

I will see if I can get a PR submitted later for adding this function into this project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants