How can i switch on the LED on PA2 GPIO (STM32F103C8T6), using standard registry configuration.
RCC-> APB2ENR |= (1<<2);
GPIOA->CRL |= (1<<9);
GPIOA->ODR |= (1<<3);
Does not work for me. Could you please advice where i make mistake?
As per the reference manual, the GPIOA CRL registers resets as 0x4444 4444 (See section 9.2.1 of the reference manual).
When you execute the following command:
GPIOA->CRL |= (1<<9);
you are setting the MODE bits of PA2 to 10 (Output mode, max speed 2 MHz). But due to the inital register initialization, the CNF2 bits are 01, which is open-drain configuration. You should initialize PA2 with the following instead
GPIOA->CRL &= ~(0b0000<<8);
GPIOA->CRL |= (0b0010<<8);
This ensures that both MODE2 and CNF2 are both set so the pin acts as an output with a push-pull configuration
Related
Summary:
I've configured a GPIO as an interrupt. I can see from all of the registers that it appears to be triggering, but my interrupt routine is never called.
Details:
I'm using a Nucleo F446 board, and the documentation specifies that PC13 should be the input for the push button. I'd like to trigger an interrupt when this happens (I know that this isn't the best way to handle a button; I was having trouble with a more complex system and reduced it to this simplified example). I'm doing this on bare metal and not using any existing libraries.
PC13 comes into EXTI13:
I see that this is interrupt #40 from the microcontroller reference manual:
I'm configuring the microcontroller as follows (using pseudo-c here for simplicity):
Enable clocks for GPIOC block, SYSCFG
RCC_AHB1ENR |= GPIOC_EN
RCC_APB2EN |= SYSCFG_EN
Enable external interrupts for GPIO C13 (it is by default an input)
SYSCFG_EXTICR4 |= (PCx << 4)
Set pin 13 of the interrupt mask, event mask, and rising trigger selection registers:
EXTI_IMR |= 1 << 13
EXTI_EMR |= 1 << 13
EXTI_RTSR |= 1 << 13
Enable IRQ 40
NVIC_ISER1 |= 1 << 8
Set up interrupt vector (here is a disassembly)
08000000 <_reset-0x124>:
...
80000e0: 08000621 .word 0x08000621
08000620 <exti15_10_handler>:
8000620: 4906 ldr r1, [pc, #24] ; (800063c <exti15_10_handler+0x1c>)
I have the main code in a loop printing a number of register values, which I will describe in a moment, to the serial port. I've implemented exti15_10_handler to turn on an LED and go into an infinite loop, so I should know when it is called, because it will also stop the printing. When I press and release the button, I see the following:
In GPIOC_IDR (the GPIO input register), I can see bit 13 change, which tells me the GPIO block is working.
In EXTI_PR (external interrupt pending), I see the value of bit 13 switch from 0 to 1 and stays there.
In NVIC_ISPR1 (interrupt set pending), bit 8 (corresponding to interrupt 40) switches from 0 to 1 and stays there.
However, NVIC_IABR0 (interrupt active bit register) does not change.
Interrupt is not called, as I see no change in the LED and the board does not hang.
I'm sure I'm forgetting to enable something, but after dredging through the reference manuals and a bunch of code examples, I'm just not seeing it. I did try the following:
asm volatile ("cpsie i" : : : "memory");
To set the interrupt flag (which I think should have been on already). I'm curious if this looks familiar to anyone.
This is a pretty unsatisfying result. While looking at the disassembly of the interrupt vector table, I noticed:
8000000: 20020000 .word 0x20020000
8000004: 08000124 .word 0x08000124
8000008: 08000595 .word 0x08000595
800000c: 08000595 .word 0x08000595
The second entry is supposed to be my reset vector
.section .interrupt_vector
.word _estack // Stack pointer
.word _reset
Although _reset is a thumb function, it is not encoded with the LSB set to indicate that. If I change the line to:
.word _reset + 1
...or put .thumb_func immediate before my reset handler in my startup code, it works correctly every time.
I'm trying to do a pretty basic 'get an LED' to blink tutorial with a Raspberry Pi Zero. Following this guide:
Blink: Making An LED Blink On A Raspberry Pi
I'm able to get the LED to turn on and off with the gpio command line utility, and the sample code for using RPi.GPIO works fine as well, but I can not get the GPIO Zero example to work.
from gpiozero import LED
from time import sleep
redLED = LED(21)
print "Press CTRL-C to exit."
try:
while True:
redLED.on()
sleep(0.5)
redLED.off()
sleep(0.5)
finally:
redLED.close()
print "\nCompleted cleanup of GPIO resources."
The code executes with no errors, but the LED doesn't blink. What things can I try to troubleshoot likely problems?
Since the command line and the RPi.GPIO examples work, I'm sure the LED and resistor are wired up correctly, so I'm not sure what to try next.
I am working on to enable Wandboard Quad(IMX6Q) Uart 2 features for to get data from GPIO3_26 and GPIO3_27 I enabled Uart2 from dts and recompiled imx6q-wandboard.dtb file ,it seems its working but
when I send the "hello" to ttymxc1 I m seeing the senseless charachters , even if I adjust same baudrate ttymxc1 and my machıne ttyUSB0 (I m using usb to rs232 converter ). I think I need to close some features but I dont know what is it or I need to make some configuration pinmuxing and ALT modes .
Is there any way to change the ALT modes of the features or when we choose the UART or another features it is enabling the dependent ALT Mode ?
Can you give me a suggestion or what Am I doing wrong ?
Must_ba
Today I was wondering why the GFlags option Stop on hung GUI appears in the Kernel Flags tab of the GFlags user interface. Does the kernel have a GUI which could hang?
So I tried to get some information from Microsoft, but MSDN just says:
The Stop on hung GUI flag appears in GFlags, but it has no effect on Windows.
So I wonder even more: a kernel flag for a kernel which has a GUI, but it's not the Windows kernel?
Although it seems not of practical use, can anyone explain this?
I also tried to get more information from WinDbg .hh !gflag, but it doesn't even give the statement that this won't work on Windows.
Kernel flag indicates flag takes effect immediately without requiring a reboot
Registry flag requires a reboot for the flags to take effect
the kernel does not have any gui that could hang.
the term windows doesnt mean kernel but the gui windows of the running application
check NtSetSystemInformation in your os to understand why 0x8 does not take effect
basically there are a few hardcoded magic numbers inside this api which tests each request for GlobalFlag changes and allows them or disallows them
in xp-sp3 this magic value is 0B2319BF0 so any flag that is < 0x10 will be disallowed
and stop on hung gui is 0x8 so it isnt effective and you cant set this from registry tab
so effectively no way of setting this flag
nt!NtSetSystemInformation+0x193:
80606009 8b03 mov eax,dword ptr [ebx] ds:0023:001285f8=00000008 <---- +shg
8060600b 25f09b31b2 and eax,0B2319BF0h < magic value in nt
80606010 8945a0 mov dword ptr [ebp-60h],eax ss:0010:fb569cf0=00000000
80606013 8b0d6c125580 mov ecx,dword ptr [nt!NtGlobalFlag (8055126c)] ds:0023:8055126c=00000000
80606019 81e10f64ce4d and ecx,4DCE640Fh <--another magic value both these magic values orred together
will be 0xffffffff covers the whole range of flags
8060601f 0bc1 or eax,ecx
80606021 8945a0 mov dword ptr [ebp-60h],eax ss:0010:fb569cf0=00000000
80606024 a36c125580 mov dword ptr [nt!NtGlobalFlag (8055126c)],eax ds:0023:8055126c=00000000
Here's my problem, I define a port list as so:
module spi_jstk (
input clk, // System Clock (40MHz)
input reset, // Async Reset
input START, // Initialize SPI Transfer
input [39:0] DATA, // Input Data to Transfer
input SS, // Chip Select
output SCLK, // Serial Clock
input MISO, // Master In Slave Out
output MOSI ); // Master Out Slave In
Looks quite nice.
Now lets say I add a new signal to this list or just hit TAB and this is what happens:
module spi_jstk (
input clk, // System Clock (40MHz)
input reset, // Async Reset
input START, // Initialize SPI Transfer
input [39:0] DATA, // Input Data to Transfer
input SS, // Chip Select
output SCLK, // Serial Clock
output NEW, // NEW SIGNAL
input MISO, // Master In Slave Out
output MOSI ); // Master Out Slave In
Not sure why it did this to my comments, anyone know how I turn off this? Its really frustrating.
Another thing I don't understand is that if I hit TAB on a list of regular signals (not in a port list) it doesn't mess with my comments. These comments stay aligned after tab.
// Signals
reg [2:0] q_state, n_state;
reg q_clk;
reg q_sck; //1 MHz ticks
reg [7:0] q_mosi; //1 MHz ticks
reg [7:0] q_miso; //1 MHz ticks
Anyone know how can I fix this? Thanks.
This seems to be a side-effect of auto-lineup behavior. The documentation of C-hvverilog-auto-lineupenter describes the behavior
Type of statements to lineup across multiple lines.
If 'all' is selected, then all line ups described below are done.
If 'declarations', then just declarations are lined up with any
preceding declarations, taking into account widths and the like,
so or example the code:
reg [31:0] a;
reg b;
would become
reg [31:0] a;
reg b;
If 'assignment', then assignments are lined up with any preceding
assignments, so for example the code
a_long_variable <= b + c;
d = e + f;
would become
a_long_variable <= b + c;
d = e + f;
However it seems in this process it deletes the extra spaces between the code and the comments, I could not find a way to keep it from messing up with comments (you may want to report a bug to its maintainers do M-xverilog-submit-bug-reportRET). One option might be to disable this behavior by customizing the variable verilog-auto-lineup. There are a couple of ways to do so
1) You can use emacs' customize UI for doing so. Just do M-xcustomize-variableRETverilog-auto-lineupRET. And select the desired value for the variable.
2) You can add one of the following to your init file
(setq verilog-auto-lineup nil) ;; disable completely
(setq verilog-auto-lineup 'assignment) ;; disable only for declarations