espruino / Espruino

The Espruino JavaScript interpreter - Official Repo
http://www.espruino.com/
Other
2.8k stars 749 forks source link

PWM output broken on some pins on Espruino Board #328

Open SpenceKonde opened 10 years ago

SpenceKonde commented 10 years ago
>process.env  
={
      "VERSION":"1v61",
      "BUILD_DATE":"Apr 10 2014",
      "BUILD_TIME":"16:10:27",
      "BOARD":"ESPRUINOBOARD",
      "CHIP":"STM32F103RCT6",
      "CHIP_FAMILY":"STM32F1",
      "FLASH":262144,"RAM":49152,
      "SERIAL":"34ffd505-41563235-08610743",
      "CONSOLE":"USB"
    }
>

On a significant number of supposed PWM pins, any analogWrite() command results in the pin being held high full time.

For example:

analogWrite(C6,0); results in a voltage of 3.3v on the pin (static measurement). digitalWrite(C6,0); results in a voltage of 20-30mv on the pin. This does not effect all PWM pins analogWrite(C7,0); results in a voltage of 20-30mv on the pin.

C6, C8, and B0 are definitely effected. B1, C7, C9 and A7 are not.

This can be demonstrated easily with a LED+resistor between the pin and ground. Any analogWrite() to that pin will turn the LED on full-time, even analogWrite(pin,0);

gfwilliams commented 10 years ago

Thanks. Did you try this after a hard reset of the board, and did you try each pin one at time, or were you trying to get PWM on lots of pins at once?

I'll try again - but last time I tested I thought that only A9 had issues (this bug https://github.com/espruino/Espruino/issues/142).

The way the timers work on the STM32, sometimes PWM on two pins will use the same bit of the same timer, so it can't be done. Ideally Espruino would know - but there's quite a complex relationship in the hardware.

SpenceKonde commented 10 years ago

Okay, it appears to require a hard reset to clear (I didn't realize that reset(); was not sufficient here), and it's caused by timer conflicts.

I made a little board with some LEDs on it to test this with, and so far I've found the following:

C8 and B0 are mutually exclusive. Setting one turns the other off. A6 and C6 are mutually exclusive. Setting one turns the other off. C7 is linked to B0 (unpredictable behavior) A7 is linked to C6 (unpredictable behavior) B1 is linked to C8 (unpredictable behavior) A9 is always broken A8 is linked to B13, and kills SPI2, preventing SD card access

gfwilliams commented 10 years ago

As you've got the board now, I don't suppose you could test this with the latest from GitHub? The situation should be a lot better (but still not perfect)

SpenceKonde commented 10 years ago

Sure, I'll give it a try with the github build tonight and see how things look

On Mon, Apr 28, 2014 at 11:46 AM, Gordon Williams notifications@github.comwrote:

As you've got the board now, I don't suppose you could test this with the latest from GitHub? The situation should be a lot better (but still not perfect)

— Reply to this email directly or view it on GitHubhttps://github.com/espruino/Espruino/issues/328#issuecomment-41574759 .

SpenceKonde commented 10 years ago

Definite improvement!

A8~A10 no longer break pins B13~15; A0~A3 all go on TIM5 (like we talked about in that thread), and C6~9 all seem to go on TIM8.

There is still a conflict between C6/A7 and C8/B1 C6~9 is now using TIM8 (like it should), but A7 and B1 try to use the negated channels of TIM8 when you try to get PWM out of them instead of TIM3 like they ought to be using: analogWrite(C7,0); =undefined

:peek16(0x40013420); =17 analogWrite(C8,0); =undefined

:peek16(0x40013420); =273 analogWrite(A7,0); =undefined

:peek16(0x40013420); =276 //this turned on the negated channel of TIM8 on pin A7

If A6/A7/B0/B1 were all to default to TIM3, I think that would solve all the remaining avoidable conflicts.