Problem with encoders after migrating from LPC17 to STM32F4

[jjonas]

Hi,

I decided to migrate from the LPC17 based core to the STM32F4 based one. After doing that I noticed that encoders 13-16 and the data wheel work now only in one direction, and move several steps each time. All other encoders and buttons seem to work ok as far as I can tell. I'm using the Wilba front panel and the settings file for it. The LPC17 based core has worked ok with the same front panel. What I have connected to the core (both new and old) is the SD card (J16), the displays (J15A + J15B) and J8/9 + J19. Both cores are running the firmware v4.089 and identical hw setup files (the default ones for Wilba front panel from the firmware zip on ucapps). Both cores are running on USB power.

If I switch the front panel between the old core and the new one (SD card connected to J16 in both cases), the old one always works normally, but the new one has the problem I described above.

(As an extra quirk, with the new core, in addition to the problem described above: the encoders 9-12 are also really fidgety if the panel is on my computer desk, but if I have the panel on the floor or if I hold it in my hand, there's no such problem. When the panel is on the desk with the encoders fidgeting, it doesn't matter whether I touch it or not. The STM32F4 core location doesn't seem to matter. With the old core it doesn't matter where the panel or core is located, all works ok. But I'm not really after a solution for this, thought just that I'd mention it.)

I tried using the default hardware configuration file from newest firmware package (instead of my old own one which has a few customisations), but it didn't make a difference. I tried changing the hw setting file's encoder DETENTEDx setting but none of the setting were helping, all settings 1-5 produced completely unusable results (sometimes the turn of one encoder triggered change in a neighbouring step as well!)  I couldn't get back the normal behaviour I had with the old core, and still have, if I just switch the ribbon cable connectors to the old core (DETENTED3 works there).

The misbehaving encoders are attached to shift registers 5 (GP encoders) and 6 (data wheel) on the panel, I wonder if this has anything to do with it. Probably not, I doubt there's anything wrong with the panel as it works flawlessly with the LPC17 core. I scanned the STM32F4 for soldering mistakes but couldn't find any. I replaced the 74HCT541 on the STM32F4 to see if that was the cause of miscommunication – after all that's the IC that's communicating with J8/9 and J19 – but it didn't make any difference. I'm not sure where else to look.

[FantomXR]

Did you tried to disconnect the displays (J15A/B) for now and only use J8/9 for testing?

[jjonas]

Hi,

if I don't have the displays connected, how can I tell how the encoders behave?

Anyway, I disconnected J19 but left the displays, SD card and J8/9. Now the problematic encoders are working, including data wheel. Apparently all encoders and buttons are now working, so I think I was under the false impression that the panel PCB connector J2 must be connected to J19.

What is the purpose of the J2 connector on the panel PCB? Wilba's construction page mentions only it's connected "to additional control elements in the Chain". I don't know what that means. According to the STM32F4 schematic, J19 is "for AOUT and similar 5V based SPI Devices", and actually now that I checked, the LPC17–MBSEQ4 connection guide shows that J19 is used for AOUT. I don't remember anymore why I connected LPC17 connector J19 to panel connector J2, I must have thought it's necessary (perhaps I was thinking one is DIN and the other is DOUT). At any rate it didn't cause any problems.

Anyway, based on quick testing, everything seems to be working now with J2–J19 disconnected. Thanks!