Solved

What DMA settings should I use for DCMI for STM32 if I'm using OV7670 camera without FIFO?

I've just bought a STM32G030F6P6 dev board and I'm testing its cababilities.And one thing I'm having problems with is saving my data to the FLASH.The first time it writes as espected in the FLASH, but not in the second, HAL_FLASH_Program returns HAL_ERROR.#include "main.h"   uint32_t Address = 0x0800F800; uint32_t buffer = 0x12345678; uint32_t data1 = 0; uint32_t data2 = 0; HAL_StatusTypeDef status;   int main(void) { HAL_Init();   SystemClock_Config();   data1 = *(__IO uint32_t *)Address; status = HAL_FLASH_Unlock(); status = HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, Address, buffer); status = HAL_FLASH_Lock(); data2 = *(__IO uint32_t *)Address;   while (1) { } }   void SystemClock_Config(void)...

..

In examples I got familiar with RF low level access is controlled by some exact coprocessor firmware. Existing coprocessor binaries provide some higher level of abstraction that seems to not include forcing signal with exact characteristics. Do I missing something or is there any other approach to start continuous signal generation with specified power and frequency?

..

Hi, I dont know how this happened, but my Eval board STM32H757 can not go after :SystemClock_Config() ==> HAL_PWREx_ConfigSupply() ==> while (__HAL_PWR_GET_FLAG (PWR_FLAG_ACTVOSRDY) == 0U)The progam stay in the while loop : while (__HAL_PWR_GET_FLAG (PWR_FLAG_ACTVOSRDY) == 0U)from what I see, the  MODIFY_REG (PWR->CR3, PWR_SUPPLY_CONFIG_MASK, SupplySource);doesn't modify SMPSEN or LDOEN. They are bot to state "1". In the datasheet ( with STANDBY =0 and SMPSLEVEL =0 ), it is an illegal setup:"Illegal combination, the default configuration is kept. (writedata will be ignored)."the Programm is directly outputed from cubemx ( default perepheral setup )So I am stuck here, and I dont know how to move forward.Does anybody know the path to recover this?Thank you

I want to send 16-bit, 16-channel data measured by ADC. but I realize BLE is transfering 8bit data. How can I solve this?my key script is below.<main.c>uint16_t DMAo[16];​ HAL_ADCEx_Calibration_Start(&hadc1, ADC_SINGLE_ENDED); HAL_ADC_Start_DMA(&hadc1, (uint32_t*)DMAo, 16);<custom_app.c>uint8_t UpdateCharData[247];uint8_t NotifyCharData[247];uint32_t DMA32[16];extern uint16_t DMAo[16]; extern ADC_HandleTypeDef hadc1;void myTask(void) { if(HAL_GPIO_ReadPin(LD2_GPIO_Port, LD2_Pin)) { HAL_ADC_Start(&hadc1); for(int i=0;i<16;i++) { DMAf[i] = DMAo[i]; DMA32[i] = DMAo[i]; UpdateCharData[i] = DMA32[i]; }   Custom_Readwrite_Update_Char(); } else { HAL_ADC_Stop(&hadc1); } UTIL_SEQ_SetTask(1 << CFG_TASK_MY_TASK, CFG_SCH_PRIO_0); }void Custom_Readwrite_Update_Char(void){ Custom_STM_App_Update_Char(CUSTOM_STM_READWRITE, (uint8_t *)UpdateCharData); return;}<custom_stm.c>tBleStatus Custom_STM_App_Upd

Hi, I want to use B-U585I-IOT02A as a controller for mobile robot, I use a smartphone for the remote control. For now I am using HC-05 as the bluetooth interface because I can't find out how to program the STM32WB5MMG to act similar with HC-05. Can anyone give me any guide or reference how to do it? I just need it to work as the bluetooth interface to receive serial data and send it to the STM32U585.And I use MITAppInventor 2 to create the smartphone software if anyone wondering.

