I am using a rapberry pi pico to read the temprature from a k-type thermocouple. in the code, I added a while loop, but no way to break it, and I also named it main.py. the code automatically runs on startup, and I cant stop it. I've tried to stop it in thonny and pressing CTRL+C. it keeps saying the pico is busy, and I have to wait till the program ends. I tried to open it in storage mode, but it continues to run the script. I also soldered a wire to the TP6 pad to make sure the bootsel button wasnt broken. still nothing. I think I have to flash RenameMainDotPy to the pico, but I'm not sure how to do that as the pico wont open in storage mode.
any help would be greatly appreciated.
Related
I am a software engineer working on a microcontroller system for a side project. The microcontroller I am using is the SparkFun ProMicro (based on the RP2040 board). I am trying to flash the board so that I can write data to the onboard flash memory.
All of the tutorials I have found online suggest starting in boot mode, dragging and dropping the UF2 file, and done!
When I do this, the microcontroller ejects from my computer. Is that meant to happen? It just reboots then doesn't reboot in bootloader?
Once I got MicroPython installed I moved on to writing and flashing code to the board.
I am using the Thonny IDE which identified the correct board (albeit the PICO), then saved the following file as main.py (taken from RPI foundation). It prints toggle, and I believe the output shows that it is being printed from the board, but the light on the board isn't blinking. (code and output below)
I considered that the pinout could be different from this board and the PICO, but some research shows they both use Pin 25 for the LED control.
All this leads me to believe I am on the right path, but I think I am missing something that is taken for granted in the tutorials. My end goal is to write arbitrary text data to flash storage, but I understand it can only take about 8000-10,000 writes before it becomes unreliable, so I want to test that I can write working code before I use some of those.
Is there something I am missing, or am I not thinking about this in the right way?
When I do this, the microcontroller ejects from my computer. Is that meant to happen? It just reboots then doesn't reboot in bootloader?
Yep.
but the light on the board isn't blinking.
Maybe your LED is busted, cause your code is right.
My end goal is to write arbitrary text data to flash storage
That's a terrible idea, unless you just like burning up boards for no good reason. Get an SD Card reader or concoct one out of a solution like this one, and use this sdcard library that will even mount your card, and add it to the syspath. Then you can essentially write all the arbitrary text data you like without burning up your RP2040.
Blinking this LED was harder than I expected. I ended up finding this sample code from AdaFruit and using the commented out neopixel code. The... bright side was that there was way more control over this led that I had realized.
Dont forget you have to add the neopixel.mpy from the bundle to your board.
With the RPi Pico W, you can now identify the led pin with "LED" instead of pin 25 (or another pin). This change is due to pin 25 being used for the Wifi chip on the Pico W. This works on Pico W as below
from machine import Pin
import time
led = Pin("LED", Pin.OUT)
while True:
led.toggle()
time.sleep(0.5)
I have verified this working on a RPi Pico W with MicroPython - using the unstable python version - rp2-pico-w-20220719-unstable-v1.19.1-181-gc947c2529.uf2.
I believe this is intended to become the standard way to access an on board led, since the port can be changed for different boards without changing source code.
That's not a simple LED connected to pin 25 on the Pro Micro RP2040 - it's a WS2812 RGB LED, sometimes called a NeoPixel. There's a one-wire protocol to drive these devices.
MicroPython has support for NeoPixel's built-in:
from machine import Pin
from neopixel import NeoPixel
pin = Pin(25, Pin.OUT) # set Pin 25 to output to drive a NeoPixel
np = NeoPixel(pin, 1) # create NeoPixel driver on Pin 25 for a single pixel
np[0] = (255, 0, 0) # set the first pixel to red (R, G, B)
np.write()
See the rp2 Quickref for more details.
I am a new STM32 user migrating from Atmel/Microchip's SAMD line.
I created my first project following along the tutorials here: https://www.youtube.com/watch?v=x_5rYfAyqq0&t=682s. It's a motor driver, with some other hardware shown outside of the screenshot below, but at the moment I am just trying to get statusLED to blink. I can successfully connect to the board with an STLink, when I press debug and resume, my LED will momentarily flash which I capture on video and scope, shown in the video here.
Strangely I don't lose connection to the board or anything, and my program continues to execute, but nothing else happens. As you can see from the code it's supposed to just blink every 500ms. Does anyone have an intuition as to what might be going on?
Here's a video showing the momentary flash (The LED is in the bottom right corner of the board and I press the debug/resume buttons off camera)
https://photos.app.goo.gl/BfGQbW1SX8EJT5eV8
I am using the internal clock for debug purposes, and only have Trace Asynchronous Sw debug + the statusLED set as GPIO output. My only added code is:
HAL_GPIO_WritePin (statusLED_GPIO_Port, statusLED_Pin,GPIO_PIN_SET);
HAL_Delay (500);
HAL_GPIO_WritePin (statusLED_GPIO_Port, statusLED_Pin,GPIO_PIN_RESET);
HAL_Delay (500);
Also here's the board schematic:
STM32F302R8 Board Layout
HAL_Delay depends on the SysTick interrupt being enabled and hooked up to the HAL.
You need to call HAL_Init() from main(), which in turn calls HAL_InitTick().
After that you need the function:
void SysTick_Handler(void)
{
HAL_IncTick();
}
The example projects in the STM32Cube package will include this.
if you configured your Hardware with CubeMX:
check your CubeMX configuration if your GPIO is set up correctly as "GPIO Output" in "Open Drain" oder "Push Pull" mode. According to the schematics "Open Drain" would be my recomendation, but Push Pull would also work.
One of my favourite mistakes is clicking one line to low in CubeMX, selecting "GPIO_Analog" for the pin instead of "GPIO_Output" and searching the code for a long time for a bug where there is none ;)
This turned out to be my having pulled up Boot0 with the intention of using a bootloader, and then forgetting about it. So I rotated my Boot0 resistor to be a pulldown and everything is working now.
Still unsure what configuration is going on to get the brief LED flash in the video, but definitely consider this resovled.
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.
I use a Raspberry Pi and the PiTFT display for a program with kivy. In the program you can start a process and amongst other things you can then pause or stop it. Clicking "Pause" will lead to the button saying "Continue". Now when you click "Pause" and then without continuing "Stop", something weird happens: The touchscreen stops working. You can't click any more buttons, neither in my program nor in any other.
I know you might think it has to be something in my code, but I promise it's not. The process does things in a while loop over and over again which contains another while loop that is only executed if the value 'paused' is not set. And it works fine on my laptop. Also: There are two versions of the program. One reading values from an AD-converter connected to the pins and one just generating random values instead. And the one with the random numbers does not have this problem. So it's really not about the code..
Sometimes it happens that after like 2 minutes suddenly the "Start"-button that I pressed the 2 minutes ago is reacting again. So it somehow seems as if there's just a huge delay. It then works fine again until you do the "Pause" -> "Stop" thing.
The last weird thing is that when I reboot, the touchscreen is not working at all, not even at the beginning. And also not after a few minutes, there's no delay. It always works again after the second reboot.
So I really don't know where this is coming from. The only difference is the AD-converter-part, but that worked fine before. I used the device for months and this is just happening now. And it's so weird that not the program crashes but the whole touchscreen.. even after the reboot.
I also tried another Pi, but it gives me the same problem.
Does anyone have an idea what I can do?
Any chance you see a tiny little rainbow square in the upper right?
The Pi uses it to indicate that you're drawing too much power.
Since TFTs are normally powered directly from the Pi, it stands to reason that if you're putting extra load on the system while already using a TFT, it could be enough to push it over the edge.