Good day
The problem:
I am trying to blink the three LED's on the board, but the LED's are not blinking
What I have done:
Using CubeMX I have configured the board using the default pinout.
PB0 = LD1, PB7 = LD2, PB14 = LD3
I have added these lines to main.c to blink the LED. Please note I have commented out the Ethernet Init due to the expected hard fault as I have not configured ethernet and memory.
MX_GPIO_Init();
//MX_ETH_Init();
MX_SPI1_Init();
MX_USART3_UART_Init();
MX_USB_OTG_FS_PCD_Init();
/* USER CODE BEGIN 2 */
/* USER CODE END 2 */
/* Infinite loop */
/* USER CODE BEGIN WHILE */
while (1)
{
HAL_GPIO_TogglePin(GPIOB, 0);
HAL_GPIO_TogglePin(GPIOB, 7);
HAL_GPIO_TogglePin(GPIOB, 14);
HAL_Delay(1000);
}
Observations:
With the above lines of code only LD3 will blink. IF I try blink only LD3 and comment out the other two blink commands, then LD3 no longer blinks
If I set the startup conditions of the three LEDs to high (in either the gpio.c or in CubeMX) then all three LEDs turn on, but they will not blink thereafter.
Does anyone know what is going on here?
With much embarrassment, this is the problem. The API HAL_GPIO_TogglePin() requires very specific arguments.
The following examples do not work:
HAL_GPIO_TogglePin(A,12);
HAL_GPIO_TogglePin(GPIOA,12);
HAL_GPIO_TogglePin(A,GPIO_Pin_12);
Please make sure you use the proper handles and arguments:
HAL_GPIO_TogglePin(GPIOA,GPIO_Pin_12);
Related
The TIM SR register value always be 0x1F, And Can not use to clear the reg.
HAL Lib Always runs into time interrupt really fast, and Can not clear SR register.
How to fix the promble？
Cubemx set
NVIC
`
void TIM3_IRQHandler(void)
{
/* USER CODE BEGIN TIM3_IRQn 0 */
/* USER CODE END TIM3_IRQn 0 */
HAL_TIM_IRQHandler(&htim3);
/* USER CODE BEGIN TIM3_IRQn 1 */
/* USER CODE END TIM3_IRQn 1 */
}
`
`
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
if ( htim == &htim3){
__HAL_TIM_CLEAR_FLAG(&htim3,TIM_FLAG_UPDATE) ;
HAL_GPIO_TogglePin(GPIOC,GPIO_PIN_13) ;
}
}
`
I will base my explanation on STM32F746's TIM3. Timers across STM32 that share number are usually identical or very similar.
TIM3->SR has 0x1F? That's 5 flags set! TIM3 is a general purpose STM32 timer. These 5 flags mean you have counter interrupt and four capture/compare interrupt status flags set at the same time. Something weird is going on. Are you sure you're supposed to have those flags set? Well, if their interrupts are not enabled, it doesn't matter.
You can clear these flags in TIM3->SR by writing zero to the specific position you want to clear and 1 everywhere else. As per reference manual, this register ignores if you write 1. It doesn't set bits when you do that. It only resets when you write zero. So,
TIM3->SR = 0; //clear all interrupt flags
TIM3->SR = ~TIM_SR_UIF; //clear update interrupt flag only
This works because the bits in the reference manual are marked rc_w0 - read, clear by writing zero. If bits in your SR register work differently, you may have to clear them differently. For example, sometimes status register is read-only and you clear it via write to flag clear register. Check reference manual of your MCU.
I have a problem with STM32H747 Discovery board and OV5640 camera shield.
I configured DCMI interface and it works fine. I can see values in hdcmi->Instance->DR register changing and vsync and hsync interrupts work.
I want to transfer single line of pixels from DCMI to buffer in RAM. So I start DMA in circular mode with data length equal to line buffer size in words (32bit). Then I start DCMI in circular mode. Since then DMA should transfer each received line to buffer and then call transfer completed callback.
But there is a problem with DMA that transfers data. First line is transferred correctly, but then data in the buffer stays always the same. DMA transfer completed callback is called every line (checked with counting hsync and DMA TC interrupts).
This is how DMA is initialized in Cube:
cube dcmi dma init
Line buffer initialization:
uint8_t cameraLineBuffer[CAMERA_LINE_SIZE] __attribute__ ((aligned (32)));
Function starting DCMI with DMA:
HAL_StatusTypeDef DCMI_Start_DMA_line(DCMI_HandleTypeDef *hdcmi, uint32_t DCMI_Mode)
{
/* Process Locked */
__HAL_LOCK(hdcmi);
/* Lock the DCMI peripheral state */
hdcmi->State = HAL_DCMI_STATE_BUSY;
/* Enable DCMI by setting DCMIEN bit */
__HAL_DCMI_ENABLE(hdcmi);
/* Configure the DCMI Mode */
hdcmi->Instance->CR &= ~(DCMI_CR_CM);
hdcmi->Instance->CR |= (uint32_t)(DCMI_Mode);
/* Set DMA callbacks */
hdcmi->DMA_Handle->XferCpltCallback = DCMI_DMA_LineTransferCompletedCallback;
hdcmi->DMA_Handle->XferErrorCallback = DCMI_DMA_Error;
/* Enable the DMA Stream */
uint32_t pLineData = (uint32_t) cameraLineBuffer;
HAL_DMA_Start_IT(hdcmi->DMA_Handle, (uint32_t)&hdcmi->Instance->DR, pLineData, CAMERA_LINE_SIZE/4);
/* Enable Capture */
hdcmi->Instance->CR |= DCMI_CR_CAPTURE;
/* Release Lock */
__HAL_UNLOCK(hdcmi);
/* Return function status */
return HAL_OK;
}
What can cause such strange behavior? I looked at examples in FP-AI-VISION1 and AN5020 manual but I couldn't find anything that I missed.
Ok, so I finally figured out the problem. DMA just writes data to RAM memory. CPU tries to access it, but it was using cached memory. After first CPU access to buffer DMA stopped working, probably because data was transferred to cache and so was visible by CPU and in the debugger.
Final solution was to just disable D-Cache at all. This website explains the problem well.
This seems to be a problem that is somewhat common, but I have been unsuccessful with any of the solutions I have found online. Specifically I am trying to transmit a 1024 byte buffer (full 128x64 px image) to a SSD1306 display via I2C/DMA and the HAL generated in cubeIDE. I am using a STML432 nucleo board. I have no problem transmitting the buffer without DMA using HAL_I2C_Mem_Write
Based on other questions I have seen, the problem lies in the fact that the DMA finishes while the I2C bus is still working on the transmit. I just don't know how to remedy this and the examples given usually don't use the HAL (unfortunately, despite my efforts I am not quite competent to correctly apply them to the HAL myself I guess). I have tried using the interrupts for I2c and DMA with no luck, only about the first 254 bytes get transferred (just shy of two rows showing on the screen).
Here is my code for sending the buffer:
static void ssd1306_WriteMData_DMA(const uint8_t *data, uint16_t size)
{
while(HAL_I2C_GetState(&hi2c1) != HAL_I2C_STATE_READY);
HAL_I2C_Mem_Write_DMA(&hi2c1, I2C_ADDR, SSD1306_REG_MDAT, 1, (uint8_t*)data, size);
}
and the code for each interrupt handler:
void I2C1_EV_IRQHandler(void)
{
/* USER CODE BEGIN I2C1_EV_IRQn 0 */
if(I2C1->ISR & I2C_ISR_TCR){
I2C1->CR2 |= (I2C_CR2_STOP);// stop i2c
I2C1->ICR |= (I2C_ICR_STOPCF);// Reset the ICR flag.
// stop DMA
DMA1->IFCR |= DMA_IFCR_CTCIF6;
// clear flag
DMA1_Channel6->CCR &= ~DMA_CCR_EN;
}
/* USER CODE END I2C1_EV_IRQn 0 */
//HAL_I2C_EV_IRQHandler(&hi2c1);
/* USER CODE BEGIN I2C1_EV_IRQn 1 */
/* USER CODE END I2C1_EV_IRQn 1 */
}
void DMA1_Channel6_IRQHandler(void)
{
/* USER CODE BEGIN DMA1_Channel6_IRQn 0 */
// stop DMA
DMA1->IFCR |= DMA_IFCR_CTCIF6;
// clear flag
DMA1_Channel6->CCR &= ~DMA_CCR_EN;
/* USER CODE END DMA1_Channel6_IRQn 0 */
HAL_DMA_IRQHandler(&hdma_i2c1_tx);
/* USER CODE BEGIN DMA1_Channel6_IRQn 1 */
/* USER CODE END DMA1_Channel6_IRQn 1 */
}
I think that is all the pertinent code, let me know if there is something else I am missing. All of the initialization code for the peripherals was done through cubeMX, but I can post that if need be, or the settings. I feel like it is something really simple that I'm missing, but this is a bit over my head to be honest so I don't quite grasp exactly what's going on...
Thanks for any help!
Problem is in your custom DMA1_Channel6_IRQHandler and I2C1_EV_IRQHandler. Those functions will be called right after I2C transfers 255 bytes, which is MAX_NBYTE_SIZE for NBYTES. HAL already have all required interrupt routines inside stm32l4xx_hal_i2c.c:
Sets I2C transfer IRQ handler to I2C_Master_ISR_DMA;
Checks if data size is larger than 255 bytes and uses reload mode.
Sets I2C DMA complete callback to I2C_DMAMasterTransmitCplt;
Starts DMA using HAL_DMA_Start_IT()
Configures I2C registers using I2C_TransferConfig()
HAL driver will handle all I2C+DMA interrupts using I2C_Master_ISR_DMA and I2C_DMAMasterTransmitCplt:
I2C_DMAMasterTransmitCplt will restart DMA for each chunk of 255 (MAX_NBYTE_SIZE) or less bytes.
I2C_Master_ISR_DMA will reset RELOAD/NBYTES registers using I2C_TransferConfig.
For last block of data I2C_AUTOEND_MODE is used.
So all you need is
remove "user code" from DMA1_Channel6_IRQHandler and I2C1_EV_IRQHandler functions
enable I2C1 event interrupt in STM32 Device Configuration Tool
configure DMA with data width byte/byte
perform a single call of HAL_I2C_Mem_Write_DMA(...) to start transfer
check HAL_I2C_STATE_READY before next transfer
See HAL_I2C_Mem_Write_DMA, I2C_Master_ISR_DMA and I2C_DMAMasterTransmitCplt source code in stm32l4xx_hal_i2c.c to understand how it works.
About why DMA finishes while I2C is still working: HAL driver sends I2C data over DMA using 255 byte chunks, stops DMA, starts DMA, clears I2C_CR2 NBYTES/RELOAD, enables DMA. DMA may be run continuously using DMA_CIRCULAR mode, but currently it is not implemented in HAL I2C drivers. Here is example of using I2C with DMA_CIRCULAR mode:
// DMA enabled single time
hi2c1.hdmatx->XferCpltCallback = MY_I2C_DMAMasterTransmitCplt;
HAL_DMA_Start_IT(hi2c1.hdmatx, (uint32_t)&i2cBuffer, (uint32_t)&hi2c1.Instance->TXDR, I2C_BUFFER_SIZE);
MY_I2C_TransferConfig(&hi2c1, (uint16_t)DAC_ADDR, 254, I2C_RELOAD_MODE, I2C_GENERATE_START_WRITE); // in first call using I2C_GENERATE_START_WRITE
uint32_t tmpisr = I2C_IT_TCI;
__HAL_I2C_ENABLE_IT(&hi2c1, tmpisr);
hi2c1.Instance->CR1 |= I2C_CR1_TXDMAEN;
Still need to clear I2C_CR2 NBYTES/RELOAD using MY_I2C_TransferConfig each 254 bytes (I do not use 255 to align interrupt firing to even index in array):
static HAL_StatusTypeDef MY_I2C_Master_ISR_DMA(struct __I2C_HandleTypeDef *hi2c, uint32_t ITFlags, uint32_t ITSources)
{
if (__HAL_I2C_GET_FLAG(&hi2c1, I2C_FLAG_TCR) == SET)
{
MY_I2C_TransferConfig(&hi2c1, (uint16_t)DAC_ADDR, 254, I2C_RELOAD_MODE, I2C_NO_STARTSTOP); // in repeated calls using I2C_NO_STARTSTOP
}
return HAL_OK;
}
With this approach DMA circular buffer size is not limited to 255 bytes:
#define I2C_BUFFER_SIZE 1024
uint8_t i2cBuffer[I2C_BUFFER_SIZE];
Main.c should have MY_I2C_TransferConfig() function, which is copy pasted version of private function HAL_I2C_TransferConfig() from stm32l4xx_hal_i2c.c. On earlier STM32 microcontrollers there is no NBYTES/RELOAD fields and I2C_CR2 does not need to be updated this way.
Using DMA in circular mode allows to achieve highest frame rate, you just need to fill DMA buffers in time using XferHalfCpltCallback and XferCpltCallback callbacks. Frames may be copied from larger buffer by using memcpy() or DMA MEMTOMEM transfer.
You haven't said which STM32 you are using. They have different bit definitions (because the I2C peripherals in the earlier released parts were rubbish) but it looks like you are using one of the later ones.
Basically you can find what you need in the bit definitions for the I2C registers in the reference manual. If you are setting stop before it has finished you need to look for a BUSY bit that gets cleared or BTF (byte transfer finished) bit that gets set when it is time for you to send stop.
I am trying to receive 8 bytes from my pc on my NUCLEO F446RE stm32 board.
Transmitting to the pc works.
The problem is, I am unable to receive data using DMA.
I saw an example with almost the same code and it has worked for the person.
If I use the interrupt mode (just change HAL_UART_Receive_DMA to HAL_UART_Receive_IT, it does work and the RX Complete callback is being called.
Here is the complete main.c. DMA is in circular mode.
main.c
https://pastebin.com/1W4BCjxB
I got it solved, it is actually ridiculous.
So, this is part of the code that CubeMX generates:
MX_GPIO_Init();
MX_USART2_UART_Init();
MX_DMA_Init();
If I order it as follows:
MX_GPIO_Init();
MX_DMA_Init();
MX_USART2_UART_Init();
It works!!!
I had the same problem. Here is the solution with using the CubeMX integrated view.
In the CubeMX->Project Manager->Advanced Settings you can select the order of functions to be generated. I moved my MX_DMA_Init to the top to ensure that the DMA is ready before any other peripherals are initialised.
You haven't initialized the DMA variables as well as handler for the DMA interrupt. You will need to do something along these lines
Initialize DMA:
hdma_usart2_rx.Instance = DMA2_Stream1;
hdma_usart2_rx.Init.Channel = DMA_CHANNEL_2;
hdma_usart2_rx.Init.Direction = DMA_PERIPH_TO_MEMORY;
hdma_usart2_rx.Init.PeriphInc = DMA_PINC_DISABLE;
hdma_usart2_rx.Init.MemInc = DMA_MINC_DISABLE;
hdma_usart2_rx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE;
hdma_usart2_rx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE;
hdma_usart2_rx.Init.Mode = DMA_CIRCULAR;
hdma_usart2_rx.Init.Priority = DMA_PRIORITY_HIGH;
hdma_usart2_rx.Init.FIFOMode = DMA_FIFOMODE_DISABLE;
HAL_DMA_Init(&hdma_usart2_rx);
void DMA2_Stream2_IRQHandler(void)
{
HAL_NVIC_ClearPendingIRQ(DMA2_Stream2_IRQn);
HAL_DMA_IRQHandler(&hdma_usart1_rx);
}
HAL_UART_Receive_DMA only starts the DMA and does not handle the interrupt and the data transfer.
2 STM32 μc (NucleoF767ZI and Nucleo F446RE) should communicate via SPI. The first µc is programmed with Simulink using the Nucleo Support Package. As it stands, the μc with the Support Package can only work as a master. Now I just want to send a number from 0-255 to the slave μc for testing. And see the message with debugging mode. According to the Simulink block parameter, the Slave address register must be entered.
Then i am going to measure the the Duty Cycle of a PWM signal and send to via spi to the Master µc in Simulink, so the µc will function as a Sensor.
/* USER CODE BEGIN 0 */
uint8_t Rx[2];
/* USER CODE END 0
/* USER CODE BEGIN 2 */
__HAL_SPI_ENABLE(&hspi1);
/* USER CODE END 2 */
while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
HAL_SPI_Receive(&hspi1,Rx,1,10);
HAL_Delay(50);
}
/* USER CODE END 3 */
}
So my question, is it possible that my SPI of the slave µc (e.g., SPI2) has an address?
sIMULINK-SPI