Solved

HiI have some wiedgets which are using the registerTimerWidget functionality.My software crashes with an assertion:*** assertion failed: timerWidgets.size() < MAX_TIMER_WIDGETS, file ../../../../framework/source/touchgfx/Application.cpp, line 585The MAX_TIMER_WIDGETS are defined as 32 in the file Application.hpp. Now I wanted to increase that number, but the crash still happens at 32 registrations.Now I assume that the library is precompiled with MAX_TIMER_WIDGETS = 32 and that your check does not check for the size of Vector<Drawable*, MAX_TIMER_WIDGETS> timerWidgets;Anything I can do to increase that number? @Martin KJELDSEN​ Thanks for your help./jimmii

..

Hello,I am developing a system using VL53L1X.Occasionally, when the host microcomputer is asynchronously reset, there is no response from the sensor after that.It can be detected that the sensor's SDA is stuck at Low. We can handle it.The situation I am encountering is that the sensor's SDA line is high, but I2C communication is not possible.Is there an internal state that ignores the start condition from the host microcomputer?If so, please tell me the transition conditions to that internal state.Best regards.

Hello,​I am developing a system using VL53L1X.Occasionally, when the host microcomputer is asynchronously reset, there is no response from the sensor after that.​I've never used the xshut terminal.If communication with the sensor becomes impossible, I'm thinking of using the xshut terminal to synchronize the host microcomputer and the sensor.Please let me know the setup time required to start I2C communication after setting the xshut pin to high level.​From the topic below, I think 10ms is enough, but I would like some information as a specification. Title:vl53l1x-xshut-pin​​Best regards.

Hi, I cannot debug stm32mp157-dk2 on macOS (stm32cubeide). I have those logs in the console:Does anyone know how to resolve it? :)

I'd like to raise attention of ST staff regarding the LPS28DFWTR pressure sensor and what I believe is a sensor design issue (I hope I'm wrong, because it is an amazing sensor nevetheless!).The original topic was here:https://community.st.com/s/question/0D53W00001r8PF1SAM/what-is-the-material-the-membrane-is-made-from-on-the-lps28dfwJust in case I copy-paste results of my quick research here:I confirm that LPS28DFWTR is not just sensitive to sunlight, it is sensitive to ANY light! It feels like some p-n junction on sensor's die is exposed to light through transparent silicone and it's confusing readings/I2C. I'm attaching video here:https://veed.io/view/a25b61dc-20d8-4442-998d-9bb3f83cf191It's a simple setup where I measure both pressure/temp using LPS28DFWTR and convert it to altitude (you can see current altitude and temp resdings on display).As you can see on the display, when I cover membrane and sensor to light - pressure readings are fine.When membrane is facing bright

Hi, I have an application that suggests the pressure sensors are very sensitive to sunlight. 1. I have noticed the same behaviour. Can anyone confirm if the sensor experiences a photo-electric effect that amplifies the signal current within the sensor?Images below are of a device with two LPS33HW sensors mounted in orthogonal directions being dipped in and out of water. In the first case this is done inside under ambient light, in the second it is outside in direct sunlight. 2. In some cases we have observed the sensor measurement circuit appears to lock up but the digital line continues to output the last known value. Can anyone confirm the following: I suspect the Analog circuit has experienced some overcurrent and has shut itself down, but the digital line remains powered and keeps reporting the last known value.Can anyone confirm this behaviour? 

HelloI have recently acquired a B-L475E-IOT01A2 IoT node, which has an integrated SMT32L475VGT6 MCU microprocessor.I have installed the STLINK V2 driver and tried to connect to it via a microUSB type B cable to the USB_STLINK port (CN7), with jumper JP4 on pins 1 and 2. So LED5 lights green and I proceed to load (in CubeIDE) a project previously generated with CubeMX. Then I receive the following error message: "No ST-LINK detected! Please connect ST-LINK and restart the debug session".Therefore, I try to connect through CubeProgrammer to the micro-controller but I am not able to. I have tried to update the STLINK driver firmware and I still can't connect. I have also downloaded and installed OpenOCD as an alternative. I have repeated the process on both Linux and Windows (because I have read in other forums that many users have had problems with the STLINK driver on Linux).So I've been at a loss and unable to transfer a project for a while now. I suspect it may be a bootloader thing,

Hi, my license for SPC5Studio is expired after 1 year trial. Is there any way to extend this license? I do have a permanent license but it's activated on another Lab PC (connecting to a UDESTK dongle). I need to activate it on my personal PC so that I can create/build and send the program to the target PC. Thanks Bui

