NUCLEO H755ZI-Q - Clock Configuration Question

[Sebastian_R]

Hello everyone, 

I'm having a hard time with the clock configuration on my NUCLEO board, which is probably related to my limited experience with STM32, so apologies if it's a dumb question.

I was testing around with said NUCLEO board and the STM32CubeIDE. I loaded up the preset for the board and got my testcode working. Then I noticed, that the SYSCLK was set to 64MHz by default. Since the CPU1 can go up to 480MHz I tried increasing that value to 400MHz and let CubeIDE find a solution. I updated the prescalers for my peripherals and timers and uploaded the code again.

But after the increased clock-frequency, most of my code broke. Timers 3-5 seem to work as expected, but for example Timer 2 is set to ellapse after 800 counts which at 200MHz should equal 4µs, seems to have a duration of 8µs when setting a pin and observing with an oscilloscope. Also lots of steps seem to be skipped, since my generated pattern is missing more than half of it's pulses (the toggling is done when Timer 2 ellapses).

This seems highly counterintuitive to me, since in theory I just sped up the CPU. Is it maybe a limitation of the NUCLEO board? I'm currently using the stock board and powering it via USB and the ST-Link debugger. 

I've attached both IOC-files so if someone could take a look and give me some hints, it would be greatly appreciated. 

Thanks in advance,

Sebastian

[SofLit]

Hello @Sebastian_R ,

The second part of your description is not clear:

---

@Sebastian_R wrote:

But after the increased clock-frequency, most of my code broke. Timers 3-5 seem to work as expected, but for example Timer 2 is set to ellapse after 800 counts which at 200MHz should equal 4µs, seems to have a duration of 8µs when setting a pin and observing with an oscilloscope. Also lots of steps seem to be skipped, since my generated pattern is missing more than half of it's pulses (the toggling is done when Timer 2 ellapses).

---

Could you please elaborate? what kind of pattern you are generating? I suggest to share your code.

---

@Sebastian_R wrote:

Also lots of steps seem to be skipped, since my generated pattern is missing more than half of it's pulses (the toggling is done when Timer 2 ellapses).

---

It depends on how you generate the pattern. It could be that the timer is faster than your pattern generation mechanism.

[Sebastian_R]

Hello SofLit,

in short what I'm trying to do, is generate a manchester-encoded pattern and drive an output pin with that pattern. That does work, when I use the MCU with 64MHz of CPU clock. I've attached measurements with both configurations and as you can see, it works properly with 64MHz and using the same code, just the different clock configuration, gets all messy when going up to 400MHz (or any other frequency I've tested so far).

I've also attached the code and boiled it down to the functions used for this test. Pattern generation is done using TIM2 & TIM3, where TIM2 switches the bus and TIM3 starts different time slots. The starting points generated by TIM3 are correct, it's just the actual pattern no longer working. TIM5 sends an interrupt every 500µs and one cycle of the pattern. I've also since checked, that TIM2 seems to ellapse every 4µs, so thats working, but switching of the bus gets skipped often so the bus stays in its past state longer.

Hope this clears things up a bit, but I'll also provide further information if needed.  

 

[SofLit · Accepted solution]

Forget about manchester genaration for now.

If you toggle just a pin in TIM2_IRQHandler(), do you see the same behavior?

[Sebastian_R]

Good point, if I just toggle the pin, I see the expected behaviour, but as soon as I add in the slot again, the amount of toggles varies. So it must be something with my counter variables (bitCounter or nextSlot), as in the debugger I can sometimes see faulty values. Out of couriosity I checked the runtime of my conversion function and that finishes way before the actual transmission starts, so probably no delays here. 

It must have something to do with either one of the arrays the data is stored in or one of my counter variables. I thought that declaring them as volatile might be enought, but it seems otherwise. If you have any suggestions of the top of your head, I'd be very glad, but you've helped a lot already, so thank you for that.

And I still can't wrap my head around why it would be running fine on the lower CPU clock.

[Sebastian_R]

After some more testing, I think i finally figured it all out. Thank you very much @SofLit for your kind help, much appreciated. 

It seemed like one of my variables, which was accessed in two different interrupts, sometimes got overwritten or set with faulty values. I changed the code to only access that variable in one interrupt and now everything works. 

Again, many thanks for your kind help and guiding me in the right direction