0

So I implemented a simple PWM on a PIC 12F617. Had to use the Compare peripheral with interrupts since I couldn't generate 50hz with the PWM module (too low frequency). I set a value to the CCPR1 register and when TMR1 reaches that value, an interrupt is firing in which I either set a pin to 1 or 0 to generate the duty cycle I want.

Now I also bitbang I2C in the main loop and here's the weird thing. I tested both PWM and I2C separately and they work fine. Once I enable them both, I2C gets completely messed (can see it on the scope), it looks like it can't pull the line low so it basically is oscillating a few millivolts below VCC when it wants to pull it down, while on other occassions it is just oscillating all over the place.

And now the even weirdest thing. While I2C alone works and stops when I enable PWM, if I disable PWM again, it won't go back to where it was before! At first I thought it was slave device acting up, but power cycling everything wont do anything. After a few hours of fiddling here and there looking for ghosts, breaking the whole circuit and assembling it again it starts to work again. So I enable PWM again and sure enough, everything is screwed again! I disable PWM and back to square 1, everything is messed and just doesn't want to work. I spent all day trying to find out whats going on, I've done this 4 times already and everytime the same story.

Anyone had this happen to them? Any advice on how to prevent PWM making everything go crazy?

John
  • 1,361
  • 2
  • 12
  • 23
  • 1
    From your description I can deduce only that *your code is bad*. – Eugene Sh. Jul 24 '17 at 21:24
  • 1
    Show the code. It's probably not **bad**, just misbehaving... – Chris Knudsen Jul 24 '17 at 21:29
  • 2
    @ChrisKnudsen Code is never misbehaving. It is doing exactly what it was told to. – Eugene Sh. Jul 24 '17 at 21:40
  • 4
    @E Yes, exactly. However, that doesn't make it so much _bad_... just misguided. The next philosophical question: Who is the victim: the code, or the creator? Or perhaps the hardware on which it lives? I suppose we're all victims. – Chris Knudsen Jul 24 '17 at 21:59
  • 1
    As a relativist, I would say that all code is equal. There is no bad code or good code, just *different* code. Who is to judge the good code from the bad code? Who is to say that "everything working" is better than "everything stops working"? – Ian Bland Jul 24 '17 at 22:14
  • 2
    John - "While I2C alone works and stops when I enable PWM, if I disable PWM again, it won't go back to where it was before! [...] *power cycling everything wont do anything*" If *only* software bugs were involved in your problem, then power-cycling everything *would* restore normal operation. Therefore based on your story so far, there *might* be more to it than just software - providing an accurate schematic would help. If I had this situation, I would work to make (a) a *minimal* software build & set of actions to reproduce the problem, and (b) a *minimal* set of hardware to go with that. – SamGibson Jul 24 '17 at 22:14
  • "*Any advice on how to prevent PWM making everything go crazy?*" Write non crazy code instead. – dannyf Jul 24 '17 at 22:07
  • I'll post code as soon as I get home. SamGibson thank you for the only sensible post. :) I stripped everything down and now I discovered that just having GP2 pin 0 or 1 (not toggling it, just setting it on startup) makes it impossible to pull down GP4/GP5 on which I have pull ups. I use these two to bitbang I2C (uC doesn't have an i2c module) and they otherwise work perfectly... Unless that is I set GP2 to 0 or 1 beforehand :/ – John Jul 25 '17 at 02:22

2 Answers2

2

Most of what you describe sounds to me as though your ic2 is throwing unmasked interrupts that you are not handling. Enabling interrupts for you PWM would then make your main loop go wonky.

Mathieu L.
  • 584
  • 2
  • 5
  • Yes definitely, investigate the interrupts. Both are using interrupts, and it sounds like some contention between the two. – rdtsc Jul 25 '17 at 00:14
  • I implemented a bitbanged i2c since this uC doesn't have one. – John Jul 25 '17 at 02:23
1

From my comment above:

If only software bugs were involved in your problem, then power-cycling everything would restore normal operation. Therefore based on your story so far, there might be more to it than just software - providing an accurate schematic would help.

It has now been confirmed that the problem is more than a software problem, so I'm "promoting" this comment to an answer.

In your follow-up question "Is my GPIO pin fried?", a hardware fault has now been confirmed with at least GPIO pin GP2 on the PIC.

SamGibson
  • 17,231
  • 5
  • 37
  • 58