PWM Generation without using the PWM Mode of timers

[SRama.2]

Hi everyone. As the title suggests this might come across as an odd request. Basically I have been given a fully completed board with the microcontroller already placed on it.

I was asked to use it to generate PWM's from it and control a full bridge circuit with four MOSFETs. After some research, I figured out that the easiest way is to use the method described in the manual for generating complementary PWM's with dead time.

But then I ran into an issue. To generate the PWM's I use the TIM1 CH1 and CH1N channels. I understand that, I can get the PWM signals generated by this timer from a few output pins on the microcontroller. But unfortunately the board is designed in such a way that the outputs from these complementary channel pins are not connected to corresponding complementary MOSFETs in my circuit. So I cannot simply use the inbuilt PWM generation capabilities. So here are my questions,

1. Are there any super obvious workarounds for this problem that are skipping my mind or I just cannot think off?
2. How do I go about solving this and what would be the most efficient? Here were some of the ideas I could think off or I got from the internet

• Ignore the PWM capabilities but just read the timer count values to manually generate PWM signals through a GPIO? Even for a beginner like me, this seems not very efficient. And I Ifeel like it might not work for some reason that I dont know yet.
  • I read somewhere else that I could fire interrupts at specific instances and kind of redirect the PWM signal to a GPIO pin. (https://electronics.stackexchange.com/questions/115946/how-do-i-redirect-timer-output-for-stm32f10x-to-a-given-gpio-pin) But I also read that using interrupts is also not particularly efficient
  • Somehow configure like two timers. One timer measures the dead time and at the end, triggers the other timer that generates the PWM and it triggers the dead time timer again. This would be super convenient but I am yet to look up whether this is even possible to do.

To summarize, this question is light on code because it is only the first solution that I have written the code for and I have not gotten a chance to see if it will work. I was hoping there was some way to fix this that I dont quite know about.

Any help is much appreciated :)

PS - I am still rather new to hardware programming. So please go easy on me if I am misusing some terms or my ideas wont work. xD

[S.Ma]

Short the right pins with the wrong ones. Then keep the unneeded ones as input.

Don't toggle the pins by SW, you will get jitter caused by higher priorty interrupts when code is running.

[waclawek.jan]

Use timer-triggered DMA from memory to GPIO.

But it's probably better to redesign the hardware in the proper way.

JW

[Piranha]

Electronic engineers have not done their job right. The board is flawed and must be redesigned!

[S.Ma]

Agreed, but by hacking the board with shorting pins enables progress of HW debug the V1 board and minimize further reworks of V2.

Exploit as much as possible with minimal effort V1 board to clear as many issues before respin.

[TFlac]

Technically speaking you should be able to do anything with a Microcontroller. The mere fact that the controller is hampering this effort is surprising to me. Yes, I am new to this new way of programming, super high level HAL abstracts that hide the lower level operation. As I said I am new to this higher level and think getting to know the LL (low level) drivers will be advantages in the long run. Back in the 1980s we had to learn and know what every register did, we programmed using ASSEMBLY language. The things you could do with a MCU were unlimited because we design at MACHINE hardware level.

As I proceed with my new designs I will make it my effort to learn as much as possible of the mechanics of the processor and LL design flow. The 6502 and 8051 processor ruled the world with lower level ASSEMBLY code for 50 years and is still in use. The ARM core is now the new hot topic today so we must move forward, but not too far from the hardware mechanics of the processor.

[S.Ma]

The generation of programmer and their background is evolving. SW Tools like compilers improved so that assembler is avoided at minimum penalty over C.

I think here we are talking about a lack of HW crossbar mux on the alternate function pins (SmartIO-like feature) which sometime enables pin hungry peripherals to be useable in smaller packages / cost.