First steps with STM bare metal, UART not working [STM32VLDiscovery]

[Jesus Tomas]

Posted on February 25, 2016 at 16:09

First of all, let me apologize in advance for the mistakes in my grammar. Not an english speaker here. I hope, howewer, that this can be understood.

I have recently started to move away from PIC microcontrollers (Mainly PIC18F family) to ARM microcontrollers. I chosed STM32 because of the inexpensive Discovery Boards, wich I could use before doing a board for the project I need to do. I saw that some libraries could be used, but back in the day when I was first learning about microcontrollers, teacher never allowed us to use anything complex, since it ''obscured'' what happened in the microcontroller. Those were good times, learning in ASM with small microcontrollers... Anyway, now, some ten years after that, I still like to do things ''as close to the action'' as I can. So, I found this tutorial for setting up GNU GCC in Keil [

http://m8blogspot.com.es/2012/10/using-gcc-in-keil-best-of-both-worlds.html

] and made it work with some minor changes (Only in preprocessor directives I had to change anything, I think, and there is not much difference between Keil 4 and 5 versions). I had some problems but as of now, I have GPIOs working, and SysTick happily generating ticks every ten ms. Now I am trying to set up one of the UARTs, since withthat done I find easy to develop the rest (Having the possibility to send messages to the PC makes easier to follow the program flow, specially since I am not confortable enough with the debuggin way...). Seems that I can't send anything (Not reading even garbage from the PC), and I have not a oscilloscope right now with me, so, if any person more experienced with STM32 mcus could take a look at this and enlighten me, that would be great. The code: USART configuration

void ConfigUSART2(void)
{
// Pins: UART2_TX is PA2, UART2_RX is PA3
// So PA2 ==> ''alternate function push-pull''
// PA3 ==> ''Input floating''
GPIOA->CRL &= 0xFFFF00FF; // Both nibbles to zero
GPIOA->CRL |= 0x00004200; // and now to the correct values
RCC->APB1ENR |= RCC_APB2ENR_AFIOEN; // AFIO Clock
RCC->APB1ENR |= RCC_APB1ENR_USART2EN; //USART2 Clock
//Following the steps described in page 582 of RM0041:
USART2->CR1 |= USART_CR1_UE; // Step 1: Enable USART
//Step 2: M value, I want 8 bits so no need to touch it
//Step 3: Stop bits, again default value is ok
//Step 4: Not using DMA, so...
USART2->BRR = 0xC9; //Step 5: Baudrate --> Baudrate=Fclk/(15*USARTDIV) --> With 24MHz, 115200 USARTDIV=12,9
USART2->CR1 |= USART_CR1_TE; //Step 6: IDLE
USART2->CR1 |= USART_CR1_RE; //I enable also reception
}

Main

int main()
{
unsigned long i;
uint8_t transmit, receive, data;
Inicializar_GPIOs(); // This congigures GPIOs for leds and pushbutton, working OK
Inicializar_SysTick(); // Again, working OK, this configures SysTick only
ConfigUSART2();
transmit=0; 
receive=0;
while(1)
{
if(GPIOA->IDR & 1) // Button pressed
{
// PC9 led Toggle
GPIOC->ODR ^= GPIO_ODR_ODR9;
//Dummy loop
for(i=0;i<
0x1FFFFF
;i++); 
}
if (transmit<10)
{
data
= 
0x48
;
data+=transmit;
//while(USART2->SR&USART_SR_TXE);// Wait for idle
USART2->DR = dato;
transmitido++;
GPIOC->ODR ^= GPIO_ODR_ODR9;
for(i=0;i<
0x1FFFFF
;i++);
for(
i
=
0
;i<0x1FFFFF;i++);
}
if (USART2->SR&USART_SR_RXNE) //Data ready to be read
{
receive=USART2->DR;
if (receive==data)
{
GPIOC->ODR |= GPIO_ODR_ODR9; //I leave Led always on and wait
while(1);
}
}
}
}

I have translated variables names and comments to english,I hope there is no mistakes... Thanks in advance! And also, do you know any good tutorial/book for programming this mcus bare metal? #limited-thinking

[Radosław]

Posted on February 27, 2016 at 14:03

Have you any important arguments? Becose this isn't any argument.

Obvisly not. If i will wait or use any library in my aplication it will never be done. Now it's go to mass production.

[AvaTar]

Posted on February 27, 2016 at 14:17

> Now it's go to mass production.

Not everything is mass produced. There exist certain device classes were software needs to be certified, e.g. medical, transportation, military, and industrial use. Those devices usually survive several generations of the average consumer electronics, and thus require a certain software quality. Ever developed software for a SIL2/SIL3 compliant device ? There exist producers of mass products where your ideas are accepted and welcome. And there exist others where your style is banned - if you recognize it or not.

[Radosław]

Posted on February 27, 2016 at 14:28

SPL or HAL are certificated? First heard. 

Still not argument.  Have you read  any library file discription?  I quote ''as is''.   Think before you will say something

[clark2]

Posted on February 27, 2016 at 15:57

I will agree with Radoslaw in this somewhat off topic debate.  I have found mucking around in library ''documentation'' and gigantic header files just to produce bloated, inefficient code to be less productive than referring to the reference manual and writing code that gets the job done.

