Raspberry Pi GPIO stops working after some time - raspberry-pi

when using the GPIO library on the Raspberry PI and having an example code like this:
while True:
GPIO.setup(21, GPIO.OUT)
pwm = GPIO.PWM(21, 50)
pwm.start(0)
for i in range(0, 101, 2):
pwm.ChangeDutyCycle(i)
time.sleep(0.03)
for i in range(100, -1, -2):
pwm.ChangeDutyCycle(i)
time.sleep(0.03)
pwm.stop()
GPIO.cleanup(21)
time.sleep(1)
The code might stop suddenly after a while. No error, just no changes via pwm are recognized any longer. Anyone got an idea why this is?

This issue has been mentioned here in the old sourceforge repo:
https://sourceforge.net/p/raspberry-gpio-python/tickets/111/
https://sourceforge.net/p/raspberry-gpio-python/tickets/94/
Its because the GPIO library by default creates a new pthread for every call without cleaning up afterwards, but the number of threads might be limited to a number of 250 or so.
I created a fork of this repo (https://github.com/wuestkamp/raspberry-gpio-python) which solves this and contains instructions on how to use this on your PI.

Related

STM32 CDC_Receive_FS callback never called

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

Can't receive from USB bulk endpoint despite Windows enumerates and libusb reads descriptor of STM32 custom device class

For a fast ADC sampling USB device, I am using the USB 2.0 High Speed capable STM32F733 with the embedded USB-HS PHY. In USBView, I can see that the device is enumerated, the libusb code opens the device and claims interface, but when I try to receive data with libusb_bulk_transfer, the operation times out (return code -12). Things I have tried: I have confirmed than when I request data with libusb_bulk_transfer, the device is interrupted. Note: I have DMA enabled in my class configuration C file and it is not clear to me how that is triggered. I have verified that the transfersize and packet count registers are being set correctly by the LL library function, and that when I request data from
Any tips on debugging such problems will be much appreciated - this board is my undergrad thesis due in under two months!
Desktop sequence:
libusb_get_device_list, libusb_get_device_descriptor, libusb_open, libusb_get_string_descriptor_ascii, libusb_free_device_list, libusb_bulk_transfer(devh, fat_EPIN_ADDR, inframe, fat_EPIN_SIZE, &gotBytes, 100). Where gotBytes is integer, and inframe is a large array.
Device firmware:
MX_USB_DEVICE_Init();
uint8_t txBuffer[10*fat_EPIN_SIZE];
while (1)
{
USBD_LL_Transmit(&hUsbDeviceHS, Custom_fat_EPIN_ADDR, txBuffer, Custom_fat_EPIN_SIZE);
HAL_Delay(1);
}
Custom_fat_EPIN_SIZE is 0x200 and the endpoint address is 0x81 (EP IN 1)
Installed driver for device is WinUSB (verified in Device Manger to be winusb.sys), and I am linking libusb-1.0 into my desktop program. You can find my source code at https://gitlab.com/tywonemi-school-stuff/silicon-radar-fun, the firmware is My SW/v1 and the desktop software is a Qt Creator project in My SW/Viewer, of note is usb.cpp. You can also compare with testing project/HIDTest, which is code that I tested with STM32F303 nucleo dev board where I was able to read an array through IN bulk endpoint with the Viewer application. However, F3 has the USB peripheral, while F7 has OTG_USB, and I am now attempting USB 2.0 compliant HS so there may be more protocol-based pitfalls. You can also find the output of the device descriptor etc from USBView in my SW/USBView_broken.txt
EDIT 1: I have found finally some concrete error in the STM32 behavior. The DMAADDR is set for EPIN 0x81, and never increments, despite the DMA being enabled. I have went through literally every occurrence of the word "DMA" in the USB_OTG periphery.
I thought it might be that my linker script makes my array be stored in DTCM or similar, and the OTG DMA can't access it, but the address of txBuffer is 0x2003EBEC which is in SRAM2. The AHB matrix in the reference manual clearly shows, that the USB OTG HS DMA is master for a bus that SRAM2 is a slave of. And DTCM is connected too. I will look for application notes for USB OTG HS DMA - it just seems to be refusing to copy data!
I have fixed my issue by disabling the DMA setting. I have re-read the relevant portions of the reference manual and still don't know how exactly the values propagate into the Tx FIFOs. It is possible that DMA-less operation will be a major bottleneck in my project, I might return to this later.

Beagle Bone Black I2C2 Issues

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.

LPUART1 not working on STM32L476 (based on VisualGDB)

Hi I am developed a board based on the Discovery L476 board (STM32L476VGT6) using MBED and after porting it to VisualGDB everything works great. The only thing that doesn't work is LPUART1. I hooked it to PB10(LPUART1_RX), PB11(LPUART1_TX) but whenever I declare the port in my code and download it, the program hangs and doesn't even start:
Serial RS232(PB_11, PB_10);
If I remove this line, the code works great (but I can't use this port)
I changed the pin definitions in PeripheralPins.c so PB10 and PB11 will function as the LPUART TX and RX pins: (I added the lines)
const PinMap PinMap_UART_RX[] = { {PB_10, LPUART_1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF8_LPUART1)},
//
const PinMap PinMap_UART_TX[] = { {PB_11, LPUART_1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF8_LPUART1)},
but it still doesn't work. Any ideas?
See https://github.com/ARMmbed/mbed-os/issues/5389, the baud rate needs to be set at [sys_clk / 4096 ... sys_clk / 3]. Sys clock on this device is running at 80MHz. You could fix it in the HAL for this board until a real fix is deployed.

Problems using a MCP3008 and a MCP23S17 on SPI with WebIOPi

I'm very new to WebIOPi and I'm trying my first tests. First of all I apologize for my english.
I'm trying to get to work a RPi with a MCP3008 on CE0 and a MCP23S17 on CE1 with SPI bus.
My problem is that devices only work when connected on CE1 (so, when 23017 is on CE0 I am not able to set pins to be inputs or outputs and to set it on 1 or 0, but 3008 is on CE1 and I see its levels changing. When - vice versa - 23017 is on CE1 it is fully functional, but 3008 outputs stay still).
Due to this, I think it is not an hardware issue (I don't have much expertise in electronics, but luckily I don't build my circuits by myself :) ), I think it is a problem in WebIOPi config. Here is my WebIOPi config:
[DEVICES]
mcp1 = MCP23S17 chip:1 slave:0x27
adc0 = MCP3008 chip:0
I only added these two lines to my config file.
I did not touch anything else of my original WebIOPi installation.
In this case (adc0 fully functional, mcp1 not working), when loading the WebIOPi devices monitor I see adc0 levels working good and mcp1 pins randomly changing between being a input and an output and from 0 and 1.
May it be a config error?
Use python and spidev module instead! Look my answer on another thread for function for the mcp3008 chip.