Serial receive on STM32 MBR framework not working (solved)

[petex]

hello,

I am using the STM32 MBR frame work to do serial communications. I can get serial transmission to work fine, but serial reception refuses to work. I am calling "ReadString" and it just sits waiting for the status register (bit 5) to change.

Code: Pascal  [Select][+][-]

1.   USART1.Initialize(TUARTRXPins.PA10_USART1,TUARTTXPins.PA9_USART1);
2.  
3.   USART1.WriteString('Test program start');
4.   USART1.WriteString(CRLF);
5.  
6.   USART1.ReadString(str, 1);
7.  

I am using the default baud rate. The loopback of Rx and Tx to my computer works ok. Baud rate is 11520.

Also tried:

  //USART1.BitsPerWord := TUARTBitsPerWord.Eight;
 // USART1.Parity := TUARTParity.None; 

[MiR]

You cannot test in this way, when the writestring has finished the receive side will be in overrun because the chars sent by the write will have flooded the rx which will start receiving after all data was sent.

Remember that you are not on a multitasking OS here, with freertos this code would likely work because the serial will receive the chars based on interrupts and will put the chars in a queue for later reading.

You would need to implement interupts and queing on your own to get the same effect here.

check the uart example in mbf-freertos to see how uart interrupts can be implemented.

[petex]

I am not trying to test by looping back on the STM32 card. I just did a loopback test to my PC to check that the FTDI interface and terminal software part are working ok.

I do understand that the readstring procedure is polling the data, but when I call it, it sits waiting on a character forever, i press a key on the terminal running on my pc and nothing is received on the STM32 card.

[petex]

In the MBF framework unit MBF.STM32F1.UART.
The RX GPIO pin mode was set to TPinMode.AF0.
When I change it to an input, the readstring procedure works as expected.

i.e.

Code: Pascal  [Select][+][-]

1.   setBaudRate(DefaultUARTBaudRate);
2.   GPIO.PinMode[longWord(aRxPin) and $ff] := TPinMode.Input;
3.   GPIO.PinMode[longWord(aTxPin) and $ff] := TPinMode.AF0;    
4.  

[MiR]

I will check what the reference manual has to say on that tonight, thanks for pointing this out!

Michael

[MiR]

I have fixed the issue, you are right, the RX Pin needs to be set to Input and the pullup/pulldown resistors need to be disabled. I have fixed that and pushed the fix to github.

[petex]

Still not working. I updated your latest fix, i have to do the following to get it to work.....

Code: Pascal  [Select][+][-]

1.  setBaudRate(DefaultUARTBaudRate);
2.   GPIO.PinMode[longWord(aRxPin) and $ff] := TPinMode.Input;
3. //  GPIO.PinDrive[longWord(aRxPin) and $ff] := TPinDrive.None;
4.   GPIO.PinMode[longWord(aTxPin) and $ff] := TPinMode.AF0;
5.   // Set the (very limited) Pin Remapping, RX Pins follow TX Pins as there is only one config bit
6.  
7.  

[MiR]

Aaargh... The devil is in the detail, the underlying routine for setting pullup/pulldown did not work completely.
Hopefully fixed now, can you please retry?

I am also close to finish I2C and ADC for Bluepill, perhaps you can help me test them when they are done.

When you still find something broken please open an issue @GitHub, makes life easier....

Michael

[petex]

I have got it working as expected with the latest update. Thanks.

I am also close to finish I2C and ADC for Bluepill, perhaps you can help me test them when they are done.

I'll check them out when ready.

On a general point........
I did a quick hack of the STM32 C library to get the ADC working in a basic mode. I then discovered some cleaner conversions (namely   unit stm32f103fw Jeppe Johansen,  Bernd Mueller)

This unit does not cleanly compile using the FPC compiler tools you have released. I have tweaked some of it to get the ADC to work. I am assuming that it cleanly compiles with the official ARM compile releases. I do not want to keep re-inventing the wheel here.

So does your MBF framework provide a layer over the current STM32 library conversion ?

As it stands the MBF framework is basic in function and not comprehensive. This is not a criticism as I realise it is work in progress. I would want to extend/add bits when I need them in which case I would look to the STM32 library code.

Will your compiler changes feed back into the official FPC releases at some time ?

When adding a new bit of functionality, I would generally look at the C code examples around and take them as a guide.