Cannot change value of LCD_CR register - c

I am currently playing with L152C Discovery board and trying to make simple clock that would use the RTC build into the STM32 and onboard Glass LCD with LCD HAL library configured via CubeMX.
But I am currently facing a problem I can't get my head around:
CubeMX does not have an option to enable segment mux in the LCD_CR register. I would like to enable it, because it would make the segment mapping easier.
So I thought, fine, I will make an direct register manipulation, enabling the mux (bit 7 in the LCD_CR).
I used the command LCD->CR |= LCD_CR_MUX_SEG; But even after executing the command, the MUX_SEG bit is still zero. (I checked in the debug session with command stepping and SFRs memory map)
Is there something that I am doing wrong? Or is there another way to change init parameters that CubeMX configured but does not have graphical implementation of this settings option?
The application is using FreeRTOS and I executed LCD->CR |= LCD_CR_MUX_SEG; after HAL_LCD_Init(&hlcd); so I sappose that the LCD peripheral clock is running (and segments are updating).
I recorded a short video showing this problem:
https://youtu.be/0X6Zu5EPudU
To be honest, I am not skilled at direct register manipulation, so I am probably doing something wrong.
Any help would be appreciated!😇

As #KIIV said:
RM0038 Liquid crystal display controller (LCD) Note: The VSEL, MUX_SEG, BIAS and DUTY bits are write protected when the LCD is enabled (ENS bit in LCD_SR to 1).
The LCD must be disabled when making changes to the above registers.

Related

Syncronizing 3 STM32L4 MCU's sine generators using one GPIO pin on each MCU

I have developed a custom STM32L475 board with one GPIO pin wired up for synchronization along some other circuitry for the synchronization, unfortunately we decided to route the generated sinus signal from module to module.
This is not optimal so I want to optimize so it is not the sinus signal which is routed from master module to slave modules, but to just transfer a digital trigger to restart the generation of a full sine wave.
To do this I need to be able to setup the MCU's to use the one GPIO pin on each MCU as both output and trigger for a timer.
To do this without an update of the HW I need to be able to combine:
1. Using the 3 pins (one from each MCU) as open drain outputs as an AND gate, this works.
2. I know the GPIO pin can be used as external trigger, triggering on a negative edge.
The question is, is it possible to trig a timer of an output pin using only one GPIO pin, to make the MCU which finalizes its sine generation first trigger itself and the other MCU's, and if so, how?
Please note, it must use the level of the output pin itself, eventhough it is an outputpin.
I am a HW developer, learning to do firmware for our HW, so I am kind of new to software development, so I am using HAL, please be nice
STM32L475 allows to configure a GPIO in different modes that must be (exclusively) selected through the corresponding GPIOx_MODER register:1
(Digital) Input mode
General purpose output mode
Alternate function mode
Analog mode
The alternate function applied in Alternate function mode must also be selected exclusively, through the corresponding GPIOx_AFRL or GPIOx_AFRH register, resp.2
The trigger for an interrupt or timer is an alternate function, and the output of a (analogue or digital) signal is a (different) alternate function, too.
Therefore, I think there is no solution to the given problem based on peripheral configuration.
1
Reference Manual, Rev 7:
See
Section 8.5.1 for GPIO mode selection
Figures 23/24 in Section 8.4 for explanation
2
ibid.:
See
Section 8.5.9 for GPIO alternate function selection
Section 8.4.2 for explanation

VREF Output on STM32L0

