I am using EWARM IDE from IAR with an Olimex development board for the ARM STR712FR2, and a J-link JTAG debugger provided by IAR. For some reason, I can't seem to write to the UART TxBUFR register. I believe I have configured all the clocks and baud rate correctly. The datasheet says that when I write to the TxBUFR register, the UART is supposed to immediately start transmitting. I am running this in debug mode, and when I place a breakpoint right after I set the TxBUFR to a value, the register still shows 0x0000, unchanged.
The register value may not change or it may be write-only, have you checked to see if it is actually transmitting or not?
The UART_CR register resets to 0 which has some fields set to reserved values. Have you configured all the fields in here? ALso, as was mentioned, UART_TxBUFR is a write-only register, so you will not be able to read the value back.
Related
I'm working with the STM32L432KC and am relatively new to the embedded world. What happens if I write to a configuration register, wait some time, and then write to the register again with the same configuration. Does this have any effects?
For reference, I am using the STM32L432KC microcontroller. The register in question is the Reset and Clock Control (RCC), AHB2 Peripheral Clock Enable Register (RCC_AHB2ENR). I have a function that enables the clock for a GPIO port, by OR'ing in a bit. I am wondering if calling the function while the pin is active will have any effects.
There is no generic answer for all registers on all devices. The only correct course is to consult the data sheet or reference manual for the part concerned.
In the specific case of STM32L432 RCC_AHB2ENR all used bits are specified as "set and cleared by software" with no specific hardware action on read/write. This is true I believe for the RCC_AHB2ENR on all STM32. Note however that the unused bits are reserved and should not be set to any value other then the reset value - also defined in the reference manual and in this case all zero.
Some registers change value under hardware control, so re-writing a previously written value may have an effect. A simple example on your part is TIM1_CNT where if TIM1 is running the counter will have changed and rewriting it will effect its period and any capture/compare events or event output or PWM it may be used for.
I've been trying to port some of my AVR code to drive a simple SPI LCD to ARM as a learning exercise (I'm very new to ARM in general). For this I just need to use SPI in master mode.
I looked in the datasheet for my device (STM32F103C8) and found that the SPI1 pins I need, SCK and MOSI are mapped as alternative functions of PA5 and PA7, respectively, along with other peripherals (pg.29). My understanding is that in order to use the SPI function on these pins, I need to make sure that anything else mapped to the same pin is disabled. When looking at the defaults for the peripheral clock control register, however, it looks like the other features are already disabled.
I looked at the SPI section in the reference manual, including section 25.3.3 - Configuring the SPI in master mode. First I enabled the SPI1 master clock in APB2ENR and followed the steps in this section to configure SPI1 to my needs. I also changed the settings for PA5/7 to set their mode to "Alternate Function Output push-pull" (9.1.4). Finally, I enabled SPI1 by setting CR1_SPE.
From my reading, I had thought that by loading a value into the SPI1 data register after configuring SPI as above, the data would be shifted out. However, after writing the data, the TXE flag in the SPI status register never becomes set, indicating that the data I wrote into it is just sat there.
At this point, I'm assuming that there is something else I've failed to configure correctly. For example, I'm not 100% sure about what to do with the PA5/7 pins. I've tried to understand what I can from the datasheets, but I'm not getting anywhere. Is there anything else that needs to be done before it'll work?
I'm almost certain that you did not set SSM and SSI bits in SPIx->CR1 register. SPI in these chips is pretty simple, for the polled transfers you need to set SSM, SSI, SPE, MSTR, correct format (LSBFIRST, CPOL, CPHA) and proper baudrate (BR) in SPIx->CR1 and you're good to go.
I'm writing a kernel (using qemu to simulate) for x86 as a school project and I ran into weird problem.
Even though I have set the interrupt flag in the eflags register, I'm sill not getting any clock interrupts (I checked with qemu info register command and I see eflag=0x292 which means it is set).
To be precise when I run a spin test (while(1); program) in user mode, I get one clock interrupt, but after that one, it stops, qemu does not seems to simulate more! did it happen to anyone else? Is there another mechanism that can affect interrupts?
Anyone have a clue?
Shai.
Apparently in x86, you have to acknowledge clock interrupts after each one.
I.e one must sent an acknowledgment to the lapic after every clock interrupt.
If you are expecting interrupts from the RTC, you must acknowledge the previous interrupt first by reading from REG_C (CMOS register 0x0C).
I've configured the timer 2 in CTC mode and to toggle the port pin on compare match (TCCR2A=0x42, TCCR2B=0x02, OCR2A=0x20) and have set DDR3 to output. Hence, according to the ATmega328P documentation (pages 158-163). OC2A (aka PB3) should toggle on each compare match. Unfortunately, I can't read the pin state at PORTB. Is this expected? I assumed, that even if a port is configured as output I can read the set value.
There were two problems:
In AVR Studio 4.18 I must not use the Simulator 1, because it has a bug for the timer 2 and hence can't toggle the port pin correctly. I needed to use Simulator 2 or AVR Studio 5.
I needed to read PINB instead of PORTB (though the toggling is an output operation).
I don't know about that specific microcontroller, but in some architectures you need at least a NOP between changing the port pin and the latch being updated (so you can read the change).
Also there is the maximum frequency a pin can be toggled at (many times slower than the microcontroller CPU clock). Be sure to not be over that frequency.
I'm trying to write to my lpt register with the function outb(0x378,val);
well.. I tried to debug with the call int ret=inb(0x378); I always get the ret=255 no matter what value I insert with outb before.
*I'm writing on the kernel mode since my program is a driver, therefore I didn't use ioperm() etc.
thank you in advance.
You have the parameters of outb function wrong, correct order is :
outb(value, port)
so you have to change your code to do:
outb(val, 0x378)
For more details please read Linux I/O Programming Howto .
Do you know for a fact that you have a parallel port installed at that address?
Get yourself a small low-current LED. Stick the long end in one of pin 2 (LSB) to pin 9 (MSB) and the short end in pin 25 (ground).
Try writing various values and see if you can get the LED to change by the bit value of what you write.
This should work (unless as previously mentioned you've gotten it programmed in an input mode) Being able to read back the port value is less certain, depending on the type of parallel port and implementation details (for example, you probably couldn't with the buffer chip that implemented it in the original PC)
Also note that most USB "printer" adapters don't give you bitwise register access. Something hanging off of the PCI or PCMCIA, etc may also have problems with direct register access at the legacy port address. There are nice USB parallel interface chips such as the FT245 and successors which you can use if you don't have a "true" parallel port hanging off the chipset available.
Have you set the direction register? If it is set as input then you will read what is on the port.
inb(0x378) is not required to return what was written; at least I've seen chips to behave so. Well, since you, at some point, have called outb, you know what's on anyway.