From dc5b52a7870f03d970a646cf9a2ef92a3df696aa Mon Sep 17 00:00:00 2001 From: Mohamed-dek Mohamed Date: Mon, 4 May 2026 14:43:28 -0500 Subject: [PATCH 1/4] add dcp folder --- .../amds/daisy-chain-protocol/index.md | 155 ++++++++++++++++++ .../tutorials/profiling-tasks/index.md | 4 + 2 files changed, 159 insertions(+) create mode 100644 source/accessories/amds/daisy-chain-protocol/index.md diff --git a/source/accessories/amds/daisy-chain-protocol/index.md b/source/accessories/amds/daisy-chain-protocol/index.md new file mode 100644 index 00000000..a61440a0 --- /dev/null +++ b/source/accessories/amds/daisy-chain-protocol/index.md @@ -0,0 +1,155 @@ +# Daisy Chain Protocol + +This document describes the design consideration, implementation details, and board interface details for the sensor mainboard. A block diagram is presented and each component is discussed in detail. + +## Relevant Hardware Versions + +AMDS REV D + +## Application / Purpose + +The mainboard is specifically designed to interface directly to the [GPIO expansion port on the AMDC](/hardware/subsystems/expansion-port.md). + +## Features + +- Can connect up to 8 sensor cards. +- Can communicate with an external controller (like AMDC). An external controller can obtain the measurement results and also is allowed to control the digital conversion process. +- Robust differential IO communication is used to transmit sensor data to an external controller. +- High throughput of up to 1 MSPS (depending on ADC device on sensor cards). + +## Block Diagram and SPI Connection Configuration + +The eight sensor cards transmit data to the STM32 MCU using standard SPI protocol. The sensor cards are grouped into four pairs of daisy chain connections. See the following block diagram. + +![](images/Measurementboard_REVD.svg) + +![](images/Motherboard_3d.png) + +The sensor cards can be connected in daisy chain pair configuration (D) or single SPI configuration (S). The daisy chain configuration will have a throughput of 500 kSPS. If the number of sensor cards is less than or equal to four, then a single SPI configuration can be used to get higher throughput. This single SPI configuration will have a throughput of 1 MSPS. The configuration can be changed using jumpers (P9, P10, P15, P16) as shown in the following figure. + +![](images/Jumper_modes.png) + +## External Connections + +There are two interfacing DB-15 connectors on the measurement board. The first connector is used for interfacing with the controller (the AMDC driver) via differential I/O. The second connector is intended to connect to an external expansion for the AMDS, and is connected back to the GPIO port of the MCU on the AMDS mainboard. + +### DB15 Connector 1: AMDC Link (connects to a GPIO port on the AMDC) + +| Pin number | Signal name | Voltage level | Protocol | +|------------|--------|--------|--------| +| 1 | 5V_IN | 5V | - | +| 2 | DATA0_P | 5V | Differential IO | +| 3 | DATA0_N | 5V | Differential IO | +| 4 | DATA1_P | 5V | Differential IO | +| 5 | DATA1_N | 5V | Differential IO | +| 6 | NC | - | - | +| 7 | isoSPI2_P | 5V | IsoSPI | +| 8 | isoSPI2_N | 5V | IsoSPI | +| 9 | isoSPI3_P | 5V | IsoSPI | +| 10 | isoSPI3_N | 5V | IsoSPI | +| 11 | GND | - | - | +| 12 | SYNC_ADC_P | 5V | Differential IO | +| 13 | SYNC_ADC_N | 5V | Differential IO | +| 14 | SYNC_TX_P | 5V | Differential IO | +| 15 | SYNC_TX_N | 5V | Differential IO | + +> **NOTE:** The IsoSPI interface on pins 7-10 is a legacy interface and is not used. Only the differential I/O pins are used for signals between the AMDC and AMDS. + +### DB15 Connector 2: AMDS GPIO Link + +| Pin number | Signal name | Voltage level | +|------------|--------|--------| +| 1 | 3V3 | 3.3V | +| 2 | GPIO_1 | 3.3V | +| 3 | GPIO_2 | 3.3V | +| 4 | GPIO_3 | 3.3V | +| 5 | GPIO_4 | 3.3V | +| 6 | GPIO_5 | 3.3V | +| 7 | GPIO_6 | 3.3V | +| 8 | GPIO_7 | 3.3V | +| 9 | GPIO_8 | 3.3V | +| 10 | GPIO_9 | 3.3V | +| 11 | GPIO_10 | 3.3V | +| 12 | GPIO_11 | 3.3V | +| 13 | GPIO_12 | 3.3V | +| 14 | GND | - | +| 15 | GND | - | + +Implementation details of [IsoSPI](#isospi_comm_interface) and [Differential IO](#diff-io-transceiver) is described later in the document. + +## Systems on Board + +Per the block diagram above, the mainboard is made of several systems, as explained below. + +### STM32F7 Microcontroller + +STM32F7 microcontroller is used as an interface between the sensor card and an external controller. This MCU has a core ARM 32-bit Cortex M7 CPU. This IC can operate at a supply voltage of 1.7 V to 3.6 V. JTAG / SWD interface is used for debugging and programming the MCU. It has 6 SPIs which is used for sensor card and AMDC isoSPI interfaces. The maximum speed of the MCU SPI interface is 54 Mbps. It has 4 USART with a maximum baud rate of 26 Mbps, which are used to transmit sensor card data to the AMDC. GPIO pins of the MCU can be accessed using GPIO connector. More information on this MCU can be found [here](https://www.st.com/content/ccc/resource/technical/document/datasheet/group3/c5/37/9c/1d/a6/09/4e/1a/DM00273119/files/DM00273119.pdf/jcr:content/translations/en.DM00273119.pdf). + +(diff-io-transceiver)= +### Differential IO Isolated Transceiver + +The MCU transmits sensor data via USART communication. These USART signals are converted to differential IO using differential transceiver [ISO3086T](https://www.ti.com/lit/ds/symlink/iso3086t.pdf?HQS=TI-null-null-digikeymode-df-pf-null-wwe&ts=1596613093516). Differential IO has the ability to communicate over long distances and at faster communication rate compared to standard USART. This IC has an in-built isolation barrier. A signaling rate of up to 20 Mbps is obtained from this IC. The operating voltage is provided in the following table. + +| Parameter | Conditions | MIN | MAX | +|---------------------------------------|-------------------|---------|-------| +| Supply voltage VCC2 (Bus-side) | | 4.5 V | 5.5 V | +| IO supply voltage VCC1 (UART side) | 3.3V operation | 3 V | 3.6 V | +| IO supply voltage VCC1 (UART side) | 5V operation | 4.5 V | 5 V | + +The maximum supply current consumed by the IC including to drive currents for differential lines is 60 mA, which corresponds to 300 mW for 5 V supply. + +(isospi_comm_interface)= +### IsoSPI Communication Interface + +The isoSPI communication interface is implemented using [LTC6820](https://www.analog.com/media/en/technical-documentation/data-sheets/LTC6820.pdf). This IC provides a bi-directional interface between standard SPI signals and differential pulses. The operating conditions are provided in the following table. + +| Parameter | Conditions | MIN | MAX | +|---------------------------------------|-------------------|---------|-------| +| Supply voltage VDD (Differential side)| | 2.7 V | 5.5 V | +| IO supply voltage VDDS (SPI side) | | 1.7 V | 5.5 V | +| High-level input voltage |VDDS = 2.7V to 5V | 0.7 VDDS| VDDS | +| High-level input voltage |VDDS = 1.7V to 2.7V| 0.8 VDDS| VDDS | +| Low-level input voltage |VDDS = 2.7V to 5V | 0 | 0.3 VDDS | +| Low-level input voltage |VDDS = 1.7V to 2.7V| 0 | 0.2 VDDS | + +This IC can operate at a maximum SPI communication speed of 1 Mbps. The bias resistors (`RB1` and `RB2`) are used to adjust the drive currents to the differential lines. These resistors are selected such that the drive currents are set at 10 mA. These resistors are on the schematic, see the following figure. + +![](images/Schematic_RB.png) + +The maximum supply current consumed by the IC including to drive currents for differential lines is 17 mA, which corresponds to 85 mW for 5 V supply. + +### IsoSPI Isolation Transformer + +A transformer is required for implementing isoSPI. This will provide an isolation barrier to the differential SPI signals. This is implemented by adding pulse transformer HX1188NLT, which has 1:1 turns ratio. More information on the pulse transformer is found in the [datasheet](https://media.digikey.com/pdf/Data%20Sheets/Pulse%20PDFs/10_100BASE-T%20Single%20Port%20SMD%20Magnetics_Rev2008.pdf). + +## Sensor Card Interface + +In order to design a daugter card, the interface information provided in this section will be useful. Each sensor card slot has two headers, where the sensor card can be plugged in. See the following figure. + +![](images/DC_hdr.png) + +One header is used to supply power to the cards and the other header is used for SPI interface. + +### Header 1: Power Supply + +| Pin number | Signal name | +|------------|--------| +| 1 | +15V | +| 2 | GND | +| 3 | -15V | + +### Header 2: SPI interface + +| Pin number | Signal name | +|------------|--------| +| 1 | 5V | +| 2 | 3V3 | +| 3 | GND | +| 4 | DIN (ADC IN, MOSI) | +| 5 | SCLK | +| 6 | DOUT (ADC OUT, MISO) | +| 7 | CONVST (Conversion start) | + +For information regarding the placement of the headers, refer to the mainboard PCB Altium file in the AMDS repo located: `/Mainboard/altium/SensorMotherBoard.PcbDoc`. + +For more information on designing a sensor card, refer the [sensor card documentation](/accessories/amds/sensor-cards/index.md). \ No newline at end of file diff --git a/source/getting-started/tutorials/profiling-tasks/index.md b/source/getting-started/tutorials/profiling-tasks/index.md index 34c817e5..990ab0de 100644 --- a/source/getting-started/tutorials/profiling-tasks/index.md +++ b/source/getting-started/tutorials/profiling-tasks/index.md @@ -64,6 +64,10 @@ int task_controller_init(void) // ... ``` +```{warning} +Ensure that you +``` + Next, add task functions which wrap the `print()` and `reset()` functions for the timing stats: `task_controller.c`: From 6b51838b24318d35a0a0a7d032b3cf273c9c6375 Mon Sep 17 00:00:00 2001 From: Mohamed-dek Mohamed Date: Mon, 4 May 2026 15:32:23 -0500 Subject: [PATCH 2/4] add initial docs and changes to firmware docs --- .../amds/daisy-chain-protocol/index.md | 161 +++--------------- source/accessories/amds/firmware/index.md | 6 + source/accessories/amds/index.md | 1 + 3 files changed, 30 insertions(+), 138 deletions(-) diff --git a/source/accessories/amds/daisy-chain-protocol/index.md b/source/accessories/amds/daisy-chain-protocol/index.md index a61440a0..57167e2e 100644 --- a/source/accessories/amds/daisy-chain-protocol/index.md +++ b/source/accessories/amds/daisy-chain-protocol/index.md @@ -1,155 +1,40 @@ # Daisy Chain Protocol -This document describes the design consideration, implementation details, and board interface details for the sensor mainboard. A block diagram is presented and each component is discussed in detail. +This document outlines the architecture, setup, and features of the Daisy Chain protocol implementation, allowing robust data routing, selective sampling, and high-speed multi-board communication. -## Relevant Hardware Versions +## Multi-Target Firmware Project (Custom Build Configurations) -AMDS REV D +The firmware is designed to operate on multiple target hardware platforms using a single, unified codebase. -## Application / Purpose +- **Target Definitions**: The firmware uses `TARGET_AMDS` and `TARGET_2S` preprocessor macros to conditionally compile board-specific configurations. +- **Dynamic Peripheral Assignment**: Depending on the selected target, the system correctly configures the corresponding hardware peripherals. For example, `TARGET_AMDS` utilizes `UART4` and `UART5` for the Daisy Chain RX lines, while `TARGET_2S` relies on `USART6` and `USART1`. +- **Custom Run Configurations**: You can program either an AMDS or other devices without creating separate project branches, simply by toggling the target macro in your build/run configurations. -The mainboard is specifically designed to interface directly to the [GPIO expansion port on the AMDC](/hardware/subsystems/expansion-port.md). +## Direct Memory Access (DMA) Setup for Receiving Data -## Features +To ensure zero-CPU overhead when receiving incoming UART data, the protocol utilizes DMA streams. -- Can connect up to 8 sensor cards. -- Can communicate with an external controller (like AMDC). An external controller can obtain the measurement results and also is allowed to control the digital conversion process. -- Robust differential IO communication is used to transmit sensor data to an external controller. -- High throughput of up to 1 MSPS (depending on ADC device on sensor cards). +- **Circular Buffers**: Incoming daisy-chain data is placed into `DAISY_RX1_Pool` and `DAISY_RX2_Pool`, both of which are 256-byte circular buffers (`AMDS_RX_BUF_SIZE`). Utilizing a 256-byte size allows for 8-bit integer math to handle wrap-around without complex modulo logic. +- **Error Recovery**: In high-noise environments, UART hardware errors (Parity, Overrun, Noise, or Frame errors) can cause the hardware to drop the `DMAR` (DMA Receiver) bit, halting the stream. The UART Interrupt Service Routines (ISRs) actively monitor for these flags, clear them, and immediately re-enable the DMA requests to ensure continuous stream operation without resetting the device. -## Block Diagram and SPI Connection Configuration +## Selective Channel Transmitting -The eight sensor cards transmit data to the STM32 MCU using standard SPI protocol. The sensor cards are grouped into four pairs of daisy chain connections. See the following block diagram. +To optimize processing and transmission bandwidth, the system supports disabling unused sensor channels. -![](images/Measurementboard_REVD.svg) +- **Active Sensor Mask**: A global variable `active_sensor_mask` acts as a bitmask where `1 = Active` and `0 = Inactive`. +- **Target Defaults**: By default, `TARGET_AMDS` activates all 8 channels (`0xFF`), while `TARGET_2S` activates a subset of channels (`0x11`). -![](images/Motherboard_3d.png) +## Modified Sample-and-Transmit Fast Path -The sensor cards can be connected in daisy chain pair configuration (D) or single SPI configuration (S). The daisy chain configuration will have a throughput of 500 kSPS. If the number of sensor cards is less than or equal to four, then a single SPI configuration can be used to get higher throughput. This single SPI configuration will have a throughput of 1 MSPS. The configuration can be changed using jumpers (P9, P10, P15, P16) as shown in the following figure. +The firmware bypasses standard abstraction overhead to achieve low latency during critical sampling and transmission windows via the `adc_sample_and_transmit_fast_path` function. -![](images/Jumper_modes.png) +- **Hardware Cycle Counting**: Rather than using `NOP` loops for the mandatory 1300ns ADC wait time, the fast path uses the Cortex-M7 DWT Cycle Counter (`DWT->CYCCNT`) for deterministic waiting. +- **Instruction Interleaving**: The code optimizes wait states by starting SPI reads, and transmitting UART header bytes (`0x90`) while the CPU is waiting for the SPI RX buffers to fill. -## External Connections +## Process Routing Architecture -There are two interfacing DB-15 connectors on the measurement board. The first connector is used for interfacing with the controller (the AMDC driver) via differential I/O. The second connector is intended to connect to an external expansion for the AMDS, and is connected back to the GPIO port of the MCU on the AMDS mainboard. +Handling high-speed daisy-chained data relies on the `try_process_routing()` and `process_routing()` implementations. -### DB15 Connector 1: AMDC Link (connects to a GPIO port on the AMDC) - -| Pin number | Signal name | Voltage level | Protocol | -|------------|--------|--------|--------| -| 1 | 5V_IN | 5V | - | -| 2 | DATA0_P | 5V | Differential IO | -| 3 | DATA0_N | 5V | Differential IO | -| 4 | DATA1_P | 5V | Differential IO | -| 5 | DATA1_N | 5V | Differential IO | -| 6 | NC | - | - | -| 7 | isoSPI2_P | 5V | IsoSPI | -| 8 | isoSPI2_N | 5V | IsoSPI | -| 9 | isoSPI3_P | 5V | IsoSPI | -| 10 | isoSPI3_N | 5V | IsoSPI | -| 11 | GND | - | - | -| 12 | SYNC_ADC_P | 5V | Differential IO | -| 13 | SYNC_ADC_N | 5V | Differential IO | -| 14 | SYNC_TX_P | 5V | Differential IO | -| 15 | SYNC_TX_N | 5V | Differential IO | - -> **NOTE:** The IsoSPI interface on pins 7-10 is a legacy interface and is not used. Only the differential I/O pins are used for signals between the AMDC and AMDS. - -### DB15 Connector 2: AMDS GPIO Link - -| Pin number | Signal name | Voltage level | -|------------|--------|--------| -| 1 | 3V3 | 3.3V | -| 2 | GPIO_1 | 3.3V | -| 3 | GPIO_2 | 3.3V | -| 4 | GPIO_3 | 3.3V | -| 5 | GPIO_4 | 3.3V | -| 6 | GPIO_5 | 3.3V | -| 7 | GPIO_6 | 3.3V | -| 8 | GPIO_7 | 3.3V | -| 9 | GPIO_8 | 3.3V | -| 10 | GPIO_9 | 3.3V | -| 11 | GPIO_10 | 3.3V | -| 12 | GPIO_11 | 3.3V | -| 13 | GPIO_12 | 3.3V | -| 14 | GND | - | -| 15 | GND | - | - -Implementation details of [IsoSPI](#isospi_comm_interface) and [Differential IO](#diff-io-transceiver) is described later in the document. - -## Systems on Board - -Per the block diagram above, the mainboard is made of several systems, as explained below. - -### STM32F7 Microcontroller - -STM32F7 microcontroller is used as an interface between the sensor card and an external controller. This MCU has a core ARM 32-bit Cortex M7 CPU. This IC can operate at a supply voltage of 1.7 V to 3.6 V. JTAG / SWD interface is used for debugging and programming the MCU. It has 6 SPIs which is used for sensor card and AMDC isoSPI interfaces. The maximum speed of the MCU SPI interface is 54 Mbps. It has 4 USART with a maximum baud rate of 26 Mbps, which are used to transmit sensor card data to the AMDC. GPIO pins of the MCU can be accessed using GPIO connector. More information on this MCU can be found [here](https://www.st.com/content/ccc/resource/technical/document/datasheet/group3/c5/37/9c/1d/a6/09/4e/1a/DM00273119/files/DM00273119.pdf/jcr:content/translations/en.DM00273119.pdf). - -(diff-io-transceiver)= -### Differential IO Isolated Transceiver - -The MCU transmits sensor data via USART communication. These USART signals are converted to differential IO using differential transceiver [ISO3086T](https://www.ti.com/lit/ds/symlink/iso3086t.pdf?HQS=TI-null-null-digikeymode-df-pf-null-wwe&ts=1596613093516). Differential IO has the ability to communicate over long distances and at faster communication rate compared to standard USART. This IC has an in-built isolation barrier. A signaling rate of up to 20 Mbps is obtained from this IC. The operating voltage is provided in the following table. - -| Parameter | Conditions | MIN | MAX | -|---------------------------------------|-------------------|---------|-------| -| Supply voltage VCC2 (Bus-side) | | 4.5 V | 5.5 V | -| IO supply voltage VCC1 (UART side) | 3.3V operation | 3 V | 3.6 V | -| IO supply voltage VCC1 (UART side) | 5V operation | 4.5 V | 5 V | - -The maximum supply current consumed by the IC including to drive currents for differential lines is 60 mA, which corresponds to 300 mW for 5 V supply. - -(isospi_comm_interface)= -### IsoSPI Communication Interface - -The isoSPI communication interface is implemented using [LTC6820](https://www.analog.com/media/en/technical-documentation/data-sheets/LTC6820.pdf). This IC provides a bi-directional interface between standard SPI signals and differential pulses. The operating conditions are provided in the following table. - -| Parameter | Conditions | MIN | MAX | -|---------------------------------------|-------------------|---------|-------| -| Supply voltage VDD (Differential side)| | 2.7 V | 5.5 V | -| IO supply voltage VDDS (SPI side) | | 1.7 V | 5.5 V | -| High-level input voltage |VDDS = 2.7V to 5V | 0.7 VDDS| VDDS | -| High-level input voltage |VDDS = 1.7V to 2.7V| 0.8 VDDS| VDDS | -| Low-level input voltage |VDDS = 2.7V to 5V | 0 | 0.3 VDDS | -| Low-level input voltage |VDDS = 1.7V to 2.7V| 0 | 0.2 VDDS | - -This IC can operate at a maximum SPI communication speed of 1 Mbps. The bias resistors (`RB1` and `RB2`) are used to adjust the drive currents to the differential lines. These resistors are selected such that the drive currents are set at 10 mA. These resistors are on the schematic, see the following figure. - -![](images/Schematic_RB.png) - -The maximum supply current consumed by the IC including to drive currents for differential lines is 17 mA, which corresponds to 85 mW for 5 V supply. - -### IsoSPI Isolation Transformer - -A transformer is required for implementing isoSPI. This will provide an isolation barrier to the differential SPI signals. This is implemented by adding pulse transformer HX1188NLT, which has 1:1 turns ratio. More information on the pulse transformer is found in the [datasheet](https://media.digikey.com/pdf/Data%20Sheets/Pulse%20PDFs/10_100BASE-T%20Single%20Port%20SMD%20Magnetics_Rev2008.pdf). - -## Sensor Card Interface - -In order to design a daugter card, the interface information provided in this section will be useful. Each sensor card slot has two headers, where the sensor card can be plugged in. See the following figure. - -![](images/DC_hdr.png) - -One header is used to supply power to the cards and the other header is used for SPI interface. - -### Header 1: Power Supply - -| Pin number | Signal name | -|------------|--------| -| 1 | +15V | -| 2 | GND | -| 3 | -15V | - -### Header 2: SPI interface - -| Pin number | Signal name | -|------------|--------| -| 1 | 5V | -| 2 | 3V3 | -| 3 | GND | -| 4 | DIN (ADC IN, MOSI) | -| 5 | SCLK | -| 6 | DOUT (ADC OUT, MISO) | -| 7 | CONVST (Conversion start) | - -For information regarding the placement of the headers, refer to the mainboard PCB Altium file in the AMDS repo located: `/Mainboard/altium/SensorMotherBoard.PcbDoc`. - -For more information on designing a sensor card, refer the [sensor card documentation](/accessories/amds/sensor-cards/index.md). \ No newline at end of file +- **Thread-safe Invocation**: The main `while(1)` loop constantly checks `drv_uart_has_dma_data()` and invokes `try_process_routing()`. This wrapper uses an atomic lock (`is_routing_active`) to safely avert reentrancy without stalling the CPU or permanently blinding interrupts. +- **Dual-Stream Optimization**: Inside `process_routing()`, if both UART streams have at least a full 3-byte packet ready, the logic processes them completely interleaved. This keeps both hardware TX lines saturated simultaneously. +- **Single-Stream and Slow Path**: If one UART runs slightly faster, it employs a Single-Stream Fast Path. If a packet gets fragmented across a DMA boundary or becomes misaligned, the system reverts to a 1-byte-at-a-time State Machine (the "Slow Path") to recover the stream automatically. diff --git a/source/accessories/amds/firmware/index.md b/source/accessories/amds/firmware/index.md index 328de436..16fcb0e0 100644 --- a/source/accessories/amds/firmware/index.md +++ b/source/accessories/amds/firmware/index.md @@ -64,6 +64,12 @@ The message structure is equal between both `DATA0` and `DATA1`. However, each m _NOTE: there is no full CRC included in the transmission. The simple protocol relies on the parity check in the UART packet. This is not a terribly robust approach, but has worked well is moderate EMI environments._ +### Daisy Chain Protocol Implementation + +The physical routing, interleaving, and transmission of the sensor data across the dual UART TX lines are managed by a specialized firmware implementation known as the Daisy Chain Protocol. This protocol leverages DMA (Direct Memory Access) streams, selective channel masking, and a thread-safe routing architecture to ensure zero-CPU-overhead data receiving. + +For a comprehensive breakdown of the DMA setup and the modified sample-and-transmit fast path, please refer to the detailed [Daisy Chain Protocol Documentation](../daisy-chain-protocol/index.md). + ### Interrupt-Driven Design After start-up, the AMDS firmware is completely interrupt driven. This means that all processing occurs within an interrupt context, not the main loop. The interrupt which used to drive the firmware occurs on the rising and falling edges of the `SYNC_ADC` signal. diff --git a/source/accessories/amds/index.md b/source/accessories/amds/index.md index bc617c53..7ce6d861 100644 --- a/source/accessories/amds/index.md +++ b/source/accessories/amds/index.md @@ -40,6 +40,7 @@ However, it is a complete system which could be interfaced to any other host dev amds-in-action/index firmware/index +daisy-chain-protocol/index mainboard/index sensor-cards/index ``` \ No newline at end of file From 73a01e9c0384f4582a9391cf7f1c393d63fc0242 Mon Sep 17 00:00:00 2001 From: Mohamed-dek Mohamed Date: Mon, 4 May 2026 15:58:58 -0500 Subject: [PATCH 3/4] add initial building and flashing documentation --- source/accessories/amds/firmware/index.md | 2 + source/accessories/amds/flashing/index.md | 64 +++++++++++++++++++++++ source/accessories/amds/index.md | 1 + 3 files changed, 67 insertions(+) create mode 100644 source/accessories/amds/flashing/index.md diff --git a/source/accessories/amds/firmware/index.md b/source/accessories/amds/firmware/index.md index 16fcb0e0..3f55ecf3 100644 --- a/source/accessories/amds/firmware/index.md +++ b/source/accessories/amds/firmware/index.md @@ -70,6 +70,8 @@ The physical routing, interleaving, and transmission of the sensor data across t For a comprehensive breakdown of the DMA setup and the modified sample-and-transmit fast path, please refer to the detailed [Daisy Chain Protocol Documentation](../daisy-chain-protocol/index.md). +For instructions on programming the AMDS, please refer to [Building and Flashing Documentation](../flashing/index.md) + ### Interrupt-Driven Design After start-up, the AMDS firmware is completely interrupt driven. This means that all processing occurs within an interrupt context, not the main loop. The interrupt which used to drive the firmware occurs on the rising and falling edges of the `SYNC_ADC` signal. diff --git a/source/accessories/amds/flashing/index.md b/source/accessories/amds/flashing/index.md new file mode 100644 index 00000000..777f9470 --- /dev/null +++ b/source/accessories/amds/flashing/index.md @@ -0,0 +1,64 @@ +# Building and Flashing + +This guide provides step-by-step instructions on how to configure, build, and flash the AMDS firmware onto different hardware targets (e.g., AMDS and 2S). + +## Prerequisites + +- **IDE:** STM32CubeIDE (or your preferred C/C++ IDE configured for ARM Cortex-M development). +- **Hardware:** ST-Link V2/V3 or equivalent hardware debugger/programmer. +- **Target Board:** Either an AMDS board or AMDS-compatible board. + +## Step 1: Open the Project + +1. Launch STM32CubeIDE. +2. Go to **File > Open Projects from File System...** +3. Select the directory containing the firmware source code and click **Finish**. + +## Step 2: Set the Build Configuration (Target Macro) + +The firmware uses preprocessor macros to conditionally compile the correct peripheral assignments and active sensor masks for your specific board. + +1. Right-click on `motherboard_v1` and go to **Build Configuration > Set Active > AMDS or 2S** + +*Note: Alternatively, simply select the appropriate active configuration the Build "hammer" dropdown menu.* + +## Step 3: Build the Project + +1. **Clean** the project to ensure no artifact mix-ups from previous board builds: Go to **Project > Clean...** and select your project. +2. **Build** the project: Click the **Build** (hammer) icon or go to **Project > Build Project**. +3. Check the console output to ensure there are no compilation errors and that the build finishes successfully. + +```{important} +If you did not set the build configuration in the previous steps you will see many compilation errors that look like this: + +#error "Please define a target board (TARGET_AMDS or TARGET_2S)!" +``` + +## Step 4: Configure the Run/Debug Settings + +1. Connect your ST-Link to your PC and the target board's SWD (Serial Wire Debug) header. +2. Power on the target board. +3. In STM32CubeIDE, go to **Run > Debug Configurations...** +4. Double-click **STM32 Cortex-M C/C++ Application** to create a new configuration. +5. In the **Main** tab, ensure the correct `.elf` file is selected from your recent build. +6. In the **Debugger** tab, ensure the Debug probe is set to **ST-LINK** and the interface is set to **SWD**. +7. Click **Apply**. + +## Step 5: Flash and Verify + +1. Click **Debug** (or **Run**) from the configuration window to flash the firmware. +2. The IDE will connect to the board, erase the necessary flash sectors, and write the new firmware. +3. Once flashing is complete, if you are in Debug mode, click the **Resume** (play) button to start execution. +4. **Verification:** Observe the board's behavior. Depending on your configuration, verify that the active sensor mask operates correctly (AMDS enables all 8 channels `0xFF`, 2S enables a subset `0x11`) and that UART/DMA streams begin processing as expected. + +```{tip} +For the AMDS board, a good indicator that things are running smoothly is the 4 LEDS near the MCU blinking in order. +``` + +## Switching Between Boards + +Because the project shares a single codebase, programming a different board type is simple: + +1. Disconnect the current board and connect the new one. +2. Return to **Step 2** and swap the target macro. +3. Rebuild (Step 3) and Flash (Step 5). diff --git a/source/accessories/amds/index.md b/source/accessories/amds/index.md index 7ce6d861..4dcaf2da 100644 --- a/source/accessories/amds/index.md +++ b/source/accessories/amds/index.md @@ -41,6 +41,7 @@ However, it is a complete system which could be interfaced to any other host dev amds-in-action/index firmware/index daisy-chain-protocol/index +flashing/index mainboard/index sensor-cards/index ``` \ No newline at end of file From b994a35b27cd5a938a6895573cc262a434dbdcef Mon Sep 17 00:00:00 2001 From: Mohamed-dek Mohamed Date: Mon, 4 May 2026 16:24:48 -0500 Subject: [PATCH 4/4] remove future improvement 4 --- source/accessories/amds/firmware/index.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/source/accessories/amds/firmware/index.md b/source/accessories/amds/firmware/index.md index 3f55ecf3..36e7c78c 100644 --- a/source/accessories/amds/firmware/index.md +++ b/source/accessories/amds/firmware/index.md @@ -125,5 +125,3 @@ The AMDS firmware works, albeit with limitations as described above. Some ideas 2. The total sampling and data transmission latency as seen by the master (AMDC) could be improved. In the current firmware, the time from when the `SYNC_ADC` line is toggled to when the newly sampled data has fully been received by the master is about 11 µs. This places limitations on the control rate of the master (AMDC). The improvements can come in several parts: 1) the actual ADC sampling time can be shorten by using the `BUSY` signal from each ADC in an ISR to end the ADC sampling window. These are not used in the current firmware. Instead, the simpler approach of busy waiting until the max timeout occurs is used (i.e. wait for 1300 ns). However, the nominal wait time is only about 50% of this. 2) The data transmission time could be shorten by removing/reducing the overhead in the packet format, i.e., removing the header bytes. 3. There is no robust CRC error detection on the data transmission from the AMDS to the master device, although the UART parity is used. Future improvements could add a footer CRC to ensure the received message at the master is valid. Error correction codes could also be used to further increase the communication robustness in high EMI environments (e.g. SECDED). There is no free lunch: all of these methods would increase the data transmission latency from the AMDS. - -4. There is no need to transmit the data from all eight sensor cards if they are not all populated. Theoretically, a user could run the AMDS interface MUCH faster with fewer sensor cards installed, if changes are made such that only real data acquired from populated sensor cards are transmitted back to the master.