I am solving a problem with the software reset of the STM32F427 microcontroller. Doing a software reset of the MCU is not a problem, it works great and the MCU boots up nicely.
During the software reset, the processor pulls its reset pin to zero. This reset pulse is now a few milliseconds long. I am working on how to make this reset signal longer. I would need it to be about 10ms long.
Does anyone know if and how this signal could be extended by modifying the software? (some wait instructions at the very beginning of the run, modification in the options byte, change in the system initialization code)
This is what the MCU pin reset signal looks like during a software reset.
Background of the problem:
I have a finished hw that runs normally and sometimes it is necessary to do a sw reset (fw update, untreated error, etc.). This hw has a COMMON reset pin for MCU and another chip (hw reset pins of both chips are connected). An RC element is connected to this signal so that the sources have time to warm up before the MCU starts up. It's fine on a cold start, but the SW reset has a reset pulse too short for the second chip. This second chip will then remain in a strange (non-functional) state. Therefore, I would need to extend the reset signal.
The HW is finished, it can no longer be modified. The reset connection was a bad idea.
Related
I have an STM32F103C8 board and my program is switching the GPIOB1 with frequency of 500KHz.
At first, microcontroller runs the program perfectly but the main problem is that MCU resets after a couple of hours and stays at reset mode until I disconnect the board from the power supply. If I power the board immediately after disconnecting, MCU will not work but if I power the board few minutes later, the MCU works properly just for a couple of hours and after that, the same problem is repeated.
I already faced another problem that this issue was happening after 15 minutes, I added a 10uF capacitor to the VDD3 pin and now, this problem(going to reset mode) happens after about 5 or 6 hours.
Do you have any suggestions about hardware or program?
What should I do with the reset pin? (Currently, I'm pulling up nRST pin with a 10K Ohm resistor)
Can this happen because of the wrong power-up sequence on VDD, VDDA, and nRST pins?
Is this similar to a clock malfunction?
This is the schematic
Thanks in advance,
Amir
So I saw this video:
https://www.youtube.com/watch?v=4ElZec033vQ
https://www.youtube.com/watch?v=ClFSUXebY7Q
This video does it without the whole circuitry.
And I wanted to do something similar, but more controlled.
I want to be able to use a raspberry pi to operate a phone screen (like your finger does) and be able to code how long between turning the touch on and off. I'm using Python. I have a penny on my screen and the wire touching it. The wire is connected to GPIO 17. When I first boot up the pi, touching the wire to the penny does nothing. I have a program that registers GPIO 17 as an output and turns it on and off. When connected to an LED, it does just that. However, it constantly activates the phone without ever turning off, even when I stop the program. I tried cleanup(), which does work in a weird way. If I hold it to the penny, cleanup() doesn't do anything and the wire continues to activate the phone. But if cleanup() has already happened and I briefly break the connection, then it no longer activates the phone.
How can I code a wire to put out a signal and turn off said signal when I want?
The guy in the video is using C and an arduino, so basically I want to convert that to a Raspberry Pi with Python.
use the Gpiozero library .... there look for Led
import gpiozero
import time
coin=gpiozero.LED("GPIO17")
while(1):
coin.on()
time.sleep(1)
coin.off()
this code should control GPIO17 but you can choose another. Just try
So I'm using an STM32F103C8T6 board and it was working fine a few days ago but then tried to load a code with keil vision compiler these days and it showed this message STLINK Error(DEV_TARGET_HELD_UNDER_RESET).
After that using the STM32CubeProgrammer also shows the same problem, only connects with the "hot plug" mode
as you can see here
Its cleary a reset error, but I really dont know how it happened and don't find much resources on the internet with this problem and now I can't download any code in my stm32f103 board it shows
this message
After researching on the internet found it might be soldering problem, but I dont think its the case, i'm only using the microcontroller, not any bread board circuit, and it was perfectly fine days ago. All my write and read protections checkboxes are unchecked in the STM32CubeProgrammer sections too.
I guy on the stcommunity just said "he went through all CPU pins and the board started working." but is it a problem with the pin reset? in the STM32F103C8T6 board it has a reset buton but how can a search a problem in it?
Ok, this is what I did and now it seems to be working (I'll try to be as descriptive as I can, so you or anyone who's got stuck into this can compare):
I'm using STM32CubeProgrammer v2.6.0 under Ubuntu. The parameters to connect to the target are:
Port: SWD
Freq: 4000 kHz
Mode: Normal
Access Port: 0
Reset Mode: Software reset
Shared: Disabled
I'm using an STM32f4 Discovery as a programmer, to achieve this the jumpers should be disconnected. It is supposed that SB11 jumper (under the board) should be unsoldered too, but as you will see I'm not using the reset line on SWD. The target (STM32F103C8T6) is powered independently (+3.3V).
The connections between the target and programmer are the following:
Prog pin1 (VDD) --> NC
Prog pin2 (SWD Clock) --> PA14 (Pin#37)
Prog pin3 (GND) --> VSS (Pins# 23,35,47 and 9 if common digital analog ground)
Prog pin4 (SWD I/O) --> PA13 (Pin#34)
Prog pin5 (NSRT) --> NC
Prog pin6 (SWO) --> NC
I have access to the target's NSRT (Pin#7) through a push-button (this is important).
Once all this is ready, what I did was to press and hold the reset button, then press the connect button in STM32CubeProgrammer (without releasing the reset), and wait just two seconds, then release the reset. After this process, the target was connected and I was able to program it normally.
The program will not run immediately, you need to push and release the reset button again.
Juliane - the (DEV_TARGET_HELD_UNDER_RESET) message means that something is holding nrst to ground. You can't do much apart from 'hot plug' when in this mode. If you have a reset button then it may have failed in a connected position which will pull NRST to ground defeating the internall pullup.
Can you check the resistance across you reset button in down and up position. I suspect it is 0 ohms (or at least lower than internall pullup resistor).
If you don't have a reset button then check to see what circuitry is around NRST and try to work out why its pulling to ground.
First you need to clear the existing flash memory
it can be done with ST Link Utility or STM32CubeProgrammer
Hold down Reset button while clicking 'connect' on STM-Prog, then navigate to 'Erasing & Programming' and click 'Full chip Erase'
or
while holding reset click Full Chip Erase on ST Link Utility
After the chip is clean try setting the Debug to Serial wire
this will allow to flash new code to the board multiple times without having to clear the flash memory or holding reset before upload
in Pinout & Configuration
or in stm32f1xx_hal_msp.c
"DEV_TARGET_HELD_UNDER_RESET" can also have a hardware reason. I experienced this by accident with a PCB where I mixed up some numbers and ended up with a 10 Ohm resistor instead of a 10k Ohm resistor between 3V3 and the NRST pin on a G431RB. Usually I use a 10k resistor to connect the Reset Switch to the NRST Pin.
The end of the story was, that I was not able to connect to the MCU, the error message was "DEV_TARGET_HELD_UNDER_RESET" and I had some hard time to figure out what it was. Once I replaced the 10 Ohm Resistor with the correct value (10 kOhm) anything worked fine.
Is it possible to configure a GPIO input that sets a flag when rising or falling edge is detected without interrupting the CPU? I can then check the status of the flag in the main superloop? There is an option in CubeMX to configure the GPIO mode as "External Event Mode with Rising/Falling edge trigger detection" but I'm not sure how to read the event flag. Is this the correct mode to achieve this?
I'm not sure about the event mode (haven't used them before) but you could also use the
External Interrupt Mode with ... as long as you don't activated the IRQ Handler in the NVIC the CPU is not interrupted by any pin change.
The information if an event/interrupt has occurred could be found in the EXTI_PR register.
(See reference manual 12.3.6)
I want to wake up my stm32 controller from standby mode by giving a rising edge on WKUP pin, but there is a problem. When I press the switch on a WKUP pin for more than 10 seconds, then and then only my controller should wake up not by just pressing and releasing the switch.
Depending on which low power mode the STM32 is in (sleep, stop, standby), there are a couple of ways I see right now to do this:
Software: Wake the MCU up on the rising edge on your WKUP pin immediately. Then wait for 10 seconds and keep polling the state of the pin (in a busy loop) or check if a falling edge interrupt on the pin has happened (the GPIO would probably need to be reconfigured for that). Depending on the low power mode that was used, only the required peripherals would need to be reactivated during the waiting period, and if an IRQ is used for the falling edge, the core would not even need to be clocked during that time (a timestamp could be recorded after wake up). If the WKUP pin is released before 10 seconds have passed, the program could signal that by flashing an LED or a beep, and go to sleep again.
Hardware: An external circuit could be used to wait for 10 seconds until it actually signals the MCU, which isn't bothered at all before the actual wake up event happens and no special software would be required. If accuracy isn't that important, a simple RC circuit could be used. There also exist specialized, accurate delay ICs that do exactly that (e.g. the TimerBlox series by Linear, e.g. LTC6994, you can set the delay time with a resistor).
MCU Peripheral: Use an STM32 peripheral to implement the delay: maybe try to set up an RTC or TIMER/COUNTER interrupt after WKUP, so that an interrupt will be triggered after a certain amount of time, and go to sleep again. However, you would also need to setup an interrupt on the WKUP pin to cancel the action when the pin goes low before the waiting period ends.
Which approach would be the best certainly depends on the application requirements (accuracy, power usage, simplicity etc.). - The first one is the easiest and most straightforward IMHO, since power usage usually isn't an issue for 10 seconds of busy waiting. And accuracy also isn't that important for waking up the MCU after sleeping, right? - So the other solutions are probably overkill.