I have an STM32L051 and want to drive an external DAC (SPI).
For that I would like to use the feature, mentioned in the manual, to output the internal reference voltage to the PB1 pin of the STM32.
I use the STM32Cube HAL as a basis. However the examples of using the VREF are limited to internal use for ADCs and comparators.
If I understand correctly, I can use the CFGR3 register to both enable the VREF as well as connect it to the PB1. Using the Cube drivers, I can use the HAL_SYSCFG_VREFINT_OutputSelect(SYSCFG_VREFINT_OUT_PB1) function, but to enable it, I should use either HAL_ADCEx_EnableVREFINT() or HAL_COMPEx_EnableVREFINT(). The manual information on SEL_VREF_OUT indicates that ENBUF_VREFINT_ADC must be set.
Furthermore no mention is made about the configuration of the pin itself. Should I simply declare it as a DAC Pin? An ADC Pin?
Answer
It is as simple as
if ( HALD_ADCEx_EnableVREFINT() != HAL_OK )
{
Error_Handling();
}
HAL_SYSCFG_VREFINT_OutputSelect(SYSCFG_VREFINT_OUT_PB1);
And I can see the 1.22 V on the PB1 output.
It does not require further pin (GPIO) configuration.
Complications and justification for the question (can be skipped)
I had some issues with the board from out electronic dept. and thus switched to the STM32L053-Discovery board. The above solution did not work, and I kept seeing 0V on PB1 (or PB0).
I assumed that was due to some configuration missing. However, after some further tests, I actually found that on that Discovery board, both PB1 and PB0 are reserved for a sensor. By closing the SB23 bridge, I could use PB1 back to the GPIO, and thus see the reference voltage on the pin.

Soft bootloader error on stm32f205rg

Good day, i have a problem with the loading of
firmware of the mc stm32f205rg. i used function
boot_softs to enter to the bootloader , which is
situated in system memory.
void boot_softs() {
volatile uint32_t addr = 0x1FFF0000;
void (*SysMemBootJump)(void);
SysMemBootJump = (void (*)(void)) (*((uint32_t *)(addr + 4)));
HAL_RCC_DeInit();
SysTick->CTRL = 0;
SysTick->LOAD = 0;
SysTick->VAL = 0;
_disable_irq();
SYSCFG->MEMRMP = 0x01;
__set_MSP(*(__IO uint32_t*)0x20001000);
SysMemBootJump();
}
But during the checking with the help of Flash loader
demonstrator program i have found out that mc dont
enter in firmware reloading state.
I rechecked the same function on stm32f207 with no
changes and stm32f103c8 with address of programm
beginning changed.in both cases everything works
correctly and mc reloades.
Maybe someone faced such a problem and can help me
with this problem. Thanks in advance.
I don't think system memory can be accessed via code, You need to make changes to the external PINs that are responsible for mode selection. M0 and M1.
Upon selecting these pins , you may enter in system mode of your STM32. Here is one link that explains how to send command to bootloader. Click here!
You have to check in system bootloader address because it varies depending on MCU.
So check out this documentation from ST: in system bootloader guide from ST
As I see you are using wrong RAM address.
Part from bootloader cook book:
Moreover, there should be a trigger for entering to system bootloader. As I understand you are using software call method from your main application. This method is not reliable if BOOT pins of MCU are uncontrolled because if serial line or updating software fails you will loose main application and you will be unable to update device. Than you'll need programmer.
So updating, overwriting software which has system bootloader call is unsafe updating method. I would suggest it only as a own usage update method.
To have safety you should control BOOT pins.
Or implement mini custom bootloader which could be triggered by button (to start main app) and before triggering that mini bootloader would stay quiet and let system bootloader update main app. Update can't touch mini bootloader memory, this own customized bootloader should be untouched while update. But that is a suggestion.
Easer way to take control on update is to control BOOT pins.
For example:
put 3.3V or GND (depends on MCU) on BOOT pins with jumpers , set power and than device automatically will enter to system bootloader.
After update remove jumpers, and after power reset device will enter to your new update application.
That's all.
If you do not have BOOT0, BOOT1 pins control from hardware. I strongly recommending you to check those pins control.
There is a guide from ST about BOOT pins: reference manual
Part of description from reference manual:

STM32F1 - Using master SPI on bare metal

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.

Steps to make a LED on or off from a C program using Serial Port?

