I am adapting this bootloader for STM32F373CC to my device. To indicate that the device is powered but in bootloader mode, I'd like to turn on some of the status LEDs. However, this bootloader doesn't use the STM Cube MX libraries, so I have to code it low-level. The header file stm32f373xc.h is included, so I can use expressions like GPIOB_BASE.
I tried the following first thing in main(), but unfortunately it doesn't work:
// turn on GPIOB clock: SET_BIT(RCC->AHBENR, RCC_AHBENR_GPIOBEN);
uint32_t* rcc = (uint32_t*)RCC_BASE;
*(rcc+0x14) |= RCC_AHBENR_GPIOBEN; // AHBENR is at offset 0x14
// configure Port B, pins 4 and 5 to GPIO, Open Drain, low.
uint32_t* gpiob = (uint32_t*)GPIOB_BASE;
*(gpiob) |= 0x500; // GPIO output mode --- GPIOB_MODER = 0x500; (bits 11:8 = 0101), offset 0
*(gpiob) &= ~0xA00;
*(gpiob+0x04) |= 0x30; // output type open drain --- GPIOB_OTYPER = 0x30; (bits 5:4 = 11), offset 0x04
*(gpiob+0x0c) &= ~0xF00; // pull up/down off --- GPIOB_PUPDR = 0x0; (bits 11:8 = 0000), offset 0x0c
*(gpiob+0x14) &= ~0x30; // output low --- GPIOB_ODR = 0x0; (bits 5:4 = 00), offset 0x14
Any ideas what I'm missing? How can I find out if the problem is the clocking of the Port B, or the pin configuration?
I found this similar post, but the first answer requires the entire CMSIS, and the second answer lacks comments, so I don't fully understand what they are doing.
I hope that you know that open-drain outputs require pull-up (internal or external)
Use CMSIS definitions, not magic numbers and operations.
requires the entire CMSIS
And what is the problem? CMSIS does not add any overhead to your code, only handy definitions and inline functions, which do not change the size of the code if not used.
Also, HAL has very handy macros useful even if you do not use HAL library itself (it also will not increase the code size even by a single byte)
I will not check your magic offsets and numbers.
First error: after enabling the peripheral clock you need to wait. It is described in the Reference Manual. You do not wait and your first MODER operation has no effect. HAL macros read back the register to make sure that the operation has completed.
Example from STM32L4:
#define __HAL_RCC_GPIOB_CLK_ENABLE() do { \
__IO uint32_t tmpreg; \
SET_BIT(RCC->AHB2ENR, RCC_AHB2ENR_GPIOBEN); \
/* Delay after an RCC peripheral clock enabling */ \
tmpreg = READ_BIT(RCC->AHB2ENR, RCC_AHB2ENR_GPIOBEN); \
UNUSED(tmpreg); \
} while(0)
Then use the CMSIS registers typedefs and definitions.
#define PIN4 4
#define PIN5 5
GPIOB -> MODER &= ~((0b11 << (2 * PIN5)) | (0b11 << (2 * PIN4)));
GPIOB -> MODER |= ((0b01 << (2 * PIN5)) | (0b01 << (2 * PIN4)));
GPIOB -> OTYPER &= ~((1 << PIN4) | (1 << PIN5));
GPIOB -> OTYPER |= (1 << PIN4) | (1 << PIN5);
GPIOB -> BSRR = (1 << (PIN4 + 16)) | (1 << (PIN5 + 16)); // set the pins low
Related
I'm learning to use DMA on a STM32F446 and tried to send data over USART. The goal is to do some calculations and send the results to a PC via RS232.
Here is my MWE:
#include <stdint.h>
#include <stdio.h>
#include "stm32f446xx.h"
#define BAUDRATE ( 9600 )
#define USART2_TX_PIN (2)
#define USART2_RX_PIN (3)
int main(void) {
volatile uint32_t core_clock_hz = 16000000;
uint16_t uartdiv = core_clock_hz / BAUDRATE;
uint8_t TX_buffer[2];
TX_buffer[0] = 48; // this is a "0" in ASCII
TX_buffer[1] = 49; // this is a "1" in ASCII
// configure peripheral clocks
RCC->APB2ENR |= RCC_APB2ENR_SYSCFGEN; // Enable the SYSCFG peripheral
RCC->APB1ENR |= ( RCC_APB1ENR_USART2EN ); // Enable peripheral clocks: USART2
RCC->AHB1ENR |= ( RCC_AHB1ENR_GPIOAEN ); // Enable peripheral clocks: GPIOA
RCC->AHB1ENR |= ( RCC_AHB1ENR_DMA1EN ); // Enable peripheral clock: DMA1
// Configure pins A2 (TX), A3 (RX) for USART2. TX: alternate out push-pull, RX: in floating
// TX
GPIOA->MODER &= ~(0x3 << (USART2_TX_PIN*2)); // reset all bits
GPIOA->MODER |= (0x2 << (USART2_TX_PIN*2)); // 10 = alternate
GPIOA->OSPEEDR &= ~(0x3 << (USART2_TX_PIN*2)); // reset all bits
GPIOA->OSPEEDR |= (0x0 << (USART2_TX_PIN*2)); // 00 = low speed
GPIOA->OTYPER &= ~(0x1 << USART2_TX_PIN); // 0 = push-pull
GPIOA->PUPDR &= ~(0x3 << (USART2_TX_PIN*2)); // 00 = no pull-up / pull-down
// RX
GPIOA->MODER &= ~(0x3 << (USART2_RX_PIN*2)); // reset all bits
GPIOA->MODER |= (0x2 << (USART2_RX_PIN*2)); // 10 = alternate
GPIOA->PUPDR &= ~(0x3 << (USART2_RX_PIN*2)); // reset all bits
GPIOA->PUPDR |= (0x0 << (USART2_RX_PIN*2)); // 00 = no pull-up / pull-down , 01 = pull-up
// set alternate pin function AF7 for PA2 and PA3. AFR[0] = AFRL
GPIOA->AFR[0] &= ~(0xF << USART2_TX_PIN*4); // clear all bits
GPIOA->AFR[0] |= (0x7 << USART2_TX_PIN*4); // set AF7
GPIOA->AFR[0] &= ~(0xF << USART2_RX_PIN*4); // clear all bits
GPIOA->AFR[0] |= (0x7 << USART2_RX_PIN*4); // set AF7
USART2->BRR = ( ( ( uartdiv / 16 ) << USART_BRR_DIV_Mantissa_Pos ) | ( ( uartdiv % 16 ) << USART_BRR_DIV_Fraction_Pos ) ); // configure USART baudrate
USART2->CR1 |= ( USART_CR1_RE | USART_CR1_TE | USART_CR1_UE ); // Enable the USART peripheral
// Main loop
while ( 1 ) {
DMA1_Stream6->CR &= ~(DMA_SxCR_EN); // deactivate DMA stream for configuration
DMA1_Stream6->CR &= ~(DMA_SxCR_CHSEL); // clear bits
DMA1_Stream6->CR |= (DMA_SxCR_CHSEL_2); // 100 = channel 4
DMA1_Stream6->CR &= ~(DMA_SxCR_PL); // priority 00 = low
DMA1_Stream6->CR &= ~(DMA_SxCR_PSIZE); // size 00 = 8bit
DMA1_Stream6->CR |= (DMA_SxCR_MINC); // increment memory pointer with each DMA transfer
DMA1_Stream6->CR &= ~(DMA_SxCR_DIR); // clear bits
DMA1_Stream6->CR |= (DMA_SxCR_DIR_0); // 01 = memory-to-peripheral
DMA1_Stream6->PAR = ( uint32_t )&USART2->DR; // peripheral memory address
DMA1_Stream6->M0AR = ( uint32_t )&TX_buffer; // data memory address
DMA1_Stream6->NDTR = ( uint16_t ) 2; // number of bytes to transfer
DMA1->HISR &= ~(DMA_HISR_TCIF6 | DMA_HISR_HTIF6 | DMA_HISR_TEIF6 | DMA_HISR_DMEIF6 | DMA_HISR_FEIF6); // clear DMA flags
USART2->SR &= ~(USART_SR_TC); // clear USART transfer complete flag
DMA1_Stream6->CR |= (DMA_SxCR_EN); // set EN bit to activate DMA stream
// does not help: USART2->CR1 |= ( USART_CR1_RE | USART_CR1_TE | USART_CR1_UE ); // Enable the USART peripheral
USART2->CR3 |= (USART_CR3_DMAT); // enable USART DMA mode
// wait for end of transfer
while ( !(DMA1->HISR && DMA_HISR_TCIF6) ) {}
while ( !(USART2->SR && USART_SR_TC) ) {}
//
// do calculations here, modify TX_buffer for next transfer cycle
//
} // while (1)
} // main
The code should send the data in TX_buffer in an endless loop, thus I was expecting to receive a sequence of 01010101... in the PC's terminal. However, I only get a single 01 and then the transmission stops. As data is generally sent, GPIOs, clocks, ... seem to be configured correctly.
I guess, after one loop cycle of the while(1), the DMA or the USART are not reset to a state where they accept new transfers, but I couldn't figure out what exactly is missing. I already thought about missing ISR routines and IRQs. Many examples on the net use them, but I could not find any functionality in them which is not already in my main loop. Thus, my MWE does not use any interrupts or interrupt routines. All interrupts are deactivated in the DMA configuration register.
In circular mode of the DMA, the endless transmission is working, but this seems not to be the appropriate solution for my scenario of calculate -> send > calculate -> send -> ...
How do USART and DMA have to be configured in this case to allow multiple subsequent transmissions?
EDIT:
Added a compileable MWE.
Additional information which might be helpful:
There are also no interrupts configured for the USART.
My compiler options are:
CFLAGS += -mcpu=$(MCU_SPEC)
CFLAGS += -mthumb
CFLAGS += -Wall
# (Set error messages to appear on a single line.)
CFLAGS += -fmessage-length=0
CFLAGS += --specs=nosys.specs
CFLAGS += -ffunction-sections
CFLAGS += -fdata-sections
CFLAGS += -lm
# (Custom flags sent to the compiler)
CFLAGS += -D$(ST_MCU_DEF)
CFLAGS += -DVVC_$(MCU_CLASS)
#CFLAGS += -DVVC_$(MCU)
# FPU config
ifeq ($(MCU_CLASS), $(filter $(MCU_CLASS), L4 G4 WB F4))
CFLAGS += -mhard-float
CFLAGS += -mfloat-abi=hard
CFLAGS += -mfpu=fpv4-sp-d16
else
CFLAGS += -msoft-float
CFLAGS += -mfloat-abi=soft
endif
Let's look at the reference manual of the MCU together. You are not clearing the flags of DMA.
DMA1->HISR &= ~(DMA_HISR_TCIF6 | DMA_HISR_HTIF6 | DMA_HISR_TEIF6 | DMA_HISR_DMEIF6 | DMA_HISR_FEIF6); // clear DMA flags
USART2->SR &= ~(USART_SR_TC); // clear USART transfer complete flag
One of these lines works, the other one doesn't do anything, because
USART SR TC bit says it's rc_w0, while DMA's HISR is all "r" - read only bits. Writing to that register doesn't do anything. You need to use dedicated clear flag register of DMA.
So instead, this should work (the register is write-only):
DMA1->HIFCR = DMA_HIFCR_CTCIF6 | DMA_HIFCR_CHTIF6 | DMA_HIFCR_CTEIF6 | DMA_HIFCR_CDMEIF6 | DMA_HIFCR_CFEIF6; // clear DMA flags
Notice I'm not using |=, because |= will mean that we need to read the register first (like x |= y means x = x | y), and the register is not readable. So you prepare value for it and write it straight there without reading anything from it.
I'm trying to understand how to interface a TFT screen module with an STM32F4 chip on a custom PCB.
Here is the module and its basic info.
To write commands and data to the screen, the ILI9481 driver on the screen module uses the Display Bus Interface (DBI), where data is sent over 8 or 16 bits through data wires.
Looking at library examples, I understand (and please correct me, if I am wrong), that in order to send a command of one byte, it simply sets the digital pins of the chip high or low, depending on the command. For example, command 0x2 in 8bit communication would be 00000010, where 0 would be the digital low on the chips GPIO pin and 1 would be digital high, meaning 1 of 8 wires are active (logical high). I Hope, I understand this correctly.
Now as I looked over examples, usually these digital pins are on the same GPIO port. And if I understand correctly, GPIO ports have a register, called BSRR, where you can manipulate the logical levels of the pins of the GPIO port. If the data pins are all on the same GPIO port, I assume this would work (from the example, where c is the command byte):
void STM32_TFT_8bit::write8(uint8_t c) {
// BRR or BSRR avoid read, mask write cycle time
// BSRR is 32 bits wide. 1's in the most significant 16 bits signify pins to reset (clear)
// 1's in least significant 16 bits signify pins to set high. 0's mean 'do nothing'
TFT_DATA->regs->BSRR = ((~c)<<16) | (c); //Set pins to the 8 bit number
WR_STROBE;
}
However, on my PCB board, the data pins of the screen module are separated on different ports.
So, my question is, how would I do the same thing, send a command while manipulating the logical levels? I assume, that I could write set/reset my pins one by one, depending on the command, but how would it look with the BSRR registers?
If my data pins are as follows:
D0 -> PC12
D1 -> PC11
D2 -> PC10
D4 -> PA12
D5 -> PA11
D6 -> PA10
D7 -> PA9
Would a command of 0x9D (0b10011101) through the registers would look something like this? :
GPIOA->regs->BSRR = 0b0001101000000000; // A port: turn on PA9, PA11, PA12
GPIOC->regs->BSRR = 0b0001010000000000; // C port: turn on PC10 and PC12
how would it look with the BSRR registers?
A bitmask can be applied to the value that is written to the BSRR, for example like this:
/* set/reset selected GPIO output pins, ignore the rest */
static inline void _gpio_write(GPIO_TypeDef* GPIOx, uint16_t state, uint16_t mask)
{
GPIOx->BSRR = ((uint32_t)(~state & mask) << 16) | (state & mask);
}
The data bits need to be rearranged before writing them to the GPIO output registers, for example like this:
#define BITS(w,b) (((w) & (1 << (b))) >> (b))
/* write a data/command byte to the data bus DB[7:0] of custom ILI9481 board
used pin assignment: D0 -> PC12, D1 -> PC11, D2 -> PC10, (D3 -> PC1) (?)
D4 -> PA12, D5 -> PA11, D6 -> PA10, D7 -> PA9 */
static void _write_data_to_pins(uint8_t data)
{
const uint16_t mask_c = 1<<12 | 1<<11 | 1<<10 | 1<<1; /* 0x1c02 */
const uint16_t mask_a = 1<<12 | 1<<11 | 1<<10 | 1<<9; /* 0x1e00 */
_gpio_write(GPIOC, (uint16_t)(BITS(data, 0) << 12 | BITS(data, 1) << 11 |
BITS(data, 2) << 10 | BITS(data, 3) << 1), mask_c);
_gpio_write(GPIOA, (uint16_t)(BITS(data, 4) << 12 | BITS(data, 5) << 11 |
BITS(data, 6) << 10 | BITS(data, 7) << 9), mask_a);
}
Test:
/* just for testing: read the written data bits back and arrange them in a byte */
static uint8_t _read_data_from_pins(void)
{
const uint32_t reg_c = GPIOC->ODR;
const uint32_t reg_a = GPIOA->ODR;
return (uint8_t)(BITS(reg_c, 12) << 0 | BITS(reg_c, 11) << 1 |
BITS(reg_c, 10) << 2 | BITS(reg_c, 1) << 3 |
BITS(reg_a, 12) << 4 | BITS(reg_a, 11) << 5 |
BITS(reg_a, 10) << 6 | BITS(reg_a, 9) << 7);
}
/* somewhere in main loop of test project */
{
uint8_t d = 0xff;
do {
_write_data_to_pins(d);
if (d != _read_data_from_pins()) {
Error_Handler();
}
} while (d--);
}
(Note: Only 7 of the 8 data pins DB[7:0] were listed in the question, PC1 was assigned to data pin D3 here.)
(Note: Most of these bit-shifts can be easily optimized out by the compiler, use at least -O1 to get somewhat compact results with GCC.)
GPIOA->regs->BSRR = 0b0001101000000000; // A port: turn on PA9, PA11, PA12
GPIOC->regs->BSRR = 0b0001010000000000; // C port: turn on PC10 and PC12
These two code lines do what is stated in the comments. But they will leave all the other pins unchanged.
The resulting output will depend on the previous state of the output data register. - For the LOW data pins, the corresponding GPIO port bits in BSRR[31:16] need to be set to 1 in order to update all the 8-bit data bus lines at once.
To answer the actual question:
No, the output on the data bus will not be 0x9D (0b1001'1101) after writing the two quoted bit patterns to the two BSRR registers. - In my case, it would look like this (please correct me if I'm wrong):
/* write 0x9D (0b1001'1101) to the data bus
used pin assignment: D0 -> PC12, D1 -> PC11, D2 -> PC10, (D3 -> PC1) (?)
D4 -> PA12, D5 -> PA11, D6 -> PA10, D7 -> PA9 */
GPIOC->BSRR = 0x8001402; /* = 0b00001000'00000000'00010100'00000010 */
GPIOA->BSRR = 0xc001200; /* = 0b00001100'00000000'00010010'00000000 */
Suppose 'command' is the byte to send (I hope there is a strobe somewhere...).
I would simply make 8 lines of code like this (If I well understand the port registers of the STM32):
if (command & 1) GPIOC->BSRR |= 1 << 12; else GPIOC->BSRR &= ~(1 << 12);
if (command & 2) GPIOC->BSRR |= 1 << 11; else GPIOC->BSRR &= ~(1 << 11);
...
if (command & 128) GPIOA->BSRR |= 1 << 9; else GPIOA->BSRR &= ~(1 << 9);
Maybe this is quite raw, but it works and it is easy to understand (i.e. more difficult to make typos). Next time tell the hardware designer to arrange wires just a little better... it is hard to think at something worse than this, the bits seem reversed just to see if the software guy can cope with them!
I'm using the stm32f767zi, and I'm trying to send test data over the USART peripheral. I've done the same configuration as I always do on any device, but this time it does not output anything... I cannot find the mistake, can someone help ?
The clock setup
// Enables TIM8 (Delay), USART1 (STDOUT)
RCC->APB2ENR |= (RCC_APB2ENR_TIM8EN
| RCC_APB2ENR_USART1EN);
// Enables GPIOA, GPIOB, GPIOC, GPIOD, GPIOE, GPIOF, DMA1
RCC->AHB1ENR |= (RCC_AHB1ENR_GPIOAEN
| RCC_AHB1ENR_GPIOBEN
| RCC_AHB1ENR_GPIOCEN
| RCC_AHB1ENR_GPIODEN
| RCC_AHB1ENR_GPIOEEN
| RCC_AHB1ENR_GPIOFEN
| RCC_AHB1ENR_DMA1EN);
The initialization code
// Makes A8 (TX) and A9 (RX) Alternative Function
GPIOA->MODER &= ~(GPIO_MODER_MODER8_Msk
| GPIO_MODER_MODER9_Msk);
GPIOA->MODER |= ((0x2 << GPIO_MODER_MODER8_Pos)
| (0x2 << GPIO_MODER_MODER9_Pos));
// Selects AF7 for both A8 (TX) and A9 (RX).
GPIOA->AFR[1] &= ~(GPIO_AFRH_AFRH0_Msk
| GPIO_AFRH_AFRH1_Msk);
GPIOA->AFR[1] |= ((7 << GPIO_AFRH_AFRH0_Pos)
| (7 << GPIO_AFRH_AFRH1_Pos));
// Selects very high speed for A8 (TX) and A9 (RX)
GPIOA->OSPEEDR &= ~(GPIO_OSPEEDR_OSPEEDR8_Msk
| GPIO_OSPEEDR_OSPEEDR9_Msk);
GPIOA->OSPEEDR |= ((0x3 << GPIO_OSPEEDR_OSPEEDR8_Pos)
| (0x3 << GPIO_OSPEEDR_OSPEEDR9_Pos));
// Calculates and sets the baud rate.
m_USART->BRR = (((2 * clk) + baud) / (2 * baud));
// Configures the USART peripheral further.
m_USART->CR1 = USART_CR1_TE // Transmit Enable
| USART_CR1_RE // Receive Enable
| USART_CR1_UE; // USART Enable (EN)
and the write function:
*reinterpret_cast<uint8_t *>(m_USART->TDR) = c;
while (!(m_USART->ISR & USART_ISR_TC));
The problem you have is that you set the wrong pins. It should be PA9 & PA10
your write is also wrong
it should be :
*reinterpret_cast<volatile uint8_t *>(&m_USART->TDR) = c;
or C style:
*(volatile uint8_t *)(&m_USART->TDR) = c;
you are also checking the wrong flag.
TC is important if you want to disable the peripheral after the transition. In normal conditions use TXE flag instead.
while (!(m_USART->ISR & USART_ISR_TXE));
Your reinterpret_cast is unnecessary and incorrect.
I assume you actually wrote *reinterpret_cast<uint8_t *>(&m_USART->TDR) = c; but that is still wrong.
The person who wrote the standard device header has taken great care to make sure that USARTx->TDR already has the correct type, I strongly advise you to trust them and not cast it! In this particular case they will have made it volatile, and you have not, so it is possible that the compiler thinks it can make an optimization by not bothering to perform a write to something that you never read back.
The reason you probably got away with this on other STM32 parts is that their UARTs have just DR for both transmit and receive so reading DR for reception made the compiler think it couldn't eliminate the write.
Also, I don't know about this part, but many STM32 need an extra cycle between writing to RCC->xxxENR and using the respective peripheral, this is usually done with a read of the same register, eg:
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN;
(void)RCC->AHB1ENR;
// now safe to access GPIOA registers
I try to make master and slave stm32f103 (bluepills) communicate. But I am having trouble with receiving. When I connect my master to logic analyser I can see MOSI as in the picture
Logic Analyser
In the picture, MOSI is sending "Y" letter. But not all clock pulses same.(I don't know if this is the reason of communication fail)
here is my schematics and my code I simplified as much as I can.
Master Code:
int i;
RCC ->APB2ENR |= 0x00001004; //SPI1,GPIOA clock en
GPIOA ->CRL &= 0x00000000;
GPIOA ->CRL |= 0xb0b33333;
SPI1->CR1 = SPI_CR1_SSM| SPI_CR1_SSI| SPI_CR1_MSTR|SPI_CR1_BR_2;
SPI1->CR1 |= SPI_CR1_SPE; // enable SPI
while(1){
SPI1 -> DR = 'A';
for(int i = 0 ;i<400000;i++);
while( !(SPI1->SR & SPI_SR_TXE) ); // wait until transmit buffer empty
}
and Slave
int i;
RCC ->APB2ENR |= 0x0000100c; //SPI1,GPIOA,GPIOB clock en
GPIOB ->CRH &= 0x00000000;
GPIOB ->CRH |= 0x33333333;
GPIOA ->CRL &= 0x00000000;
GPIOA ->CRL |= 0x4b443333;
GPIOA ->CRH &= 0x00000000;
GPIOA ->CRH |= 0x33333333;
SPI1->CR1 = SPI_CR1_SSM| SPI_CR1_SSI| SPI_CR1_BR_2;
SPI1->CR1 |= SPI_CR1_SPE; // enable SPI
SPI1->CR1 &=~SPI_CR1_MSTR; //disable master
for(int c=0;c<5;c++){
LCD_INIT(cmd[c]);
}
while(1){
while( !(SPI1->SR & SPI_SR_RXNE));
char a = SPI1 ->DR;
for (i=0;i<400000;i++);
LCD_DATA(a);
for (i=0;i<400000;i++);
}
}
My Schematic:
Schematic
The problem is slave is not receiving any data.
It stucks in the loop while( !(SPI1->SR & SPI_SR_RXNE));
First, what are your HCLK and APB2 bus frequencies? If I'm not mistaken, you seem to use (fPLCK / 32) for SPI clock and your logic analyzer shows ~2 or 3 MHz clock. If your APB2 frequency is higher than the 72 MHz limit, you may experience clock problems.
In the slave, you use SSM (software slave management) and activate SSI (internal slave select). The name of the SSI bit is misleading: It mimics the physical NSS pin. So when SSI = 1, the slave is not selected. This is probably the reason why the slave ignores the incoming bytes.
I want to implement dual regular simultaneous mode of ADC1,ADC2 and two DMA ADC channels of stm32f303 discovery.
In CubeMX examples:
Usage of two DMA channels (one for ADC master, one for ADC slave) is
also possible: this is the recommended configuration in case of high
ADC conversions rates and applications using other DMA channels
intensively.
According to AN4195
When using the DMA, there are two possible cases: • Use of two
separate DMA channels for master and slave. Each ADC (in this case,
the MDMA[1:0]) must be kept cleared. The first DMA channel is used to
read the master ADC converted data from ADC_DR, and the DMA requests
are generated at each EOC event of the master ADC. The second DMA
channel is used to read the slave ADC converted data from ADC_DR, and
the DMA requests are generated at each EOC event of the slave ADC.
For 1 channel the code:
HAL_ADCEx_Calibration_Start(&hadc1, ADC_SINGLE_ENDED);
HAL_ADCEx_Calibration_Start(&hadc2, ADC_SINGLE_ENDED);
HAL_ADC_Start(&hadc2);
HAL_ADCEx_MultiModeStart_DMA(&hadc1, (uint32_t*)buffer, 3);
But how can we run 2 channels? HAL_ADCEx_MultiModeStart_DMA is for 1 channel as I can understand
Something like for independent mode is not working
HAL_ADCEx_Calibration_Start(&hadc1, ADC_SINGLE_ENDED);
HAL_ADCEx_Calibration_Start(&hadc2, ADC_SINGLE_ENDED);
HAL_ADC_Start(&hadc2);
HAL_ADC_Start_DMA(&hadc1,(uint32_t*)ADC1_data,sizeof(ADC1_data)/sizeof(ADC1_data[0]));
HAL_ADC_Start_DMA(&hadc2,(uint32_t*)ADC2_data,sizeof(ADC2_data)/sizeof(ADC2_data[0]));
I'm not 100% sure, if this also applies to the F3 series, but I've written this toturial for the F103C8 regarding ADC dual regular simultanous mode:
http://www.bepat.de/2020/11/27/stm32f103c8-adc-dual-regular-simultaneous-mode/
maybe you'll find it helpfull.
To cut a long story short: I guess you are starting the ADCs the wrong way.
ADC2 needs to be started in normal mode BEFORE ADC1 starts with
HAL_ADC_Start(&hadc2);
ADC1 is started afterwards with:
HAL_ADCEx_MultiModeStart_DMA(&hadc1, ADC_Buffer, ADC_BufferSize);
Funny - great HAL library :). This is my working code: interleaved mode - one DMA transfer half word per two conversions (master and slave). 8-bit resolution. Register version.
DMA1_Channel1 -> CPAR = (uint32_t)&(ADC12_COMMON -> CDR);
DMA1_Channel1 -> CMAR = (uint32_t)&obuff[0][0];
DMA1_Channel1 -> CNDTR = 1 * 1024;
DMA1_Channel1 -> CCR = DMA_CCR_MINC | DMA_CCR_TCIE | DMA_CCR_EN | DMA_CCR_MSIZE_0 | DMA_CCR_PSIZE_0 | DMA_CCR_TEIE | (DMA_CCR_PL_Msk);
ADC12_COMMON -> CCR = (0b11 << ADC12_CCR_MDMA_Pos) | (0b111 << ADC12_CCR_MULTI_Pos);
ADC1 -> CFGR = ADC_CFGR_DMAEN | (0b10 << ADC_CFGR_RES_Pos);
ADC1 -> CFGR &= ~(ADC_CFGR_EXTEN_Msk | ADC_CFGR_EXTSEL_Msk); // software trigger only, converting as fast as possible
ADC1 -> CFGR |= ADC_CFGR_CONT;
ADC1 -> SMPR1 = 0;
ADC1 -> SMPR2 = 0;
ADC1 -> SQR1 &= ~(ADC_SQR1_L_Msk);
ADC1 -> SQR1 &= ~(ADC_SQR1_SQ1_Msk);
ADC1 -> SQR1 |= (1 << ADC_SQR1_SQ1_Pos);
ADC2 -> CFGR = ADC_CFGR_DMAEN | (0b10 << ADC_CFGR_RES_Pos);
ADC2 -> SMPR1 = 0;
ADC2 -> SMPR2 = 0;
ADC2 -> SQR1 &= ~(ADC_SQR1_L_Msk);
ADC2 -> SQR1 &= ~(ADC_SQR1_SQ1_Msk);
ADC2 -> SQR1 |= (1 << ADC_SQR1_SQ1_Pos);
ADC1 -> CR |= ADC_CR_ADSTART;
DMA1_Channel1 interrupt is called when DMA finishes transfers.