I bought a new micro:bit v2 board, and want to add it to Scratch as an extension. I followed the 2 steps from https://scratch.mit.edu/microbit. The step 1 is ok, the led lights of my micro:bit board is flashing 5 characters "zepiv", but the step 2 failed.
The scratch link is running, and the bluetooth is enabled.
The os version is macOS Big sur 11.4(Mac mini late 2014), the bluetooth LMP version is 4.0(0x6).
The weird thing is that the board isn't visible to my Mac, but it is to my Android cell phone.
Is this a problem with my computer? Could anyone help me? Thanks in advance.
Good question, I had a lot of trouble with the same issue when connecting my LEGO MINDSTORMS EV3© to scratch. If you want to connect a device easily a good idea is to have it paired via Bluetooth already. To pair it with a mac:
Open the settings app
Select Bluetooth
Switch your micro:bit into pairing mode:
Hold down buttons A and B on the front of your micro:bit together. The front is the side with two buttons and the LED display. Keep the two buttons held down. Don’t let go of them yet!
While still holding down buttons A and B, press and then release the reset button on the back of the micro:bit. Keep holding down buttons A and B.
You should see “PAIRING MODE!” start to scroll across the micro:bit display. When you see this message start to appear you can release buttons A and B.
Eventually you’ll see a strange pattern on your micro:bit display. This is like your micro:bit’s signature. Other people’s micro:bits will probably display a different pattern.
(I found these instructions at this website)
In the Bluetooth menu, look for your micro:bit device and select Pair
After the device has paired, go back to scratch with scratch link activated, and attempt to connect to the device again.
This worked for me when I connected my EV3 device and I hope it helps you.
Related
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 think that my question is a little bit dumb but i am really stuck in this problem.
I have an embedded SAMA5D27-SOM1-EK1 board which i build Linux OS image version 4.14 with YOCTO project.
Now i want to control a RBG LED using a push BUTTON existing both on the board.
They asked me to check for GPIO drivers if they are existing in my Linux Image, I don't know how to check, then to make the LED Lights when I push the Button.
For the moment i have only the PINS of the Led and the Button.
I don't know what i must do now.
Thank you for your help!
A few Days ago my loved PC Mouse, a Razer Death Adder, died because of a rage attack of my boyfriend. So I decided to get a new one from Mad Catz, because why not trying ... A few days later I got her, a very nice Mad Catz R.A.T. PRO X.
I'm working with Unity 3D in the Version 4.0.0.0f. You may ask yourself why I'm not using the newest version? Answer is simple, I'm not allowed to, my University says all projects have to be done in the Version 4.0.0.0f.
Enough from the introduction... While testing a game I made, I pressed the DPI-Button on the R.A.T. and my character starts to constantly moving forward. It only stops if I leave the Screen and use for example my browser or another program or I restart unity completely.
I wrote a small script to show me what Buttons are pressed while I pressed the DPI-Button. It turns out that the following BUttons are Pressed if I press the DPI-Button:
JoystickButton6
Joystick1Button6
So I had a look in the Mad Catz Software and tried do define a custom Profile where the DPI-Button is simply a Shiftkey, the Software looks good but it had the same result in the game.
Is there any Unity 3D Developer with a Mad Catz R.A.T. PRO X with the same problem?
A simple Solution is to disable the Controller Driver of the Mouse.
It can be achieved by disabeling the driver in the computer management!
I already asked this questions over at Ask Ubunutu. Unfortunately I have not received an answer. As this question is not Ubunutu specific, I am trying it here.
I am using xrandr via console to enable/disable secondary monitors. This work fine so far. Unfortuantely if I move my mouse beyond one screen, it appears on the other one. How can I disable this feature - and lock the mouse to one screen?
I use Ubunutu 10.10 and awesome - no gnome/kde.
I've never seen anything in the Xrandr or Xinerama docs about restricting mouse movement to a single monitor.
And, before Xinerama, I used to run multiple X screens on multiple monitors, but the mouse moved freely between the monitors without trouble. (Windows were stuck on the monitor they started on; it worked much better than it sounds. :) So that's probably out.
You may be able to solve this starting another X server. Configure the second X11 for the correct screen, no mouse (keyboard too?) input device, and start clients on that second X server using DISPLAY=:1 xterm & and so forth.
This may sound like an odd question, but has anyone noticed that their iPhone apps launch quicker when built for distribution over being built for debugging?
Our app initially launches really slowly when compiling it for debugging / running it through xcode. (on device)
So I then dis-connected the phone from xcode and ran some extremely unscientific tests... (To try and quantify the slowness of the app)
Turned iPhone off then on. Booted my app. Counted to 6 mississippi's.
Closed app, re-launched it. Counted to 4 mississippi's.
Turned iPhone off then on. Booted 'contacts' app. Counted to 2 mississippi's.
Closed 'contacts' app, relaunched it. Counted to 2 mississippi's
The reason I compared to the contacts app is that it's pretty similar, UIWise to my own app. (Although its probably doing a lot more than my app is in the background).
My app is a navigation based app and the root view has the following elements:
UISearchBar
UISwitch
UIImageView
3x UILabels.
Not exactly a tasking amount of elements to initially load, so if there isn't a slight speed increase when building for distribution, I need to try and find the cause of whats taking the app so long to load!
One thing I thought could be the issue is that I'm using interface builder for the layout of my view(s). Could I be taking a loading hit as the initial view de-serializes?
Thanks for any input,
Jon
It's because the Distribution configuration is usually duplicated from the Release configuration in xcode, and has the "Strip debugger symbols" option turned on. Stripping symbols only used in debugging means there's less to load - which makes it faster.
I've noticed this before. I've always assumed that it has something to do with the iPhone interfacing with the Xcode debugger. I'm just guessing here, but I just tell myself it's telling the iPhone about any breakpoints and what to do when it hits them and stuff, among other "stuff". The iPhone is also probably talking to Xcode about keeping stuff in sync in case of a crash or something.