stm32f3xx-hal icon indicating copy to clipboard operation
stm32f3xx-hal copied to clipboard

Serial Communication Issue with crate

Open talalahsan01 opened this issue 4 years ago • 10 comments

Hey! Basically i was building a project which uses pwm and serial communication "usart1". So the Issue i was facing is that if I use the Serial Communication from Discovery Book, it works fine but if i write the same code with stm32f3xx_hal crate , it does work but it sends data in some other encoding, for example, from discovery book example, If i press "enter" it sends "13" but by using this crate "ENTER" = "128". Also no matter what i send i receive two integers. I am beginner so i am not very sure how to deal with this.

talalahsan01 avatar Jun 21 '20 16:06 talalahsan01

hi @talalahsan01,

if you post the code you are working with e.g. to your github account, we could have a look into it. if you describe your set up we have a chance in understanding it. For example I have no clue how your keyboard input is connected to your chip, how you are receiving anything, how you are displaying it, what the expected behaviour is, nor what all of this has to do with a pwm.

strom-und-spiele avatar Jun 21 '20 22:06 strom-und-spiele

hi @talalahsan01,

if you post the code you are working with e.g. to your github account, we could have a look into it. if you describe your set up we have a chance in understanding it. For example I have no clue how your keyboard input is connected to your chip, how you are receiving anything, how you are displaying it, what the expected behaviour is, nor what all of this has to do with a pwm.

I am showing here the code first of only usart1 communication that i am using

    let cp = cortex_m::Peripherals::take().unwrap();
    let dp = stm32::Peripherals::take().unwrap();

    let mut flash = dp.FLASH.constrain();
    let mut rcc = dp.RCC.constrain();

    let clocks = rcc.cfgr.freeze(&mut flash.acr);

    let mut gpioa = dp.GPIOA.split(&mut rcc.ahb);
    let tx = gpioa.pa9.into_af7(&mut gpioa.moder, &mut gpioa.afrh);
    let rx = gpioa.pa10.into_af7(&mut gpioa.moder, &mut gpioa.afrh);

    Serial::usart1(dp.USART1, (tx, rx), 9600.bps(), clocks, &mut rcc.apb2);

    let usart =  usart();

    let mut itm = cp.ITM;

    let mut buffer: Vec<u8, consts::U32> = Vec::new();

    

    loop{
        buffer.clear();

        loop{
            while usart.isr.read().rxne().bit_is_clear() {}
            let byte = usart.rdr.read().rdr().bits() as u8;
            iprintln!(&mut itm.stim[0],"{:?}", byte);
            //let ch = char::from(byte);

            buffer.push(byte).unwrap();

            if byte == 13 {
                buffer.pop();
                iprintln!(&mut itm.stim[0],"{:?}",buffer);
                buffer.clear();
            }
        }
    }   
}

fn usart () -> &'static mut usart1::RegisterBlock{
    unsafe {&mut *(USART1::ptr() as *mut _)}
}

So this is the code i am using and this is the same code as given in discovery book, the issue is that in my itm dump when i press e.g "a", I should receive "97", but instead I receive two numbers "6, 254" . so i could have gone around it using pop to remove one value but when i press "1" i receive "6,248" instead of "49".

What i want help is with a way to solve this problem as i mentioned i am a beginner in embedded so i really dont know whats going around. Also when pressing enter I should receive "13" but i am receiving "230,128" . I will attach my itm dump ss below.

Another issue was of pwm, when i used it with the code given in example of this crate. It was definitely working fine, so when i used it with this code it gave a panic error in itm dump saying

"panicked at 'attempt to subtract with overflow' ... stm32f3xx_hal/src/pwm.rs:878;1"

, the possible reason i could come up with was in my code when defining "clock" i didnt use "sysclk(16.mhz())" but if i used this function the serial communication stops working. Please help me regarding this.

Screenshot from 2020-06-23 23-18-23

talalahsan01 avatar Jun 23 '20 18:06 talalahsan01

