I am working on a firmware project using ESP-WROOM-02 and a modified custom board with an ESP-WROOM-02 on it. On the custom board, I have pin IO16 connected to a hardware ON/OFF subcircuit and therefore I have to set pin IO16 in GPIO/OUTPUT mode.
However, I cannot find a declaration for pin IO16 in ESP8266 RTOS SDKS's pin_mux_register.h and I cannot set up this pin. Why is pin IO16 excluded from the ESP8266 RTOS SDK? Here is a partial schematic with pin IO16 labeled as FAN:
The pin is badly commented in ESP8266 RTOS SDK and other documentation, however, I've managed to set it up via:
void ICACHE_FLASH_ATTR gpio16_output_conf(void)
{
WRITE_PERI_REG(PAD_XPD_DCDC_CONF,
(READ_PERI_REG(PAD_XPD_DCDC_CONF) & 0xffffffbc) | (uint32)0x1); // mux configuration for XPD_DCDC to output rtc_gpio0
WRITE_PERI_REG(RTC_GPIO_CONF,
(READ_PERI_REG(RTC_GPIO_CONF) & (uint32)0xfffffffe) | (uint32)0x0); // mux configuration for out enable
WRITE_PERI_REG(RTC_GPIO_ENABLE,
(READ_PERI_REG(RTC_GPIO_ENABLE) & (uint32)0xfffffffe) | (uint32)0x1); //out enable
}
taken from IoT Demo GPIO16.c implementation file.
Related
How to get RI pin status of serial port on a windows platform? I want to read the current state (ON or OFF) , when i get a call on a modem
I can set the DTR pin with :
EscapeCommFunction(hSerial,SETRTS);
But cant find an answer online on how to check the RI pin STATUS
You have to use GetCommModemStatus function.
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.
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.
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.
I'm stuck with configuration bits with PIC16F1947. I'm new to PIC programming so please answer in details.
I've the following setup:
MPLAB 8.46
MPLAB ICD 3
HI-TECH C Compiler 9.81
A PIC16F1947 PIM (Plug in module) is plugged on PICDEM LCD 2 Demo Board. The board is powered by 3 V battery and J15 jumper was connected according to the manual (1-3 connected, 2-4 connected on J15). The project is compiled as debug build.
Following are the configuration bits used:
// Configuration word 1
__CONFIG( FOSC_INTOSC & // INTOSC oscillator: I/O function on CLKIN pin
WDTE_OFF & // WDT disabled
PWRTE_OFF & // PWRT disabled
MCLRE_OFF & // MCLR/VPP pin function is digital input
CP_OFF & // Program memory code protection is disabled
CPD_OFF & // Data memory code protection is disabled
BOREN_OFF & // Brown-out Reset disabled
CLKOUTEN_OFF & // CLKOUT function is disabled. I/O or oscillator function on the CLKOUT pin
IESO_OFF & // Internal/External Switchover mode is disabled
FCMEN_OFF // Fail-Safe Clock Monitor is disabled
);
// Configuration word 2
__CONFIG( WRT_OFF & // Write protection off
VCAPEN_OFF & // VCAP pin functionality is disabled
PLLEN_OFF & // 4x PLL disabled
STVREN_OFF & // Stack Overflow or Underflow will not cause a Reset
BORV_19 & // Brown-out Reset Voltage (VBOR) set to 1.9 V
LVP_OFF // High-voltage on MCLR/VPP must be used for programming
);
I can program (burn firmware) the micro via MPLAB. But when I try to Debugger > Run it, the output windows shows following error:
ICD3Err0040: The target device is not
ready for debugging. Please check your
configuration bit settings and program
the device before proceeding.
I've checked the documentation about ICD3Err0040 but it seems to me that everything is alright.
What I'm doing wrong? Please help.
I've upgraded MPLAB IDE from 8.46 to 8.63 and debugging started to work!!!
May be they had issue with previous version.
IN CONFIG WORD 1 WRITE:- ICS_PGx2 SHOULD WORK
Debugger>Program
Invokes the msg box shown above.
Click [ok] and the IDE will modify the configuration bits appropriately to permit debugging.
For those who cannot see the pic shown above.
Single -Supply ICSP Enable bit must disabled
Watchdog Timer Enable bit must be disabled