Sorry for my silly questions ,but i am having a hard time understanding the exclamation marks in cubeMX .if somebody could please guide me here .it will be much appreciated.Example:the RCC is shown as partically disabled.i have use LSE (crystal/ ceramic Resonator ) as a mode However i should be able to use it.and i get this warning (statut: partly disabled conflict USART2 asynchrone).Exemple2:i want to use USART2 and configure PA as GPIO-EXTI (INTN DIR for my sensor TDC_GP30 pin name (pin 22)) is that possible or not ??

Hello, Can you please point me to the factory settings of stm32wb55 pucleo board.I seem to have erased some sectors 1-192 and fiddled with some option bytes (nBOOT0) and nSWBOOT0Best Regards,D

I'm struggling to get the SPI CRCERR flag and IRQ to work the way I expect.I am using an STM32WB55. The SPI communication in full duplex is working. The master is adding the CRC to the end of the Tx data. On the slave side, the CRC is read in. I can see the RXCRC updating, and I can see it go to 0x00 when the final CRC byte is read, which tells me that the CRC calculation is working. However, I cannot get the CRCERR flag to turn on when I purposefully have a CRC mismatch (using different polynomials on master and slave to trigger a mismatch).I suspect the issue is related to the DMA transfer sizes. I have read the advice about what length of transfer to use (Tx side = data length without CRC; Rx side = data length with CRC), and I have tried various combinations. I suspect that slave SPI does not know the transfer is done, so it does not do the final comparison and set the error bit.So, some actual questions:Should I expect the CRCERR flag to work with SPI + DMA on processors like the

