Nokia5110 LCD on SPI2, C4, C5, A3 fails after analogWrite() to A8 (!?)

I have my Nokia5110 display hooked up on SPI2, with CE on C5, DC on C4, and RST on A3.

I'm doing a bunch of stuff with it, and everything is working great - until I do an analogWrite() to A8.
After that, when I call g.flip(), the screen display scrambles and the LCD needs to be powercycled.

It doesn't seem to happen with any other PWM pins... (I tried the C's right near it, and the A's and B's in the middle)... but A8 does it reliably. Usually I see pieces of the image, but in the wrong place on the screen, but I've also seen it simply blank the LCD as well.

Any thoughts? I can easily work around it, but I figure it's symptomatic of a deeper issue...

Using the v60 from march 28th (because I needed eth.setIP())

<<<<<{"VERSION":"1v60","BUILD_DATE":"Mar 28 2014","BUILD_TIME":"18:14:28","BOARD":"ESPRUINOBOARD",
"CHIP":"STM32F103RCT6","CHIP_FAMILY":"STM32F1",
"FLASH":262144,"RAM":49152,
"SERIAL":"34FFD505-41563235-08610743","CONSOLE":"USB"}>>>>>

Edit - formatting. You know you've been looking at js too long when you start using semicolons at the end of sentences instead of periods...

Hmm... That is interesting... I wonder whether it's because of the way peripherals are mapped in the STM32F1...

Basically a lot of peripherals can be in two different places. On the STM32F4 parts this is done the way you'd expect - for each pin, you specify what peripheral goes to it. On the STM32F1 it's insane - for each peripheral, you tell it either to be in position 1 or position 2, and this means that you don't get the flexibility, and you can get peripherals overlapping...

I bet what's happening is that the timer (TIM1) is outputting PWM, but it's doing so over the top of the SPI.

I don't think there's much of a way to stop it I'm afraid - about the best that can be done is making sure that Espruino knows when peripherals that are in use might be overlapping. In some cases more than one time can be used for a pin, and it might be able to use a different timer that doesn't cause problems.

There's a bug for this here: https://github.com/espruino/Espruino/issues/55

The workaround would be to use the new software SPI (available in the builds, or 1v60 when it's released).

Aaaha, okay, that makes (some) sense...

It's simple enough to work around by just picking different pins for the PWM. It would be nice to have a list of what combinations have the potential for issues like this, though.

I know. To be honest it's probably easier to write code to work it out in Espruino than it is in real life :) It doesn't help that there are a whole bunch of silicon errata notes about this kind of problem too.