I just skimmed through your issue for now, but this https://github.com/stm32-rs/stm32f3xx-hal/issues/54 could be related.

Sh3Rm4n avatar Jul 21 '20 06:07 Sh3Rm4n

I've fixed your markdown inline code, to make it more readable :)

Regarding your last point:

the possible reason i could come up with was in my code when defining "clock" i didnt use "sysclk(16.mhz())" but if i used this function the serial communication stops working. Please help me regarding this.

If you use ITM for debugging, you have to remeber to change this line. The number has to fit the the microcontroller cpu frequency, which is the sysclk.

@@ -24,7 +24,7 @@ monitor arm semihosting enable
 # # send captured ITM to the file itm.fifo
 # # (the microcontroller SWO pin must be connected to the programmer SWO pin)
 # # 8000000 must match the core clock frequency
-# monitor tpiu config internal itm.txt uart off 8000000
+monitor tpiu config internal itm.txt uart off 16000000
 
 # # OR: make the microcontroller SWO pin output compatible with UART (8N1)
 # # 8000000 must match the core clock frequency

"panicked at 'attempt to subtract with overflow' ... stm32f3xx_hal/src/pwm.rs:878;1"

It is rather unfortunate, that a clock misconfiguration results into a panic. I'd love to see improvement there, but haven't had time to improve this part.

I am showing here the code first of only usart1 communication that i am using

Which example of the discovery book are you using? I have taken the time to fully understand the program but for now, this seems like a logic error in the code.

Sh3Rm4n avatar Jul 28 '20 22:07 Sh3Rm4n

I've fixed your markdown inline code, to make it more readable :)

Regarding your last point:

the possible reason i could come up with was in my code when defining "clock" i didnt use "sysclk(16.mhz())" but if i used this function the serial communication stops working. Please help me regarding this.

If you use ITM for debugging, you have to remeber to change this line. The number has to fit the the microcontroller cpu frequency, which is the sysclk.

@@ -24,7 +24,7 @@ monitor arm semihosting enable
 # # send captured ITM to the file itm.fifo
 # # (the microcontroller SWO pin must be connected to the programmer SWO pin)
 # # 8000000 must match the core clock frequency
-# monitor tpiu config internal itm.txt uart off 8000000
+monitor tpiu config internal itm.txt uart off 16000000
 
 # # OR: make the microcontroller SWO pin output compatible with UART (8N1)
 # # 8000000 must match the core clock frequency

"panicked at 'attempt to subtract with overflow' ... stm32f3xx_hal/src/pwm.rs:878;1"

It is rather unfortunate, that a clock misconfiguration results into a panic. I'd love to see improvement there, but haven't had time to improve this part.

And what about the issue with USART because when i send in data from minicom or some other device to stm i get data in some other code than what i should i have received, as i mentioned i should be receiving a single interger when i send a byte instead i receive 2 integers and that doesn't make sense, maybe it something related to high pass or low pass filters idk but the output received isnt in ASCII

talalahsan01 avatar Jul 28 '20 22:07 talalahsan01

Are you using 9600 bps on your sending device? If yes, this could mean, that something in the serial implementation isn't quite correct.

Sh3Rm4n avatar Jul 28 '20 22:07 Sh3Rm4n

Are you using 9600 bps on your sending device? If yes, this could mean, that something in the serial implementation isn't quite correct.

Yes i am using 9600 bps on my device and like i said if i use the crate f3 or stm32f30x_hal the same code gives the desired output but this crate doesn't

talalahsan01 avatar Jul 28 '20 22:07 talalahsan01

Than this is clearly a bug. I'll have to investigate. Thanks for the report :)

Sh3Rm4n avatar Jul 29 '20 04:07 Sh3Rm4n

The latest update (v 0.5.0) fixed some timing issues. @talalahsan01 when updating to this version of the hal, does the error still persist?

strom-und-spiele avatar Aug 08 '20 21:08 strom-und-spiele