Hi guys,I am using and STM32L552ZET6 and I get a behavior I can not exaplain. The device is power at 1.8V in case it matters. So to put it shortly I have 2 blocks of 8 pages each. At first start I erase both of the blocks and write only in block 1 some data. When I get some data to save I write it in block 2 but first I write two doublewords used as markers on top of the first page of block 2 after which I copy most of the data from the first block. My problem is that for the first 24 octets I try to write I get back NSPROGERR and NSPGSERR, and for the rest everything works out great and are written. If I erase the page again just before writeing I get no errors and everything gose perfect.I have tried to debug it by printing the info found in the locations just before programming and I get 0xFFFFFFFFFFFFFFFF in each location with problems.This is the function I use to program:static void FLASH_Program_DoubleWord(uint32_t Address, uint64_t Data){ uint32_t primask_bit; __IO ui

 Hi everyone,i'm trying to use the LPTIM1 in the STM32WB55 on STOP2 mode.I have a STM32WB5MM-DK and I want to generate a PWM on the pc1 output.I configured on the ioc file:LPTIM1- counts internal clock event- checked waveform generation-parameter: prescaler div1 update immediate trigger software output polarity highCLOCK CONFIGURATIONLPTIM1 clock mux on LSE (I tried the LSI with same result)CODE DBG_PRINTF( "*________START PWM______\n\r" ); if (HAL_LPTIM_PWM_Start(&hlptim1, PeriodValue, PulseValue) != HAL_OK) {  Error_Handler(); } DBG_PRINTF( "*________START DELAY______\n\r" ); HAL_Delay(20000); /* ### Enter in Stop mode ########################################### */ DBG_PRINTF( "*________START LP______\n\r" ); HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI); DBG_PRINTF( "*________EXIT LP______\n\r" );So, start the pwm at the right frequencythen wait for 20sbut when the system enter in stop mode, I no longer have the

Hi!I would like to unit test my software, is there any support for that in TouchGFX?Kind regards

Everyone, Posting for the first time here. We've been working with a 4d display that's based on an FT813 IC. The issue that we came to so far is the following.0x7C during Initialization is never detected although, it is detected from MISO. This is read on the logic analyzer. So my thinking is that the FT813 is awake and communicating to the Host.Our setup for FT813 is default : Internal CLK, SPI is at 4Mhz, Pol 0 Pha 1 , STM32 Core Clock is 16Mhz. As I debug the FT813memRead8 function it transmits the REG_ID (0x302000)address however during the SP Receive, we never receive 0x7C. Only when we added an element to return &ftData8[2]; do we receive anything at all. Yet and still it never display's 0x7C that's on the host (MISO). Therefore, we stay stuck at    while (FT813memRead8(REG_ID) != 0x7C) //we should be reading chip ID from C0000 - C0003?    {    }I have personally worked as a firmware engineer contractor for the DOD b

I just want to display 10s data， but the chart records every 10s data ,,the chart display many 10 second data.

Hello everyone,My variable had a Runover even before it reached its range.Currently, I am working with timer 2 with a frequency of 90MHz. When I retrieved the current time by `__HAL_TIM_GET_COUNTER()` and printed it by `printf("receive_time: %lu\n", (unsigned long)receive_time)`, the maximum the `receive_time` get is 16 bits although I declared it as 32 bits. I observed the printed value and it never exceeded 2^16 -1. I also tried to print with `printf("%" PRIu32 "\n",a);` but it also returned the same. I had another 32-bit variable `send_time` which is used later to subtract with `receive_time`. However, it gave me something in the order of 2*10^9 (2147482170 for example) besides some common values.I want to ask what happen and if I do something wrong. If everything is correct, is there any way to handle the rollover besides having 2 timers starting at different times?The code is here:Radio::radio.tx_buf[0] = seq++; /* set payload */   printf("send a rea

..

HiCurrently, I'm designing a PCB with "STM32MP151AAD3T".I'm developing our own PCB with reference to "STM32MP157x-EV1".​DDR trace wiring is described in Section 3.2 of "AN5122" as follows:********************************************************************************​Point-to-point connection of the data bus (2 swappable bytes, and swappable bits in the same byte):– 16 data signal bits (DQ)– 2 data mask signals (DQMx)– 2 differential clocks (DQSx_N/DQSx_P)********************************************************************************​What kind of criteria should I apply to swap bits(DQ) in the same byte?Can I prioritize pattern routing?​Best regards,

HiI have a problem where my NUCLEO-U575ZI-Q board gets a hard fault if I use sprintf. I reproduced the error by creating a new project based on the sample project "Tx_Thread_Sync". So I am using Threadx.I then added two lines to the app_threadx.c  char str[80]; sprintf(str, "Value of Pi = %u", 3);And then places a breakpoint at the variable definition. I run the code and when I click on step into the function for debugging the sprintf function the MCU goes directly to HardFault_Handler instead.Please help.What to do so I can use sprintf??Best RegardsAnders

..

I have STM32CubeIDE installed on a lab machine where internet connectivity is restricted. I need to install v1.27.1. I was able to go to the st.com site and download the en.stm32cubef4_v1-27-0.zip file, transfer it to my lab machine, then using Help->Manage Embedded Software Packages to point at the local ZIP file and install the 1.27.0 main version. However, when I try to install the 1.27.1 patch (en.patch_cubef4_v1-27-1.zip) to upgrade to 1.27.1, the Manage Embedded Software Packages option claims that the zip file is not compatible.It appears that the only way to get the 1.27.1 upgrade is to use the Help->Check for Embedded Software Packages Updates option. But, that requires an internet connection. There does not appear to be a local file selection option. So, now I'm stuck because of the lab's internet restriction.Isn't there a way to get the incremental updates without having to use the internet?

I have a VL6180X that I am running in continuous measurement mode and read from when a hardware interrupt is triggered by the senor. My issue is that I cannot get the sensor to signal at a rate of 100 Hz. Currently, the best I can achieve is 50 Hz.Has anyone had success with this? I have read that tweaking the inter-measurement and max convergence times can help, but I am not sure where to start with those values. Any advice would be greatly appreciated :)Also, within the VL6 API, I noticed that the `VL6180x_RangeSetInterMeasPeriod()` function has the following code block:/* doc in not 100% clear and confusing about the limit practically all value are OK but 0 * that can hang device in continuous mode */   if (InterMeasTime_msec < 10) { InterMeasTime_msec = 10; }This block appears to hard limit the inter-measurement time. Commenting out this check and setting `InterMeasTime_msec=0` helps with reaching 100 Hz, but makes the sensor prone to crashing. Does anyone know why this c

I think there is a bug in the function LL_RTC_WaitForSynchro(). It waits for the RTC_ISR_RSF to become 0 (on row 15). I think this is a bug. It should wait for the RTC_ISR_RSF to become 1 as in the old STM32 Standard Peripheral Libraries. My code sometimes gets stuck in this loop.ErrorStatus LL_RTC_WaitForSynchro(RTC_TypeDef *RTCx) { __IO uint32_t timeout = RTC_SYNCHRO_TIMEOUT; ErrorStatus status = SUCCESS; uint32_t tmp;   /* Check the parameter */ assert_param(IS_RTC_ALL_INSTANCE(RTCx));   /* Clear RSF flag */ LL_RTC_ClearFlag_RS(RTCx);   /* Wait the registers to be synchronised */ tmp = LL_RTC_IsActiveFlag_RS(RTCx); while ((timeout != 0U) && (tmp != 0U)) { if (LL_SYSTICK_IsActiveCounterFlag() == 1U) { timeout--; } tmp = LL_RTC_IsActiveFlag_RS(RTCx); if (timeout == 0U) { status = ERROR; } }   if (status != ERROR) { timeout = RTC_SYNCHRO_TIMEOUT; tmp = LL_RTC_IsActiveFlag_RS(RTCx); while ((timeout != 0U) && (tmp != 1U)) {

Using a STM32F091 board, I set up the ADC to:sample at the longest selectable sampling time (239.5 cycles)clock source is the internal 14 MHz RC oscresolution 12 bitsequence of all available channels incl. vrefintAt startup, there is a slight deviation: I set up the ADC to only sample VERFINT, take a lot of samples and average them; from that, calculate Vdda based on the formula in the reference manual, and store that value in a higher precision format, to calculate all the other voltages with during normal operation of the firmware.Then I set the channel sequence to all channels, as said above.The VREFINT channel is also captured as part of the sequence to, regularly, roughly monitor whether the 3V3 supply voltage is still OK.During operation, when the ADC sequence is being continuously triggered by software, I make the following observations:all channels' values but one stay in their +/- deviation of a few percent from the measured rail's nominal valueonly the VREFINT value has a lot

Hello, I am developing a home appliance application on an MCU STM32G070CB using X-CUBE-CLASSB package and IAR EWARM IDE V8.32.4. I used NUCLEO-G070RB for the early development. The app ran fine until I turned on the SRAM parity check in the options bytes. SRAM parity enabled:The application jumps to the hart fault handler when calling __iar_data_init3 to initialize RAM variables on startup (similar behavior is described here: https://forum.segger.com/index.php/Thread/5957-SOLVED-MEM-MAP-c-error-with-STM32G071/). However, what is worse for me is that the application is not running anymore when the SRAM parity check is disabled (option bytes recovered). SRAM parity disabled: The method STL_StartUp is called from the startup, which performs the startup self-tests including watchdog self-test which performs a reset invoked by each of two watchdogs (two resets overall). However, the MCU is not reset properly and the program instead gets lost somewhere in the system flash memory (0x1FFF 0000

I am using ST25NFC_Embedded_Lib_ST25R3916_1.4.0 on STM32L5 discovery board with X-NUCLEO-NFC06A1And I have no problem to detect and read ST Tag (always correct), but if I use NXP tag I have super strange behavior.On bare-metal application, it works on ST+NXP tag.But on our application that use DMA SPI, and it's 4x slower on CPU I can read st tag but NXP no. He didn't say that he detected anything. From code debug I founded that resolving of NFC conflict always return BUSY and it all. I removed DMA on SPI and still (as the DMA for that short operation give some overhead), but there is a problem. Code is mostly the same, lib is just copied. For me, it looks that this library have a problem on working on more restricted environment. Could you say how to make it working?PS> Before removing DMA I had a problem that protected areas in that lib prevented for getting to interrupt.