I knew there is a similar post:
Steps to make a LED blink from a C/C++ program?
But now I am working on a arm-based development board, and it seems to have two serial ports that I could use it to make a LED on or off.
Basically I think the flow is , make one pin in serial "1" or on and the LED will be turned on and "0" to make it off.
Is there some reference code in C-language I could refers?
Generally speaking, the board should come with some Board Support Package (BSP) which lets you control the built in I/O. Look for a serial library if you really want to use the Hardware flow control signals.
I'd recommend looking for some GPIO (General Purpose I/O, or digial I/O) on the board, which typically lets you configure it as an input or an output. You should be able to connect the LED via a current limiting resister between a digital I/O line and a ground pin. Make sure you have the LED oriented correctly if you connect it backwards it will block the current instead lighting. And as always make sure you check it out with a digital voltage meter before connecting it.
Even if you don't have a BSP for digital I/O the configuration is usually pretty simple.
Set a bit in a register to enable it, set bit in another register to select input or output they will normally be arranged in 8-bit "ports." Some systems allow you configure individual I/O pins, other will only allow you to configure the whole port for input or output. Then you just write a 1 or 0 to the bit you want to control in an write/output register.
ARM chips typically have a considerable amount of built in peripherals today, so most boards will just be bringing the I/O out to physical connectors on the board and you may need to read the chip vender's documentation to find the register memory map. Better board venders will supply documentation, a library (BSP) and examples. Luminary Micro even supplies chips with built in ethernet MACs and PHYs, just add a connector and Magnetics and you have a 1 chip Webserver.
This will, I'm afraid, be heavily dependent on the specifications of the particular arm-based development board you are using.
You need to find documentation specific to that board.
I used to do this kind of programming before.
You need to study the serial port connection
http://www.lammertbies.nl/comm/cable/RS-232.html
http://www.beyondlogic.org/serial/serial.htm
It has +5v, -5v on the output, I can't remember clearly now. Not every pin is needed.
I never use ARM before, but I use a 8-bit PIC controller to program it. I guess you can find a lot of example online.
The preferred alternative for controlling a GPIO is via a BSP. Because this BSP (board support package) does all the work for you in setting all peripherals to good defaults and and allowing you to call a function. Possibly your BSP of choice will have a function to write a byte to an 8-bit GPIO port; your LED will only have one bit. In this case your C code could look like: (at least: it will work like this on Luminary Micro kits). (Example code; requires a bit of extra work to make it compile especially on your kit).
/* each LED is addressed by an address (byte) and a bit-within-this-byte */
struct {
address, // address of IO register for LED port
bit // bit of LED
} LEDConfigPair;
struct LEDConfigPair LEDConfig[NUMBER_OF_LEDS] = {
{GPIO_PORTB_BASE,0}, // LED_0 is at port B0
{GPIO_PORTB_BASE,1} // LED_1 is at port B1
} ;
/* function LED_init configures the GPIOs where LEDs are connected as output */
led_init(void)
{
U32 i;
for(i=0;i<NUMBER_OF_LEDS;i++)
{
GPIODirModeSet( LEDConfig[i][0], LEDConfig[i][1], GPIO_DIR_MODE_OUT );
}
}
/* my LED function
set_led_state makes use of the BSP of Luminary Micro to access a GPIO function
Implementation: this BSP requires setting 8 port wide IO, so the function will calculate a mask (
*/
set_led_state(U8 led,bool state)
{
U8 andmask;
U8 setmask;
andmask = ~(1 << LEDConfig[led].bit);// a bitmask with all 1's except bit of LED
if (true == state)
{
setmask = (1 << LEDConfig[led].bit); // set bit for LED
} else
{
setmask = 0;
}
GPIOPinWrite(LEDConfig[led].address, andmask, setmask);
}
Of course this is all spelled out; it can be done in a single lines like this:
#DEFINE SETLEDSTATE(led,state) GPIOPinWrite(LEDConfig[led].address, ~(1<<LEDConfig[led].bit),(state<<LEDConfig[led].bit))
this will do the same, but only makes sense when you can dream bit masks, and you only want to toggle some LEDs to debug the real program...
The alternative: bare metal.
In this case you need to set up everything for yourself. For an embedded system, you need to be aware of pin multiplexing and power management (assuming memory controller and cpu clocks are already set up!)
initialization: set pin multiplexing in such a way that the function you want to control is actually mapped on the package.
initialization of pheripheral (in this case either a UART, or a GPIO function on the same pin)
You can't do it using Rx or Tx pins of Serial port. For that you just need to control the RTS or CTS pins of serial port.
Just google for "access COM port in VC++ code" and then control the RTS and CTS status pins to turn ON and OFF any external device.

Resources