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
Related
I have ordered the black pill ( STM32F411CEU6, real ones ) to replace my blue pill dev kits that didn't have enough RAM and have had nothing but issues getting it going. I have generated the project using STM32CubeIDE.
I'm using A11, 12, 13 for GPIO output and PB9, 8 for I2C communication, and A10, 11 for my USART device.
I am able to get the st link programmer and software to detect my black pill and debug for a short duration until I enter MX_GPIO_Init()
After this the programmer loses communication with the device and prevents me from doing any real programming. Some places I have looked says to try to set the Sys -> Debug setting to "Serial Wire" but this is disabled by default for me and am unable to switch it.
In context of debugging when I do debug in live mode I can see a debug enabled
Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
InitWhile : Enabled
So the debugging looks like it's set up properly but I just don't understand why it can't call the init for the GPIO from looking at the debug console I get this
handle_vCont_c, Failed continue thread
which is thrown after entering this function
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
which doesn't make a whole lot of sense to me as I have not seen this before, can someone please help me out setting up this project properly? thanks.
The serial wire debug interface is defined for PA13 and PA14. In CubeMx IDE, first set SYS->Debug->Serial Wire. Select another pin for GPIO instead of PA13.
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.
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.