Hi,I created a project for the Tiny Shark using TouchGFX 1.17 and found it generated code for the NOR Ram OCTOSPI interface that was incorrect such that a Hard Fault was generated.I built another project using Ver. 1.18 and had the same problem.Luckily i put a tag next to the modded line so I found it in the earlier project and put it into the new one.The relevant code is:/** * @brief OCTOSPI1 Initialization Function * @param None * @retval None */ static void MX_OCTOSPI1_Init(void) { uint32_t statusResult;   /* OCTOSPI1 parameter configuration*/ hospi1.Instance = OCTOSPI1; hospi1.Init.FifoThreshold = 1; hospi1.Init.DualQuad = HAL_OSPI_DUALQUAD_DISABLE; hospi1.Init.MemoryType = HAL_OSPI_MEMTYPE_MICRON; hospi1.Init.DeviceSize = 26; hospi1.Init.ChipSelectHighTime = 2; hospi1.Init.FreeRunningClock = HAL_OSPI_FREERUNCLK_DISABLE; hospi1.Init.ClockMode = HAL_OSPI_CLOCK_MODE_0; hospi1.Init.WrapSize = HAL_OSPI_WRAP_NOT_SUPPORTED; hospi1.Init.ClockPrescaler = 3; hospi1.Init

But What It's mean exactely ? I must buy a Debugger like ST-LINK/V2 ? Thank you for your helps. Regards

I'm working with the STM32L4 Nucleo-64 Development Board and compiling with STM32CubeIDE 1.6.1. I have created a project using STM32CubeMX that I then imported into STM32CubeIDE. Hence, my linker script file was generated by STM32CubeIDE. Whenever I compile, my resulting (hex or binary) firmware file contains 96 bytes starting at address 0x20000000. Where do those bytes come from and what's the purpose of them?

..

Like I said, I can not find the spice model for the STD134NF7AG MOSFET.

STM32WB55RGV6 connects ADS1299 by spi. And I choose spi2. There are three signas miso\ mosi and sck. SPI2 has two alternative: GPIO_AF3_SP2 and GPIO_AF5_SPI2.① STM32CUBEMX automatically generated miso(GPIO_AF3_SP2), mosi and sck(GPIO_AF5_SPI2).Initialization is ok, but no data.② All ​GPIO_AF3_SP2. Initialization is failed and application crash.③​ All ​GPIO_AF5_SP2. Successfully.Although the result is good, I do not understand why:sad_but_relieved_face:

Hello,Can you help me to use the DMAMUX in the STM32G474 microcontroller?How can I program the uC to make TIM2_CH1 sends a DMA request when CC. I have found this in the reference manual but I can't undesrtand which channel of the DMA is involved. Thanks for the clarification

The STM32CubeMX generate:```#define LCD_SPI_Send_DMA(rd, ln)           BSP_ERROR_FEATURE_NOT_SUPPORTED```instead if I modify the generated DISPLAY/Target/lcd_conf.h with`#define LCD_SPI_Send_DMA BSP_SPI1_Send_DMA`seems work correctly.I am using:Nucleo WB55RGGFX01M1STM32CubeIDE 1.9X Cube Display 2.1.0 (in the package 2.0.0 was correctly defined)Is this only a STM32CubeMX bug or I can't use SPI + DMA+ Display?Thanks for the support

In order to achieve minimum power drain on the B-L072Z-LRWAN1 discovery board, it is necessary to remove some solder bridgesSee: https://community.st.com/s/question/0D50X00009XkbSOSAZ/excess-current-consumption-running-bl072zlrwan1-from-batteryAnd:https://community.st.com/s/question/0D50X00009q4M1zSAE/cant-power-bl072zlrwan1-with-batteryTo be able to use the onboard ST-Link again, these connections need to be restored:NRST: link CN4.3 to CN12.5;SWD: fit two links on CN8;VCOM: link CN5.1,2 to JP6. Rather than have to mess about with 2 separate links for the SWD, a single-row 4-pin header can be adapted:

We recently received our B-L072Z-LRWAN1 but are not able to run the program while batteries are plugged in. In the datasheet it says that we need to remove SB37 to accomplish this. But then I cant program it anymore? How can I use the board with battery only and still be able to program it?

Posted on December 11, 2017 at 20:21   I have removed all the solder bridges & links to minimise stray consumption. When I measure the combined current through JP3 and JP1 (ie, MCU & RF), it is ~0.87mA between Tx pulses.  (SB19,14,17 are removed; JP2 is not fitted - so no current to USB_LRA) But, when I power the board from the battery, and measure the battery current, I see 1.95mA  (SB18 is removed) The ST LD39050 regulator (U7) is supposed to be ''low quiescent current'': the datasheet says it should only, typically, be taking 100uA at 500mA load - so we should be nowhere near that! So where is this extra milliamp going?? EDIT To clarify: the ~0.87mA to MCU & RF is measured while powered from the battery. #current-consumption #b-l072z-lrwan1 #low-power #current Note: this post was migrated and contained many threaded conversations, some content may be missing.

Hi,I am using an official STM32MP157C-DK2 board.I tested to build OP-TEE 3.17.0 for stm32mp1 however the boot hangs.I am building OP-TEE OS using:make PLATFORM=stm32mp1 \ CROSS_COMPILE_core=arm-linux-gnueabihf- \ CROSS_COMPILE_ta_arm64=arm-linux-gnueabihf- \ CFG_ARM32_core=y \ CROSS_COMPILE_ta_arm32=arm-linux-gnueabihf- \ CFG_TEE_CORE_LOG_LEVEL=2 \ CFG_TEE_CORE_DEBUG=n \ CFG_EMBED_DTB_SOURCE_FILE=stm32mp157c-dk2.dtsThe full image (st-image-core) I am using is based on meta-st-stm32mp and open-stlinux (dunfell branch)The kernel is the one present in the meta layer: kernel (5.10.61)I am aware that an existing version of OP-TEE is present in the build however it's from version 3.12.0.I tried to build OP-TEE OS version 3.16.0 apart and include it in the final image and it works as expected.I investigated and the issue comes from the linux-stm32mp kernel patches because when I built the stable kernel based on the same version 5.10.61 without patches, it works with OP-TEE 3.17.0 without issu

Bug report in HAL.Under heavy load, the USB Host stack can hang due to the EPDIR flag on an IN Channel being incorrectly cleared by the HAL.stm32f4xx_ll_usb.c, function USB_HC_Halt, clears EPDIR in the case that the request queue is full. This routine is called by IN & OUT interrupt handlers and can there leave EPDIR wrongly reset for an IN channel.In the case of using DMA, tech ref says (in section 'Halting a Channel') that code does not need to check for request queue full - so I think the code should probably take DMA into account as well.I am using DMA, I have commented out the process queue check.