Using st7789 tearing pin interrupt for synchronization of lcd display. But getting interrupt at very high rate hence all other tasks are getting delayed. Help me in configuration of tearing pin interrupt at lower rate so other task will get MCU time and get executed.
Using stm32l4 with st7789 driver to drive TFT LCD display.
Related
If i want to use mpu6050 intterrupt to wake up stm32.
when i move my board,stm32 can wake up form stop mode.
i have realized the iic communication between stm32 and mpu6050.and stm32 can already enter stop mode.
I'm using the STM32L496 and attempting to use the CAN interface with the embedded bootloader. I know I can put it into the bootloader, I can see the bootloader mapped to memory zero-address. And I can see the HSI is checked and system clock set to 72MHz as it should. However, when I attempt to send the first CAN frame (which should kick off the CAN command loop), the device resets. If I have boot0 high, it will reset to the application, but if I hold it low it will reset to the bootloader again.
I have a 24MHz oscillator connected to the HSE pins. Why does the device reset when I send a CAN frame (any CAN frame)?
The first flashing went fine, subsequent flashings fail with
Error in initializing ST-LINK device. Reason: No device found on
target.
On an STM32H745 NUCLEO board I have enabled the DEBUG interface and SWO pin by mistake. Is there a way to hard reset this board ?
The "flashing under reset" trick did not work. That is, holding the reset button pressed and immediately releasing it before STM32_Programmer does its thing through ST-Link. A bit of RTFM-ing sometimes helps:
If a deadlock is faced due to a mismatch between the HW
board setting and the FW setting (LDO/SMPS), the user can
recover the board by doing the following:
- Power off the board
- Connect CN11 ‘BT0’ pin (BOOT0) to VDD using a wire
- This changes the BOOT0 pin to 1 instead of 0 and thus the
device boot address is changed to boot address 1 making the
bootloader starting in System memory, instead of starting the
FW in the user Flash (FW that is setting a wrong LDO/SMPS
configuration)
- Power on the board and connect using
STM32CubeProgrammer
- Erase the user Flash
- Power off the board and remove the wire between BOOT0
and VDD
- The board is now recovered and can proceed normally.
Now I got to figure out why it goes deadlocked as soon as I flash my bin... commented some bits of code and rebuilt, sill does it.
LE: found the offending lines:
HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);
...
My SystemClock_Config function was all written for LDO power instead of SMPS
I have a use case where the Movesense sensor will be used occasionally (say, an hour a day) and I'd like to maximize battery life. Is there a way to put it into a sleep state, and then wake it in response to some user action? For example, shut off Bluetooth and all sensors but the accelerometer, and then wake them up with the accelerometer detects that it's being moved or tapped.
I see that the Movesense sensor can be put in "PowerOff" or "FullPowerOff" state. In these states is it completely shut down, or is it possible to continue to monitor the accelerometer?
Yes, it is possible. You can check hr_wakeup_sample:
https://bitbucket.org/suunto/movesense-device-lib/src/887714f3b42496988cce6055b3ccf8b8c99a6846/samples/hr_wakeup_app/?at=master
The device is waking up when you put your fingers to the metal pins (on the bottom).
Also you can change this line:
asyncPut(WB_RES::LOCAL::COMPONENT_MAX3000X_WAKEUP::ID,
AsyncRequestOptions(NULL, 0, true), (uint8_t) 1);
https://bitbucket.org/suunto/movesense-device-lib/src/887714f3b42496988cce6055b3ccf8b8c99a6846/samples/hr_wakeup_app/HrWakeupApp.cpp?at=master&fileviewer=file-view-default#HrWakeupApp.cpp-132
to use this API:
https://bitbucket.org/suunto/movesense-device-lib/src/887714f3b42496988cce6055b3ccf8b8c99a6846/MovesenseCoreLib/resources/movesense-api/component/lsm6ds3.yaml?at=master&fileviewer=file-view-default#lsm6ds3.yaml-119
Am I correct in assuming that it's not possible to exit from STOP mode on SPI receive interrupt, because all the clocks are stopped?
Yes, SPI is stopped in STOP mode.
If your MCU is the SPI slave, and you can afford to lose the first packet, i.e. the master will restart if it doesn't get the right answer, then you can reconfigure the NSS pin as an EXTI activated on falling edge, it will work even in STOP mode.
You are correct, SPI receive interrupt cannot be used to wake up the controller from STOP mode.
But any EXTI Line configured in Interrupt mode can wake up the microcontroller. (Table source)
The complete EXTI line mapping can be found in the reference manual, page 176. From GPIOs are mapped to EXTI0 - EXTI15. And the remaining usable lines are the following:
EXTI line 17 is connected to the RTC Alarm event
EXTI line 18 is connected to the internal USB wakeup event
EXTI line 19 is connected to the RTC Tamper and TimeStamp events
EXTI line 20 is connected to the RTC Wakeup event (available only on STM32F070xB and STM32F030xC devices)
EXTI line 23 is connected to the internal I2C1 wakeup event
What you can do is configuring an external interrupt on the GPIO pin of the corresponding SPI line which will wake up the controller. After that the proper SPI RX interrupt can be used. Note that you will lose the early data on the SPI as you will only have a GPIO interrupt and the SPI peripheral will be stopped until wake up.