stm32f3xx-hal
stm32f3xx-hal copied to clipboard
Serial Communication Issue with crate
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.
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.
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.
I just skimmed through your issue for now, but this https://github.com/stm32-rs/stm32f3xx-hal/issues/54 could be related.
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.
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
Are you using 9600 bps on your sending device? If yes, this could mean, that something in the serial implementation isn't quite correct.
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
Than this is clearly a bug. I'll have to investigate. Thanks for the report :)
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?