I will also offer this opinion:  the STM32F1 peripherals, in my limited experience, are a disaster.  They are very complicated to manage and the documentation leaves a lot to be desired. FWIW, Texas Instruments offers very affordable development boards (you can buy an MSP-EXP432P401R evaluation board right now for $4.32).  Many of their development boards are less than $20.  In addition, their peripherals and documentation are vastly better than ST's; so is their user forum and ecosystem, in general.That's my two cents worth...

[AvaTar]

Posted on February 27, 2016 at 18:05

>I will agree with Radoslaw in this somewhat off topic debate.  I have found mucking around in library ''documentation'' and gigantic header files just to produce bloated, inefficient code to be less productive than referring to the reference manual and writing code that gets the job done.

Not so much off-topic. You need to see this in a wider context. I'm not speaking of ST's libraries specifically here, but of the idea to either separate low-level hardware-related routines and 'abstract' application logic, or get down into peripheral registers from everywhere, as Radoslaw suggests as panacea. With choosing one of this methods to use, a young engineer basically chooses his career path. ST has a lot of high-volume/low cost customers, which need cthe cheapest silicon to get a job done. These are basically industries who's products have a lifespan of 6 ... 24 month. And there are other branches of the IT industries, that guarantee support for their products for 5 .. 25 years. Those companies are gladly willing to sacrifice 10 or 20% of core performance, if they can reuse tested and proven libraries and sources. And they don't haggle for a few cent, if a DO-178B of SIL2/3 certification costs a thousand times as much.>I will also offer this opinion:  the STM32F1 peripherals, in my limited experience, are a disaster.  They are very complicated to manage and the documentation leaves a lot to be desired. The ST peripherals are surely more complex - that does not make them a disaster IMHO. Higher perfomrance and flexibility demands more complexity. If only ST was able to pack that into a good, comprehensive and robust HAL library. Cube is the worst thing I have seen in years, and IMHO will end in some kind of disaster. The SPL is killed in favour of Cube. Much more robust, lightweight and comprehensive, but incomplete and abandoned.> FWIW, Texas Instruments offers very affordable development boards (you can buy an MSP-EXP432P401R evaluation board right now for $4.32). ... Not sure about the MSP432. While the 430 is probably about to die out, not everybody needs aCortex M4. And TI was not willing to offer M0/M3 chips to avoid internal competition. But with the fierce competition in the MCU market, it's late to introduce another M0/M3. Meaning, TI's strategy (buying LM and abandoning the M3 core) is not clear to me.>In addition, their peripherals and documentation are vastly better than ST's; so is their user forum and ecosystem, in general. While this is not fully true (the TM4C ADC has a sererve design bug, for instance), the documentation is better. And there are even helpful TI employees present on their forum, answering technical question - figure that ...

[AvaTar]

Posted on February 27, 2016 at 18:09

> SPL or HAL are certificated? First heard. 

You need to read thoroughly before answering to posts. No one made the statements you suggest.> Think before you will say something I agree.

[Radosław]

Posted on February 27, 2016 at 18:55

You mention about that.

Any library or coding standard will not preserve from programist mistakes. I usealy creates aplication that i must suport at least 10 years, and after that next 10 years of service.  This aplication work in industial enviroment.  Without any second of break. Give me any reason to use SPL or HAL. Baremetal programing is the best way to get save aplication. But any sofftware or device certification aren't for newbes. But problem in this topic becomes from 1 try of....

[mark239955_stm1]

Posted on February 28, 2016 at 10:57

Guys... put away your e-penif's, please, you're both right in your particular contexts.

Personally I mostly do register hacking because I loathe bloated badly written bug-heavy inefficient library code like ST's HAL abomination, but I do understand why it exists and acknowledge that it has its place if rapid code deployment and portability are critical requirements.  I even use bits of it, sometimes. As amusing as your respective ranting has been, you've both repeatedly had your says; can you leave it alone yet?

[AvaTar]

Posted on February 28, 2016 at 12:49

>Personally I mostly do register hacking because I loathe bloated badly written bug-heavy inefficient library code like ST's HAL abomination, ...

I use it sometimes too, for my private projects. But often the SPL, since it is not only robust and mature, it also provides for a self-documenting code. Who does remember all the peripheral register names, addresses, and bits, even after a few weeks ? For sure that doesn't matter for throw-away code that needs no maintainance. >... but I do understand why it exists and acknowledge that it has its place if rapid code deployment and portability are critical requirements.  I even use bits of it, sometimes. I, actually, do not. Beside of the current quality of the tool and the generated code, I know of no professional user that is really willing to embark on the Cube-ship.> Guys... put away your e-penif's, please, you're both right in your particular contexts. I have no problem with others using different methods that suits their need best. But honestly, I don't understand how one feels personally attacked when not everybody is in total agreement with him.

[Radosław]

Posted on February 28, 2016 at 13:07

Why someone should remember all bits? Everything is in RM.   But stil for example UART have only 3 register for control and 1 with status.  WOW to many for me.

I'd attack this methd becose I see to many times, bad code created with this methos with guys who aren't familiar with architekture or how the tools work, compiler for exmaple. Readability? WOW. I prefer to read 3 lines not 3 pages for config ports for example. Any SPL or HAL creates lazy programist. It's not prefesional. And and the end.  HAL SPL to have to much errors for me.  At last portability, SPL, HAL -> NONE , reg based -> FULL.