Uart 6 problems

jdcowpland · ‎2013-12-02

Posted on December 02, 2013 at 10:43

Hey folks,

Having some issues receiving data on uart6 on my STM32F415VG and hoping someone might be able to help. I'm sending data at 115.2kbaud with 8 bits, no parity and one stop bit. I send the data to my peripheral device ( a sequence of 5 bytes) and it responds with 5 bytes. I can see both these signals on the lines between the devices using an oscilloscope. Problem is that it looks like the response is possibly too fast for the processor to catch? My receive code looks like this:

USART6_CR1.RE = 1;

i=0;

while(1){

if(usart6_sr.b5 == 1){

buffer[i]= USART6_DR;

i++;

if(i==4){

break;}

I know i could use the stm libraries, but I'm using Mikroelektronika as my IDE so that's not going to work all that easily. I've run a debug, and the first time through, the uart picks up the first response byte and the SR register has a value of 248. That shows that there is an overrun error. The second time through that while loop, the value is 192, which shows that there is no data left to read. Makes me think that all the data is coming too fast and that it catches the first byte but the rest of the data keeps coming before it can clear the data register and so it logs an over run. Any ideas?

#clubbing-baby-seals

frankmeyer9 · ‎2013-12-02

Posted on December 02, 2013 at 11:04

The source code presented doesn't give an indication of the actual instructions and timings.

However, polling a flag in a blocking loop is surely not the best method to implement serial communication.

I can't imagine the Mikroelektronica toolchain does not have a way to define an interrupt handler.

But I do know that most of their libs are encrypted, the main reason why I would not even consider using this toolchain.

jdcowpland · ‎2013-12-02

Posted on December 02, 2013 at 16:46

I agree that Mikroelektronika's libraries are annoying (and often don't even work) so most of the time, I'm just writing everything from scratch using the registers etc.. Here's my current code using the interrupt that you suggested. I've also incorporated DMA to try and speed things up, but all I get is the first response bit into my buffer 5 times rather than the 5 response bits I expect.

#include ''stdint.h''

uint8_t cmd1[] = {0x55, 0xAA, 0x00, 0x00,0xFF};

uint8_t buffer[250];

char *temp;

int i,b=0;

void main() {

RCC_APB2RSTR.USART6RST = 1;

Delay_us(1);

RCC_APB2RSTR.USART6RST = 0;

RCC_APB2ENR.USART6EN = 1;

RCC_AHB1ENR.DMA2EN = 1;

GPIO_Config(&GPIOC_BASE,

_GPIO_PINMASK_6 | _GPIO_PINMASK_7,

_GPIO_CFG_MODE_ALT_FUNCTION | _GPIO_CFG_OTYPE_PP | _GPIO_CFG_SPEED_100MHZ);

UART6_INIT_ADVANCED(115200,_UART_8_BIT_DATA, _UART_NOPARITY, _UART_ONE_STOPBIT, &_GPIO_MODULE_USART6_PC67);

USART6_CR1.UE = 1;

USART6_CR1.M = 0;

USART6_CR1.PCE = 0;

USART6_CR2bits.Stop = 0;

USART6_BRRbits.DIV_Fraction = 0xC;

USART6_BRRbits.DIV_Mantissa = 0x16;

DMA2_S0CRbits.CHSEL = 0;

DMA2_S0CRbits.MBURST = 0;

DMA2_S0CRbits.PBURST = 0;

DMA2_S0CR.DBM = 0;

DMA2_S0CR.PL0 = 0;

DMA2_S0CR.PL1 = 1;

DMA2_S0CR.PINCOS = 0;

DMA2_S0CR.MSIZE0 = 0;

DMA2_S0CR.MSIZE1 = 0;

DMA2_S0CR.PSIZE0 = 0;

DMA2_S0CR.PSIZE1 = 0;

DMA2_S0CR.MINC = 1;

DMA2_S0CR.PINC = 0;

DMA2_S0CR.CIRC = 0;

DMA2_S0CR.DIR0 = 0;

DMA2_S0CR.DIR1 = 1;

DMA2_S0CR.PFCTRL = 0;

DMA2_S0CR.TCIE = 1;

DMA2_S0NDTR = 0x05;

DMA2_S0PAR = &USART6_DR;

DMA2_S0M0AR = &buffer;

Delay_ms(1);

USART6_CR1.TE = 1;

for(i=0;i<sizeof(cmd1);i++){

Uart6_Write(cmd1[i]);

}

//while(USART6_SR.TC == 0){}

NVIC_IntEnable(IVT_INT_USART6);

USART6_CR1.RXNEIE = 1;

/*USART6_CR1.TE = 0;

USART6_CR1.RE = 1; */

//DMA2_S0CR.EN = 1;

Delay_us(1000);

/*

if(USART6_SR.B5 == 1){

buffer[0]=Uart6_Read();

} */

Delay_ms(1);

}

void Usart6_interrupt() iv IVT_INT_USART6{

DMA2_S0CR.EN = 1;

}

Tesla DeLorean · ‎2013-12-02

Posted on December 02, 2013 at 19:00

Grief, can you explain the benefits here?

The task, as I'm interpreting it, should be well within the scope of the processor using interrupts, and at data rates exceeding the ones here.

Note : writing registers at a bit level on ARM is not efficient, on some peripherals it is destructive.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

jdcowpland · ‎2013-12-04

Posted on December 04, 2013 at 09:51

Hey guys, thanks for the help. Not quite sure what was going on to begin with. I stripped the code back and started from scratch basically and got it all working without dma within a matter of minutes. Pretty new to developing stuff on stm boards so forgive me if I'm doing things that seem daft :p

Tesla DeLorean · ‎2013-12-04

Posted on December 04, 2013 at 18:05

Pretty new to developing stuff on stm boards so forgive me if I'm doing things that seem daft :p

Not sure I'd characterize it as Daft, as much as Brutal. I think there are less painful ways of learning new architectures.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Andrew Neil · ‎2013-12-05

Posted on December 05, 2013 at 11:30

''I'm using Mikroelektronika as my IDE so that [use the stm libraries] is not going to work all that easily''

Why not? The libraries are supplies as standard 'C' source code - shouldn't be any problem with that, surely...?

''

I can't imagine the Mikroelektronica toolchain does not have a way to define an interrupt handler''

Defining an interrupt handler shouldn't be difficult - one of the key features of Cortex-M is that interrupt handlers are just plain 'C' functions -

no

special toolchain support required!

frankmeyer9 · ‎2013-12-05

Posted on December 05, 2013 at 11:42

Defining an interrupt handler shouldn't be difficult - one of the key features of Cortex-M is that interrupt handlers are just plain 'C' functions -

no

special toolchain support required!

Sure, but most toolchains (and all commercial ones) come with ready-made template implementations and matching linker scripts + startup files.

Not sure what Mikroelektronika provides here, and I have no intention to try ...