Bare6-9 feedback
General feedback
Removing the "** Your answer here **" flags make it harder to find your answers in the code, keep those to make things easier for your reviewers.
Bare6
From 0
"`This should not be a problem, since the frequency is in range and they are valied numbers." - They are valid numbers, but not compatible. There's no scaler (1 * 2^x, x = 0,1,2,3,4) which transforms 84Mhz to 64 Mhz (84 * (1 / Scaler) = 64).
"I get the error "Frequency searched for is out of range for this VOS range when changing PCLK1 from 32 to 64" - Reflect on why you get this error, this is correct behaviour, but why does it happen?
"When I chnage pclk2 to 64 the other sysclk chnages to 64 and pclk1 changes to 32." - Correct, and why does this happen?
From 2
"3.91 MHz" - This is your reading, yes. Look into the code, there should be a scaler somewhere in there set to 4. Your answer should be reading * scaler.
"4.8 V" - This seems a bit high, but we also got some rather high numbers. It should be around 3.3V as that's what it should be running at.
From 3
"3 Hz (ociloscope: 11.9 MHz or 12 MHz)" - This is correct, but show some calculations. It's hard to see if you simply looked at the blinking and came up with the correct frequency or if you calculated it.
From 4
"12 * 4 = 48 MHz (roughly rounded)" - This is correct, the same scaler should be used in the earlier example.
"4.9 V" - This value seems high, but like I said earlier we also had some high values. It should land somewhere around 3.3V
From 6
"Yes, I suppose?" - This is wrong, as the necesary scaler between 84Mhz and 64 Mhz isn't reachable. Look into CubeMX under clocks, there you'll find the necessary information regarding this.
Bare7
It seems like your code should work, but you didn't use split() in lateresources like I did: gpioa.split().pa5.into_push_pull_output()
Your code should work still, since you split the gpioa itself. Comment your code.
Bare8
Putty should work just fine. The tracing will add extra cycles to treating each byte which we receive and the more tracing and prints we add the more errors you should get.
Your results seem correct. During release the compiler will optimize the code to the best of it's abilities, so it should perform better than it's debugger counterpart which yours did.
Bare9
There's a few optimizations you can make here. It's weird that you managed to crash the system, though... It should be very hard at least, write a bit more about how you did that.
When an error occurs you do this: "cx.spawn.trace(false,data).unwrap();", which strikes me as odd. Why are you spawning your non-data?
You can also "optimize" out the received data counter and print, since we're only really interested about the failure of receiving data, right? What's the point of the system telling us that everything's fine (after we've confirmed that we can receive all 16 bytes without any issue)?
You could also move the prints to a separate lower prioritized task. (What priority should this task have?)