I want to pass sine wave data onto a pin (any possible one), so that my program would be able to read it when being run in an emulator.
How how can I pass data in the form of (time:value) or just pass a function float generatorForPinX(int time); to act as signal generator into the GNU ARM Eclipse (I use QEMU but if any other emulator is required I am willing to migrate) board emulator?
These instructions are for emulating an Olimex STM32 P103 Development Kit.
Download and build
First download and build Qemu STM32, which includes patches for emulating the ADC peripheral on the STM32:
wget https://github.com/beckus/qemu_stm32/archive/stm32.tar.gz
tar xf stm32.tar.gz
cd qemu_stm32-stm32
./configure --target-list="arm-softmmu"
make
cd ..
If the configure step fails, then install the missing requirements. See the README for more information.
Then download the Olimex STM32 P103 Development Kit Demos:
wget https://github.com/beckus/stm32_p103_demos/archive/master.tar.gz
tar xf master.tar.gz
Look in stm32_p103_demos-master/demos/adc_single/main.c for an example program which uses the ADC.
Run the demo application
To build and run the adc_single demo:
cd stm32_p103_demos-master
QEMU_ARM_DIR=../qemu_stm32-stm32/arm-softmmu/ make adc_single_QEMURUN_TEL
(from another terminal) telnet localhost 7777
UART2 is attached to the telnet server on port 7777, which you should see output from. See the README for more information on how to build and run the demo applications.
Looking at the source for the adc_single demo application, it has 3 different modes:
Mode 1 (the default) will read from the temperature sensor on ADC channel 16
Mode 2 will read the Vdd value from ADC channel 16
Mode 3 will read from ADC channel 8.
The modes can be selected by using a button, but since we are emulating the hardware with QEMU, the button is not available. I switched between the modes by changing the int mode = 1; value and recompiling the program.
ADC emulation
The method that QEMU uses to emulate each ADC channel is viewable in the stm32_adc_start_conv function in hw/arm/stm32_adc.c:
static void stm32_adc_start_conv(Stm32Adc *s)
{
uint64_t curr_time = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
int channel_number=stm32_ADC_get_channel_number(s,1);
// Write result of conversion
if(channel_number==16){
s->Vdda=rand()%(1200+1) + 2400; //Vdda belongs to the interval [2400 3600] mv
s->Vref=rand()%(s->Vdda-2400+1) + 2400; //Vref belongs to the interval [2400 Vdda] mv
s->ADC_DR= s->Vdda - s->Vref;
}
else if(channel_number==17){
s->ADC_DR= (s->Vref=rand()%(s->Vdda-2400+1) + 2400); //Vref [2400 Vdda] mv
}
else{
s->ADC_DR=((int)(1024.*(sin(2*M_PI*qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL)/1e9)+1.))&0xfff);
}
s->ADC_SR&=~ADC_SR_EOC; // jmf : indicates ongoing conversion
// calls conv_complete when expires
timer_mod(s->conv_timer, curr_time + stm32_ADC_get_nbr_cycle_per_sample(s,channel_number));
}
As you can see, ADC channel 16 will emulate a random Vdd input, ADC channel 17 will emulate a random temperature input, and all other channels will follow a sine wave from 0 to 2048. Here is a graph of the ADC values returned from all 3 modes:
If you want to have an ADC channel use a different emulation pattern, you can modify stm32_adc_start_conv and rebuild QEMU following the steps above.
Related
I have a nucleo-144 board with stm32f746zg MCU. I'm trying to program the board with openocd, using gnu make and the makefile generated from stm32cubemx. I've added following line to my makefile to automate the flashing process:
flash: all
openocd -f interface/stlink.cfg -f target/stm32f7x.cfg -c "program $(BUILD_DIR)/$(TARGET).elf verify reset exit"
The code compiles without any problem and when I type make flash in the terminal the result is:
❯ make flash
openocd -f interface/stlink.cfg -f target/stm32f7x.cfg -c "program build/my-board.elf verify reset exit"
Open On-Chip Debugger 0.11.0 (2021-11-18) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : DEPRECATED target event trace-config; use TPIU events {pre,post}-{enable,disable}
Info : clock speed 2000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : STLINK V2J33M25 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.236769
Info : stm32f7x.cpu: Cortex-M7 r0p1 processor detected
Warn : Silicon bug: single stepping may enter pending exception handler!
Info : stm32f7x.cpu: target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f7x.cpu on 3333
Error: couldn't bind gdb to socket on port 3333: No error
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08002a18 msp: 0x20050000
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
** Programming Started **
Info : device id = 0x10016449
Info : flash size = 1024 kbytes
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
shutdown command invoked
But the program doesn't run on the board and there's no blinking. I tried this in windows and wsl ubuntu. In both cases the results are the same. Also tried loading the binary file instead of .elf but again no luck.
Can somebody tell me what am I doing wrong here?
Ok. I'm not sure if I should post this as an answer, but the problem wasn't either openocd or the broken hardware.
When I started the project in cubemx, I initialized the default nucleo-f746zg peripherals and for some reason (probably one of the peripherals need higher clock frequency to work properly) in clock configuration the default clock source is selected as HSE and this option cannot be changed. On the other hand the nucleo board doesn't come with an external oscillator and it should be soldered by the user. So after generating the code and flashing it to the board it causes an error and the program doesn't run. Although, I think there was a block of code in clock configuration of HAL libraries that would "try" to use HSE and PLL as clock source and in case of not responding or any problem in settings, the HSI would be used as default source.
Anyway when I start the project from MCU selector in cubemx and don't use nucleo initializations, I can set the clock to HSI and everything works fine.
I am trying to create an application that will stream audio with Darkice as well as provide a LED VU meter indication of the audio stream.
I have created a virtual card with . This card is recognized by alsamixer, aplay, and arecord but I can not transfer the line-in signal from the usb card (hw:0,0) to the dummy card (hw:2,0).
I have tried several .asoundrc scripts that I found both in your Q&A as well as Google using alsa dmix, dsnoop, and multi but nothing has worked so far.
I am presently using one python program (LED_VU.py) that autostarts in one terminal, and the second python program containing Darkice (streamer.diDual.py) in a second terminal. The configuration portion of the LED program is:
### LED VU Meter on RPI ###
#!/usr/bin/env python
import alsaaudio as AA
import audioop
from time import sleep
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setwarnings(False)
#Define physical header pin numbers for 10 LEDs
RPiPins=[11,12,13,15,16,18,22,7,3,5]
#set all pins as output
for pin in RPiPins:
GPIO.setup(pin, GPIO.OUT)
#Set up audio
card = 'hw:0,0'
The configuation portion of darkiceDual.cfg is:
# Darkice Configuration File - Generated by Streamer
[general]
duration = 0 # duration of encoding, in seconds. 0 means forever
bufferSecs = 5 # size of internal slip buffer in seconds
reconnect = yes # reconnect to server if disconnected
[input]
device = hw:2,0 # alsa usb soundcard device for audio input
sampleRate = 44100 # sample rate in Hz
bitsPerSample = 16 # bits per sample
channel = 2 # channels. 1 = mono, 2 = stereo
My .asoundrc file is:
pcm.!default {
type plug
slave.pcm "mdev"
route_policy "duplicate"
}
pcm.mdev {
type multi
slaves.a.pcm "hw:0,0"
slaves.a.channels 2
slaves.b.pcm "dmixer"
slaves.b.channels 2
bindings.0.slave a
bindings.0.channel 0
bindings.1.slave a
bindings.1.channel 1
bindings.2.slave b
bindings.2.channel 0
bindings.3.slave b
bindings.3.channel 1
}
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:2,0"
period_time 0
period_size 1024
buffer_size 4096
rate 44100
channels 2
format S16_LE
}
}
What am I doing wrong?
The streamer will have no audio if I use hw:2,0 and have the 'Can not connect' error if I use hw:0,0 (LED_VU.py is using this). If I change the card setting of the LED program to hw:2,0 the LEDs will lockup with all of them lit.
Any help is appreciated!
Thank you for the help. The two programs both use the usb line-in as expected.
I am not able to use alsamixer or amixer now. Pulseaudio is causing the problem now. If it is installed, the LED_VU.py program will not run. When it is uninstalled, the python programs will run but not alsamixer.
Apparently, you want to run the VU meter and DarkIce from the same audio data, i.e., you need to allow two programs to share one recording device.
This can be done with the dsnoop plugin. Which is enabled by default for USB devices.
Tell both programs to record from the device default. If that was redefined, try dsnoop:0 instead.
Just off the bat I'd like to state that I'm aware of Python and other high level implementations for manipulating GPIO on the Raspberry PI. I've also been using the WiringPI C API and am experiencing problems with it on Raspbian Jessie that I was not having on Raspbian Wheezy even though I have not changed a single line of code. Also the WiringPI C API developer says he has no immediate plans to support Raspbian Jessie so I'm kind of up a creek without a paddle.
For this reason I've been reading the following tutorial (among others) on accessing Raspberry PI GPIOs using sysfs since this seems to be one way of addressing GPIO without using WiringPI and without writing my own GPIO library:
http://www.hertaville.com/introduction-to-accessing-the-raspberry-pis-gpio-in-c.html
According to this tutorial, to set GPIO17 as an input, you write the string 'in' to the file handle:
/sys/class/gpio/gpio/17/direction
...and then I can read GPIO input values from:
/sys/class/gpio/gpio17/value
This is all well and good but I do not have the option of retro fitting pull-up resistors to my production boards. Is it possible to set the Raspberry PI's built in pull-up and pull-down resistors using sysfs?
Also, if setting the pull-up and pull-down resistors via sysfs is not possible am I correct in assuming that even in the latest Raspbian Jessie the only other way to do this is write directly to GPIO registers? i.e. even in Raspbian Jessie there is no official C API for GPIO programming?
You can use a device-tree overlay to activate the pull-ups and port direction at boot up.
You will have to modify and compile the dts (source), place it in /boot/overlays, and enable it in config.txt. The instructions are in the source header. (Thanks to PhillE for his help!)
/*
* Overlay for enabling gpio's to pull at boot time
* this overlay uses pincctrl to initialize the pull-up register for the the listed gpios
* the compatible="gpio-leds" forces a module probe so the pinctrl does something
*
* To use this dts:
* copy this to a file named gpio_pull-overlay.dts
* modify the brcm,pins, brcm,function, and brcm,pull values
* apt-get install device-tree-compiler
* dtc -# -I dts -O dtb -o gpio_pull-overlay.dtb gpio_pull-overlay.dts
* sudo cp gpio_pull-overlay.dtb /boot/overlays
* add this line to the end config.txt: dtoverlay=gpio_pull
* reboot
*/
/dts-v1/;
/plugin/;
/ {
compatible = "brcm,bcm2835", "brcm,bcm2708";
fragment#0 {
target = <&gpio>;
__overlay__ {
gpio_pins: gpio_pins {
brcm,pins = <30 31 32 33>; /* list of gpio(n) pins to pull */
brcm,function = <0 1 0 1>; /* boot up direction:in=0 out=1 */
brcm,pull = <2 0 1 0>; /* pull direction: none=0, 1 = down, 2 = up */
};
};
};
fragment#1 {
target-path = "/soc";
__overlay__ {
gpiopull:gpiopull {
compatible = "gpio-leds";
pinctrl-names = "default";
pinctrl-0 = <&gpio_pins>;
status = "okay";
};
};
};
__overrides__ {
gpio_pull = <&gpiopull>,"status";
};
};
user1967890's solution worked fine for me until about May 28 or 29 of 2020, then I did an apt update/upgrade and I believe there was a Raspberry Pi kernel upgrade, after which this stopped working. In any case I had to resort to using a Python solution. So I now use the following at bootup to set the pullup resistors on GPIO pins 17 and 18, and to make sure that neither the pullup nor pulldown resistors are set on GPIO 22 through 25. And yes I realize this code could be shortened by using a loop to set GPIO_PIN_NUMBER, but it only runs once at bootup, so I am not too worried about it.
#!/usr/bin/python
import RPi.GPIO as GPIO
GPIO_PIN_NUMBER=17
GPIO.setmode(GPIO.BCM)
GPIO.setup(GPIO_PIN_NUMBER, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO_PIN_NUMBER=18
GPIO.setmode(GPIO.BCM)
GPIO.setup(GPIO_PIN_NUMBER, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO_PIN_NUMBER=22
GPIO.setmode(GPIO.BCM)
GPIO.setup(GPIO_PIN_NUMBER, GPIO.IN, pull_up_down=GPIO.PUD_OFF)
GPIO_PIN_NUMBER=23
GPIO.setmode(GPIO.BCM)
GPIO.setup(GPIO_PIN_NUMBER, GPIO.IN, pull_up_down=GPIO.PUD_OFF)
GPIO_PIN_NUMBER=24
GPIO.setmode(GPIO.BCM)
GPIO.setup(GPIO_PIN_NUMBER, GPIO.IN, pull_up_down=GPIO.PUD_OFF)
GPIO_PIN_NUMBER=25
GPIO.setmode(GPIO.BCM)
GPIO.setup(GPIO_PIN_NUMBER, GPIO.IN, pull_up_down=GPIO.PUD_OFF)
Obviously if I had wanted to pull a GPIO pin down I could have used GPIO.PUD_DOWN rather than GPIO.PUD_UP. I did not have to install anything that wasn't already present on my Raspberry Pi, although it's possible that something might have been installed during a previous software setup that would not be present on a brand new install of Raspbian.
This question may be so obvious it is stupid but I am failing to come up with an answer for it.
I am trying to make a simple makefile project for the sam4s xplained board from Atmel.
I am new to ARM and am feeling a bit lost in how to get stuff to work. Here is what I do trying to get the LEDs to work:
/* Enable clock for PIOC. */
PMC->PMC_WPMR = PMC_WPMR_WPKEY_PASSWD;
PMC->PMC_PCER0 = PMC_PCER0_PID13; /* PIOC clock enable. */
/* Enable output for LED. */
PIOC->PIO_WPMR = PIO_WPMR_WPKEY_PASSWD; /* Enable writing to registers. */
PIOC->PIO_PER = PIO_PER_P10 | PIO_PER_P17; /* Enable pio 10, 17. */
PIOC->PIO_OER = PIO_OER_P10 | PIO_OER_P17; /* Set pio10 and 17 as output. */
PIOC->PIO_SODR = PIO_SODR_P10; /* Set pio10. */
PIOC->PIO_CODR = PIO_CODR_P17; /* Clear pio17 . */
But absolutely nothing happens. Am I missing something?
There should be user LEDs at PIOC 10 and 17.
Board schematics:
http://www.atmel.com/webdoc/sam4s16xplained/sam4s16xplained.boardScematics.section_ggo_tyg_xf.html
The problem was not in the code but in Atmel's tools used to program the board. I had been using SAM-BA In-system Programmer to program the board but for some reason it failed to change the contents of the flash. Even setting a single manually in the memory view fails.
I instead tried Seggers JLink software and did the following steps:
Update the JLink driver on the board using Atmel Studio 6 (this step requires windows).
Downloaded the J-Link software package for Linux from Segger: https://www.segger.com/jlink-software.html.
Using JLinkExe to program the board, like so:
Make sure JP25 is disconnected - only needed for sam-ba.
Connect via usb with the jtag connector.
Start JLinkExe
In the JLink terminal do:
JLink> device at91sam4s16c
JLink> loadbin <target.bin>, 0x400000
Sometimes I need to reset the board before it works after programming it. Using the Segger tools debugging also works now. Start gdb server with JLinkGDBServer and connect with arm-none-eabi-gdb using:
(gdb) target remote :2331
(gdb) file <target.elf>
The STM32F2 micro-controller has build in capabilities to prevent readout of application code using a debug interface. It works fine and is accomplished pretty easily by configuring the read protection(RDP) level to '1' (!0xAA || !0xCC) or '2' (0xCC which is irreversible). Except trying to turn it off is where i run in to issues.
The expected behavior when the RDP level is lowered back to 0:
The chip will perform a mass flash erase.
Followed by clearing the protection flag.
System reset
Except after a power cycle the flash has been successfully erased but the protection flag remains on level '1' (0x55) keeping the debug interface disabled. And thus preventing me from writing any new application code. It is possible to fiddle around with the debugger and force the flag to level 0 (0xAA) manually though..
Is there anyone who have had the same or similar issues with the STM32F2xx series that can help me out? I'm using the STM32 standard peripheral drivers for programming the flash.
Enable
// Enable read out protection
FLASH_OB_Unlock();
FLASH_OB_RDPConfig(OB_RDP_Level_1);
FLASH_OB_Launch();
FLASH_OB_Lock();
// Restart platform
NVIC_SystemReset();
Disable
// Disable read out protection
FLASH_OB_Unlock();
FLASH_OB_RDPConfig(OB_RDP_Level_0);
FLASH_OB_Launch();
FLASH_OB_Lock();
// Restart platform
NVIC_SystemReset();
This is because before the clearing the protection flag, and in the middle of mass flash erase, you restart the chip.
The only way to recover the chip is to use the system bootloader.
Force boot0 pin to be 1 and force boot1 pin to be 0 at power up, start bootloader then connect USB and program the chip with DFU programmer.
You can download the DFU programmer here.
I used the library as follows (it was not working without FLASH_Unlock();):
// Flash Readout Protection Level 1
if (FLASH_OB_GetRDP() != SET) {
FLASH_Unlock(); // this line is critical!
FLASH_OB_Unlock();
FLASH_OB_RDPConfig(OB_RDP_Level_1);
FLASH_OB_Launch(); // Option Bytes programming
FLASH_OB_Lock();
FLASH_Lock();
}
No need for NVIC_SystemReset();.
Checking functionality worked best with STM32 ST-LINK utility CLI for me:
> "C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility\ST-LINK_CLI.exe" -c SWD -rOB
STM32 ST-LINK CLI v3.0.0.0
STM32 ST-LINK Command Line Interface
ST-LINK SN : 51FF6D064989525019422287
ST-LINK Firmware version : V2J27S0
Connected via SWD.
SWD Frequency = 4000K.
Target voltage = 2.9 V.
Connection mode : Normal.
Device ID:0x422
Device flash Size : 256 Kbytes
Device family :STM32F302xB-xC/F303xB-xC/F358xx
Option bytes:
RDP : Level 1
IWDG_SW : 1
nRST_STOP : 1
nRST_STDBY : 1
nBoot1 : 1
VDDA : 1
Data0 : 0xFF
Data1 : 0xFF
nSRAM_Parity: 1
WRP : 0xFFFFFFFF
Not really a solution, but I hope this saves someone some time.