Add AMDS firmware changes to implement the DCP

[mohamed-dek1]

Closes #95

Notes

Anything reviewers should be aware of when reviewing? Other related issues? Known problems? Future work?

Self-Review

1. Are all files under 300 kB (if not, please carefully assess whether it is worth committing them)? Yes
2. Are all files named according to the appropriate naming convention, i.e., dash-case, camelCase, snake case? Yes
3. Do all Markdown files follow the CONTRIBUTING article template? Yes
4. Do all links work in the material that the PR is adding? Yes
5. Is the PR configured to close the correct issue(s)? Yes
6. Did the PR fully address the Approach section of the issue(s) it is closing? Yes

Reviewer Instructions

Reviewers, please copy and paste a suitable review checklist into your review and answer all questions.

Appendix

This section should be the same for all PRs. Do not edit this section when creating a PR.

Review Checklists

Checklists maintained by the eLev lab for research repositories include:

• Report checklist
• Publication archive checklist (select a checklist from the Approach that corresponds to the step this PR seeks to complete).
• Standard checklist (if none of the above apply).

Standard checklist

1. Are all files under 300 kB (if not, please carefully assess whether it is worth committing them)? **Yes or No**
2. Are all files named according to the appropriate [naming convention](https://github.com/Severson-Group/research-repo-template?tab=readme-ov-file#file-naming), i.e., dash-case, camelCase, snake case? **Yes or No**
3. Do all Markdown files follow the [CONTRIBUTING article template](https://github.com/Severson-Group/.github/blob/main/CONTRIBUTING.md#markdown-documentation-template)? **Yes or No**
4. Do all links work in the material that the PR is adding? **Yes or No**
5. Is the PR configured to close the correct issue(s)? **Yes or No**
6. Did the PR fully address the `Approach` section of the issue(s) it is closing? **Yes or No**

Please work on addressing any **No** items.

[mohamed-dek1]

We've implemented the Daisy Chain Protocol per this comment. However, we need to ensure that the current implementation meets the timing requirements for 3-phase current control. At this point in time, we are able to exchange data across 2 AMDS boards. The timing spec is not yet met. See

• this comment for the hardware test results: Modify the AMDS firmware to receive, handle, and send data from another AMDS as per the DCP spec. #100 (comment)
• this comment for the AMDC IP-Core commit that was used: Add AMDC Firmware changes to implement the DCP AMDC-Firmware#500 (comment)

[mohamed-dek1]

I'm able to run a single AMDS at 88KHz on my REVF AMDC with the release candidate. This is what @Daehoon-Sung is running in the cabinet for BP6. For some reason, when I program his AMDS boards with the new firmware, his AMDC is reporting corrupt data. One thing to note is that he has a REVE AMDC which is running (I'm assuming) the most recent released firmware for that board).

88KHz sampling and EVENT_RATIO of 2

AMDC counters

[mohamed-dek1]

I've also tested with 2 AMDS boards on 2 different GPIO ports and confirmed still working at 88KHz.

[Daehoon-Sung]

Hello @mohamed-dek1, for BP4, I am using REVE AMDC and it has the most recent released firmware (1.4.x) for that board. I believe @noguchi-takahiro and I have updated the most recently released firmware. See this page:

[mohamed-dek1]

The timing manager sensor acquisition time versus the Saleae measurement

AMDS_CH_ENABLE_REG: 0x000000F0

[mohamed-dek1]

I've programmed @Daehoon-Sung's AMDC with the new firmware and was able to read AMD data through it.

[elsevers]

We have thoroughly reviewed and tested this code. Time to squash and merge.

[elsevers]

This code has been thoroughly tested on multiple benches in the lab and is working well.

The only thing we are noticing is that there is a stastically impossible overflow event that can occur that would disrupt a packet of data:

AMDS/Mainboard/Firmware/mainboard/Core/Src/adc.c

Lines 155 to 160 in 818233e

	uint32_t wait_cycles = (SystemCoreClock / 1000000) * 13 / 10;
	// Deterministic wait for exactly 1300ns using hardware cycles, not NOPs
	while ((DWT->CYCCNT - start_cycles) < wait_cycles) {
	// Spin perfectly safely
	}

@AwesomeTornado is making an issue for this item. Otherwise, okay to proceed to merge.

[elsevers]

Looks like @AwesomeTornado resolved the merge conflicts and we are ready to merge this.