please.
I am having weird behavior with STM32F105RB (64pins) board, the issue is on GPIO PB8, PB15, PB9 and PB3.
GPIO_InitTypeDef BOARDPINS;
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE);
BOARDPINS.GPIO_Pin=(GPIO_Pin_9);
BOARDPINS.GPIO_Mode=GPIO_Mode_Out_PP;
BOARDPINS.GPIO_Speed=GPIO_Speed_2MHz;
GPIO_Init(GPIOB, &BOARDPINS);
DISABLEJTAG();
The Problem:
Each time i configured one of these as OUTPUT PUSH PULL (PB8, PB15, PB9, PB3) and toggle a pin, they all act like there is a shot circuit. all these three pins will toggle together.
My Diagnosis:
I tested for continuity (shot circuit) among these pins by taking off power and physically test pair of these GPIOs. but no shot was detected.
I checked the datasheet and reference manual but did not see any special feature associated with these pins.
Every other pin with exception of these four toggles individually, no issue.
My based IDE is Truestudio 9.3.0, i tried using eclipse with arm plugins and also tried Arduiono 1.18.19. none got it solved.
Now, I am asking
What could be wrong?
Is there feature is need to disable?
Related
I am trying to use the USB Device library on STM32Cube but when I execute using the debugger or that I try to turn an LED on in CDC_Receive_FS, it never reaches that point.
Here is how I set up everyting:
My board is a NUCLEO-F746ZG
I enabled USB_OTG_FS in Device_Only mode, activated _VBUS and _SOF. Left everything else by default and USB On The Go FS global interrupt is enabled!
I set up USB_DEVICE: Class For FS IP set to Virtual Port Com, left everything by default
Main loop left empty
CDC_Receive_FS: put breakpoint in it and/or HAL_GPIO_WritePin(LD1_GPIO_Port, LD1_Pin, GPIO_PIN_SET);
I have TIM2 set up for the things I would like to do when it will work
Then I tried to send data to the board, first using Python using serial with a baudrate of 921600 but got nothing. Then using PuTTY with a baudrate of 9600, still nothing...
If anyone has a clue, I have been struggling with it the whole day.
Here is the whole project: https://ecloud.global/s/cjGYqK6z9g58Lm4
I am having troubles using an I2C sensor with the Beagle Bone Black (BBB). The BBB is running a newly flashed 18.04 Ubuntu image specifically for the BBB.
I wired the sensor (VIN, GND, SCL, SDA) to the corresponding I2C2 pins (4, 2, 19, 20) on the BBB using the below pinout.
The sensor is supposed to be using address 0x40, but scanning I2C2 (using i2cdetect -r 2) does not show the sensor.
I have tested this with two separate sensors as I thought at first I may have fried the original sensor somehow, but the results are the same. In fact, running the I2C2 scan command yields the exact same results when nothing is connected at all.
I have read in many places that I2C2 may not be enabled by default, but I assume it is enabled in my case as I can scan I2C2 without getting an error. Is this assumption incorrect? Again, this is a freshly flashed BBB, and I have not enabled/disabled anything - it should be in the default state.
I have also verified the connectivity of my wires between the sensor and BBB. The voltage between VIN and GND on the chip is 3.3V, so it is definitely being powered.
Why can't I connect to my I2C sensors using the BBB?
it could be that the source you are using is outdated or not a viable entry for i2c.
Also, you could use this command to make sure i2c2 pins are available:
config-pin p9.21 i2c
config-pin p9.22 i2c
This may work, also. If this does not work, please reply with your entire source.
Seth
P.S. Also, if you have time, you may want to get an i2c library to use if your software falls short of setting up your own i2c library. They have smbus2 you can install with pip and other i2c libraries out there still.
Here are a few things you should check (in random order).
List all I2C buses wich i2cdetect -l and try them all. Depending on the platform, the i2c bus number in Linux may be different from the peripheral number used in the datasheet and pinout. E.g. "I2C2" might be bus i2c-1 or i2c-3 in Linux).
Use an oscilloscope or logical analyzer to see if the SCL and SDA lines are being driven. If they aren't check the bus number as above. If they are, then check whether the device gives an ACK; if it doesn't, anything else will never work: double-check the chip slave address. There are cheap logical analyzers that you can buy and user with pulseview.
Simply load the Linux driver for your chip (see the kernel docs on how to do it from userspace for a quick test). Then see check if the device appears or use dmesg to see any kernel error messages while probing.
Code below physically breaks nucleo boards. 2 so far.
ST links is unable to connect and boards are not detected.
first dead one was xncleo stm32f411re, another one is nucleo stm32f446re.
I'm a complete beginner and that is pretty much my first code.
and 2 boards dead;) The question is why it may happen? or can one reset the board harder that normal jumper reset
int main()
{
RCC->AHB1ENR = (1<<0);
GPIOA->MODER = (1<<5);
while(1)
{
GPIOA->ODR |= (0<<5);
}
}
This is similar to this question ->
https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming
, answer to which helped me to restore the board, however answers to my problem in this thread are also very helpfull.
some pins used for debugging need to have some settings. if you change those settings the debugger cannot connect anymore. you need to set the debugger to connect under reset when the debug pins are in the initial corrct state. stm32 processors cannot be bricked this simple way.
so not listen to the advices that you need to use crappy STM libraries. just only set the pins you use, not the whole port.
Yes, your problem is with the line "RCC->AHB1ENR = (1<<0);". That enables power to GPIOA, but disables power to the other GPIOs (B,C,D,E, and H on the F411), which includes the SWD pins.
Edit:Reseting problem solved here: https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming
the reason problem occured solved below
Ok, it doesn't physically break the board. Needed hard reset - shorting rst and sb11 pins on nucleo stm32f446re. didn't try on xnucleo yet.
User P__J__ got it right in the comment. I'll cite:
just do not assign to the moder. use |= or &= instead – P__J__
Done.
And the fixed code:
int main()
{
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN;
GPIOA->MODER |= GPIO_MODER_MODE5_0;
while(1)
{
GPIOA->ODR |= GPIO_ODR_OD5;
}
}
I am working with STM32H743, and I want to use Pin no. 89 as DAC output. Is there any register setting where I can change PA4 to PG4(89).
I tried replacing PA4 to PG4 in a working example code, but the output still comes on PA4.
I don't know which STM32F7 you are using exactly so I could not lock at the Reference Manual, but I guess it is the same as on STM32F4 devices:
The answer is quite simple:
NO, you could not reroute the DAC pins.
(A look ad a randomly chosen F7 datasheet also shows only one pin for the DACs)
I simply guess it is not possible to route the output signal through a multiplexer without generating to much interference.
According to the H753 datasheet (can't find a specific one for H743), there are two DAC channels, PA4 is DAC1_OUT1 and PA5 is DAC1_OUT2. It does not appear to be changeable.
I have a sensor with the interrupt output connected to a input pin on my RaspberryPi. My goal is to trigger an event from the sensor interrupt. The data sheet for my sensor says that once an interrupt is triggered on the sensor, the interrupt status register will have the appropriate bit set to 1 and stay that way until it is cleared; while the status register has a status bit of 1, the interrupt pad on the sensor will be pulled down.
My problem is that I can see the status register correctly reflect an interrupt when I physically trigger the sensor. But when I read the pin from my Pi, I never see any change reflected. Here's the gist of my code:
import Sensor
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setup(11, GPIO.IN, pull_up_down = GPIO.PUD_UP)
s = Sensor.start()
while True:
print 'sensor int reg: ', s.readIntReg() # I do not clear interrupt
print 'pin value: ', GPIO.input(11)
The first print will change according to my interaction with the sensor as expected. The second print shows the pin holds 1 or 0 depending on whether it is set to pull up or down, respectively.
It seems like the problem lies in that whenever the interrupt fires, the sensor is pulling the pin down and the Pi is pulling it up... How should I handle this?
The sensor is the VCNL4010 [https://www.adafruit.com/products/466]
I suppose you have the gpio driver installed and active on the Pi?
Then you'll probably never see the interrupt triggering from the Python level since the kernel driver will service it (and reset the flag) already in the background.
I added a 10k external pull-up resistor with 3.3V and that did the trick... not sure why the internal pull-up on the Pi didn't do the same, perhaps I configured it wrong.
UPDATE: That turned out not to be the issue at all. I was neglecting to explicitly set the sensor to free run mode. Part of my code had the unintended side effect of setting that mode so in tweaking things for test sometimes it worked. The pull-up on the Pi works fine.