STM32F429 UART7 Rx question

[baev_al]

Posted on September 19, 2014 at 13:19

Hello friends.

I'm trying to communicate with DS18B20 via 1-wire interface.

Here is the example of reset function (all pins and clk are set erlier). The problem is that the variable data

does not receive UART7 DR value. I use EWARM. I see that DR receives the response from the DS18B20. Is this

some compiler options?

print_number (data) � prints 3 digit number on the LCD. In this function it is always 255, however data

variable is unavailable in the watch window.

void ow_reset()

{

USART_InitTypeDef USART_InitStructure;

uint16_t data;

USART_InitStructure.USART_BaudRate = 9600;

USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;

USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;

USART_InitStructure.USART_Parity = USART_Parity_No;

USART_InitStructure.USART_StopBits = USART_StopBits_1;

USART_InitStructure.USART_WordLength = USART_WordLength_8b;

USART_Init(UART7,&USART_InitStructure);

USART_Cmd(UART7,ENABLE);

USART_ClearFlag(UART7, USART_FLAG_TC);

USART_SendData(UART7, 0xf0);

data = USART_ReceiveData(UART7);

while(USART_GetFlagStatus(UART7, USART_FLAG_RXNE) == RESET);

while (USART_GetFlagStatus(UART7, USART_FLAG_TC) == RESET);

print_number (data);

}

#debugger-is-invasive #1-wire

[Tesla DeLorean]

Posted on September 19, 2014 at 14:11

Well I'm not sure it functions at a hw level, but you need to be waiting for RXNE before reading the data register.

[baev_al]

Posted on September 19, 2014 at 18:12

I tried with and without that function - nothing changed. It is important that UART7 DR is 0xE0 and equals the response value of ds18b20...

What is interesting when I changed data = USART_ReceiveData(UART7); with data = (uint16_t)(UART7->DR & (uint16_t)0x01FF); correct value started to be indicated on the lcd, but still in the watch expression window the value of data is unavailable

[waclawek.jan]

Posted on September 19, 2014 at 18:28

USART routines often fail when you try to step through them using a debugger, which reads out the state of USART's registers (to be able to display them) at every step. This is because some of the status flags are cleared by hardware upon reading the registers, e.g. the RXNE flag is cleared when the DR register is read.

JW

[Tesla DeLorean]

Posted on September 19, 2014 at 18:55

You can't simply park a debug view over peripheral registers and hope to get a realistic view of them. The debugger is invasive, and if you want to know what's happening internally you need your own code to read the registers, output diagnostics, and react to the transient state and interplay of the registers appropriately.

[Andrew Neil]

Posted on September 19, 2014 at 21:56

''It is important that UART7 DR is 0xE0 and equals the response value of ds18b20''

Have you read this: 

http://www.maximintegrated.com/en/app-notes/index.mvp/id/214

?And have you got your hardware connections correct?The 0xE0 is not the ''response value'' from the DS18B20 - it is just the effect of the Presence Pulse.And it is not guaranteed to be 0xE0...

[baev_al]

Posted on September 20, 2014 at 07:22

''USART routines often fail when you try to step through them using a debugger...''

Yes, I tried step by step debug...it was a mess. So I put the breakpoint at the very end of the function.

[baev_al]

Posted on September 20, 2014 at 07:25

''You can't simply park a debug view over peripheral registers and hope to get a realistic view of them. The debugger is invasive...''

I started to print certain information on the LCD. For example this substitution data = USART_ReceiveData(UART7); with data = (uint16_t)(UART7->DR & (uint16_t)0x01FF); I could catch only with the LCD. However it seems that it should be the same action.

[baev_al]

Posted on September 20, 2014 at 07:33

''Have you read this: 

http://www.maximintegrated.com/en/app-notes/index.mvp/id/214

? And have you got your hardware connections correct? The 0xE0 is not the ''response value'' from the DS18B20 - it is just the effect of the Presence Pulse. And it is not guaranteed to be 0xE0...'' Yes, exactly this article I used as a reference.  The part from this article: ''A single slave device running at minimum internal timing will change the response to 0xE0. A single slave running at maximum internal timing will change the response to 0x90. '' I hope the one DS18b20 I use is running at minimum timing :)

[Andrew Neil]

Posted on September 20, 2014 at 08:51

''I hope the one DS18b20 I use is running at minimum timing''

But ''hoping'' does not make it so!Statistically, it is highly  unlikely to be at either the maximum or minimum limits - or any other specific value, for that matter!