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)?
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.
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.
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
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.
I have put together a media converter that converts from 100Mbps ethernet on one side and 100BASE-FX fiber on the other. The application that this converter goes into uses Full Duplex / Pause Frame flow control to handle data overloads. I have configured my hardware to accept and deal with pause frames. What I need is a means of testing the setup to see that the media converter correctly handles the pause frames. To that end I have 2 questions....
1) Does anyone have a good method for testing a piece of hardware for it's handling of pause frames?
2) An idea that I had was to send data through the converter. While doing so, send a pause frame of a known length to the converter. Then look to see that the device pauses for the correct amount of time. Does this method seem plausible? If so, is there an easy way (software tool) to generate pause frames to accomplish what I am trying to do?
Any help here would be greatly appreciated.
Thanks,
Mike Nycz
There are two types of Pause frame testing:
1) Your device should detect Pause frames and stop transmitting for the time mentioned in received Pause frame. If you send a few pause frames to your device, it can be difficult to detect whether your device stopped transmission for that small duration. What you can do is to send Pause packets continuously. By doing this your device should altogether stop transmitting till it is receiving pause packets.
2) Your device should generate Pause frames when RX FIFO level is above a certain threshold and should stop generating them when level again goes below the threshold.
You can use a Packet generator like N2X/IXIA etc for generating pause packets. One more thing Pause packets should be of 64 bytes only. For size other than 64bytes, device may opt to reject them.