preenfm Forum
PreenFM => preenfm2 and preenfm3 => Topic started by: lokki on December 09, 2020, 02:02:07 PM
-
i can't see my preenfm3 via usb-midi connection in 0.99b could that be?
-
hmm, the preenfm3 does not show up as midi device...
but i can update/downgrade the firmware just fine, so that means communication is working fine. i am sure this was working before.
i tried 0.91, 0_97 and 0_99 and they all don't show up on my mac. will investigate further...
-
ok,
ioreg -p IOUSB -l -w 0
gives me:
+-o preenfm3@14200000 <class AppleUSBDevice, id 0x10000ce78, registered, matched, active, busy 0 (7 ms), retain 31>
{
"sessionID" = 427533152208158
"iManufacturer" = 1
"bNumConfigurations" = 1
"idProduct" = 22336
"bcdDevice" = 256
"Bus Power Available" = 250
"USB Address" = 14
"bMaxPacketSize0" = 64
"iProduct" = 2
"iSerialNumber" = 0
"bDeviceClass" = 0
"Built-In" = No
"locationID" = 337641472
"bDeviceSubClass" = 0
"bcdUSB" = 272
"USB Product Name" = "preenfm3"
"PortNum" = 2
"non-removable" = "no"
"IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
"bDeviceProtocol" = 0
"IOUserClientClass" = "IOUSBDeviceUserClientV2"
"IOPowerManagement" = {"DevicePowerState"=0,"CurrentPowerState"=4,"CapabilityFlags"=32768,"MaxPowerState"=4,"DriverPowerState"=4}
"kUSBCurrentConfiguration" = 1
"Device Speed" = 1
"USB Vendor Name" = "Xavier Hosxe"
"idVendor" = 1155
"IOGeneralInterest" = "IOCommand is not serializable"
"IOClassNameOverride" = "IOUSBDevice"
}
and yes i have Usb Midi enabled in the config menu (In/Out)
-
Will take a look at that on my mac.
-
don't actually! after a reboot to linux (dual boot system) it started working again, also on osx. so it seems to be an osx oddity...
-
argh...it just happened again. OSX is not recognising the preenfm3 anymore.
-
i suspect it is my macbook air actually. i had an issue with a preenfm2 and a garbled display that was only present on the air. i guess the usb ports just don't deliver enough "juice"...
how much power does the preenfm3 need?
-
Xavier, would it be possible for you to reimplement the screen dimming feature? this would allow me to run the preenfm3 from my air. and honestly I liked the backlight a bit dimmer then full brightness...
-
ok, so...
it seems this is not related to my macbook air after all. i cannot get my preenfm3 to be seen on any other computer as well!
so usb-midi is broken for me.
symptoms:
preenfm3 turns on normally
osx does not see the preenfm3 as midi device, it is not even recognised as usb device via: ioreg -p IOUSB -l -w 0 in terminal.
putting it into DFU mode (with jumper set) it is recognised by ioreg -p IOUSB -l -w 0 and i can flash firmware.
i guess communication is working so it is not a hardware issue, right?
anything i can try? i know this was working before, so it seems really strange.
-
I can see the preenfm3 on my macbook (Big Sur / Was working in previous catalina 10.15).
I tested the pfm2 editor (when can mainly work with pfm3).
I verified it's visible in ableton live 10.
And also in MacOs>Utilities>Audio Midi Setup> Midi Studio.
So I don't know what i can do here.
What application did you try ?
I forgot to reply to some questions :
how much power does the preenfm3 need?
300mA.
Xavier, would it be possible for you to reimplement the screen dimming feature? this would allow me to run the preenfm3 from my air. and honestly I liked the backlight a bit dimmer then full brightness...
I tried to remove all what could lead to electornic noise.
I may put it back when i'm sure it does not decrease TFT stability.
(Lowering the brightness requires sending a PWM message to the TFT led at 100Khz)
-
ok thanks.
is there any difference in USB communication between the DFU mode and regular synth boot up?? can one fail and the other work? from a hardware point of view, the connections are exactly the same, so if one works, the other should work as well, right?
i really don't know what to try here...
i tried with puredata, but i can also not see it in audio midi setup (well i can see that it was once online, but not anymore)
i don't know about the tft, does not seem to make a difference after all. i am just baffled it used to work, and not anymore, i did not change anything on the preenfm3 except for firmware upload...
-
is there any difference in USB communication between the DFU mode and regular synth boot up?? can one fail and the other work? from a hardware point of view, the connections are exactly the same, so if one works, the other should work as well, right?
Yes the connection is exactly the same.
USB is only 1 data lines (on 2 differential wires).
But they require totally different driver. And USB is all about drivers.
I don't know if there's a way on MacOS to see what USB drivers is in use for the different devices.
-
Yes, put the command I wrote above into a terminal...
ioreg -p IOUSB -l -w 0
It will give you a list of all devices and the driver it uses etc. preenfm3 is not even listed here when I boot it normally. I will next try to boot without usb power and a wall wart supply to see if it changes something.
-
ok, with a wall wart (and the jumper set to dc in) it is also not recognized.
Hmm...will try a reflash. could a bug in the bootloader prevent usb midi from working? or is the usb stuff completely in firmware?
-
Not sure reflashing will change anything.
The bootloader might change some clocks that prevent the firmware from working. But i doupt it's the case.
Will check anyway.
-
Is there a debug mode available that could show me this info somehow?
The clock frequency i mean... Will boot up Linux later, since I am more familiar with lsusb and dmesg...
-
I just tried also on my work macbook (10.15.5) and it also works fine. I can see "preenfm3" in the MacOS "midi studio".
It will give you a list of all devices and the driver it uses etc. preenfm3 is not even listed here when I boot it normally. I will next try to boot without usb power and a wall wart supply to see if it changes something.
I don't understand, in your message #2 you list the output of the command that shows the preenfm3.
Now you say it does not show up. Did it stop working ?
it seems this is not related to my macbook air after all. i cannot get my preenfm3 to be seen on any other computer as well!
What is this other computer ?
Have you tried with an other USB cable ?
-
I have tried with several cables. That output was of one time it was working(approximately one out of 30 times it works).
In dfu mode it works every time which really makes me think it is not a hardware issue.
I have access to several macs, some with Linux other with osx on them. Will try to find a pc with windows on it...
-
Ok on Linux it is better, it works one out of 10 I would say :) no pattern...
-
EDITED : What i wrote here is wrong.. the preenfm3 midi driver actually uses the internal 48Mhz. Not a derived PLL from the 8Mhz crystal as i wrote in this message.
I have tried with several cables. That output was of one time it was working(approximately one out of 30 times it works).
In dfu mode it works every time which really makes me think it is not a hardware issue.
I have access to several macs, some with Linux other with osx on them. Will try to find a pc with windows on it...
I thought about what can be the difference between DFU and Usb MIDI, and it can be a hardware problem.
USB requires a precise 48Mhz clock.
The DFU is built in in the STM32H7 and use a internal clock, the MIDI use the pfm3 8Mhz crystal to build the 48Mhz.
(The "USBKey access from computer" in the bootloader also use the pfm3 8Mhz crystal, does it work reliably ?).
Can you boot in the bootloader, then simply click reboot and see if it's better ?
If yes, that would mean your crystal needs a bit more time to stabilize.
-
Interesting...
The SD Card access from bootloader is slow but it works reliably. I can copy files, delete them or create new folders...
This seems to rule out a hardware issue.
The bootloader reboot thing did not help, the preenfm3 is still not recognized.
-
sd card access gives me this:
+-o STM32 Mass Storage@14100000 <class AppleUSBDevice, id 0x100000a38, registered, matched, active, busy 0 (3 ms), retain 21>
{
"sessionID" = 1922088129427
"iManufacturer" = 1
"bNumConfigurations" = 1
"idProduct" = 22314
"bcdDevice" = 512
"Bus Power Available" = 250
"USB Address" = 14
"bMaxPacketSize0" = 64
"iProduct" = 2
"iSerialNumber" = 3
"bDeviceClass" = 0
"Built-In" = No
"locationID" = 336592896
"bDeviceSubClass" = 0
"bcdUSB" = 512
"USB Product Name" = "STM32 Mass Storage"
"PortNum" = 1
"non-removable" = "no"
"IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
"bDeviceProtocol" = 0
"IOUserClientClass" = "IOUSBDeviceUserClientV2"
"IOPowerManagement" = {"DevicePowerState"=0,"CurrentPowerState"=3,"CapabilityFlags"=65536,"MaxPowerState"=4,"DriverPowerState"=3}
"kUSBCurrentConfiguration" = 1
"Device Speed" = 1
"USB Vendor Name" = "STMicroelectronics"
"idVendor" = 1155
"uid" = "USB:0483572A375F35743030"
"IOGeneralInterest" = "IOCommand is not serializable"
"USB Serial Number" = "375F35743030"
"IOClassNameOverride" = "IOUSBDevice"
}
with the above command...
DFU:
+-o DFU in FS Mode@14100000 <class AppleUSBDevice, id 0x100000a8b, registered, matched, active, busy 0 (2 ms), retain 16>
{
"sessionID" = 2206053589421
"iManufacturer" = 1
"bNumConfigurations" = 1
"idProduct" = 57105
"bcdDevice" = 512
"Bus Power Available" = 250
"USB Address" = 15
"bMaxPacketSize0" = 64
"iProduct" = 2
"iSerialNumber" = 3
"bDeviceClass" = 0
"Built-In" = No
"locationID" = 336592896
"bDeviceSubClass" = 0
"bcdUSB" = 512
"USB Product Name" = "DFU in FS Mode"
"PortNum" = 1
"non-removable" = "no"
"IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
"bDeviceProtocol" = 0
"IOUserClientClass" = "IOUSBDeviceUserClientV2"
"IOPowerManagement" = {"DevicePowerState"=0,"CurrentPowerState"=3,"CapabilityFlags"=65536,"MaxPowerState"=4,"DriverPowerState"=3}
"Device Speed" = 1
"USB Vendor Name" = "STMicroelectronics"
"idVendor" = 1155
"IOGeneralInterest" = "IOCommand is not serializable"
"USB Serial Number" = "200364500000"
"IOClassNameOverride" = "IOUSBDevice"
}
and normal boot shows nothing, nada, rien :-)
-
ok, did another firmware reflash to 0.97 and usb-midi works again, strange.
did re-update to 0.99b and it works for 2 or 3 reboots and then stops working again. really f***ing strange.
will have to reflash 0.97 and do more then a couple of reboots to check if it is really reliable then.
-
will have to reflash 0.97 and do more then a couple of reboots to check if it is really reliable then.
Yes that would be interesting.
-
Unfortunately I can confirm, that 0.97 is also only working VERY sporadically.
Interestingly it always seems to work after the firmware upload...so the first boot is ok. I wonder how and why that could be, since I unplug the preenfm3 in between and set the jumper...
-
this is from one time it worked:
"sessionID" = 3911869770800
"iManufacturer" = 1
"bNumConfigurations" = 1
"idProduct" = 22336
"bcdDevice" = 256
"Bus Power Available" = 250
"USB Address" = 3
"bMaxPacketSize0" = 64
"iProduct" = 2
"iSerialNumber" = 0
"bDeviceClass" = 0
"Built-In" = No
"locationID" = 336592896
"bDeviceSubClass" = 0
"bcdUSB" = 272
"USB Product Name" = "preenfm3"
"PortNum" = 1
"non-removable" = "no"
"IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
"bDeviceProtocol" = 0
"IOUserClientClass" = "IOUSBDeviceUserClientV2"
"IOPowerManagement" = {"DevicePowerState"=0,"CurrentPowerState"=4,"CapabilityFlags"=32768,"MaxPowerState"=4,"DriverPowerState"=4}
"kUSBCurrentConfiguration" = 1
"Device Speed" = 1
"USB Vendor Name" = "Xavier Hosxe"
"idVendor" = 1155
"IOGeneralInterest" = "IOCommand is not serializable"
"IOClassNameOverride" = "IOUSBDevice"
do you get the same readings and values? i.e. power state etc.? and bus power available?
from the packet size it looks like you made the device usb 1.1 compatible, right? could you make it usb 2.0 with 512 bytes packet size?
-
What i get is
+-o preenfm3@14200000 <class AppleUSBDevice, id 0x100000387, registered, matched, active, busy 0 (0 ms), retain 16>
{
"sessionID" = 1697173677
"idProduct" = 22336
"iManufacturer" = 1
"bDeviceClass" = 0
"bMaxPacketSize0" = 64
"bcdDevice" = 256
"iProduct" = 2
"iSerialNumber" = 0
"bNumConfigurations" = 1
"Bus Power Available" = 250
"USB Address" = 5
"Built-In" = No
"locationID" = 337641472
"bDeviceSubClass" = 0
"bcdUSB" = 272
"USB Product Name" = "preenfm3"
"PortNum" = 2
"non-removable" = "no"
"AppleUSBAlternateServiceRegistryID" = 4294968197
"bDeviceProtocol" = 0
"IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBHostFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
"IOPowerManagement" = {"DevicePowerState"=0,"CurrentPowerState"=3,"CapabilityFlags"=65536,"MaxPowerState"=4,"DriverPowerState"=3}
"kUSBCurrentConfiguration" = 1
"Device Speed" = 1
"USB Vendor Name" = "Xavier Hosxe"
"idVendor" = 1155
"IOGeneralInterest" = "IOCommand is not serializable"
"kUSBProductString" = "preenfm3"
"kUSBVendorString" = "Xavier Hosxe"
"IOClassNameOverride" = "IOUSBDevice"
}
If you unplug the TFT, the current required will be 50mA lower. You can give it a try, to see if that makes a difference.
-
An extra datapoint if it helps:
Just tested my preenFM3 on v100 - I can't see the preenFM3 over USB either. (MacOS 10.15.7, Macbook Pro 13” early 2015)
As a sanity check - same cable, port; Mac sees the PreenFM2 (pcb R6, latest fw) with no problems
-
OK, I'm able to reproduce it on my Linux machine.
My current dev pfm3 does not have this problems which is my excuse for being slow on this one ;) My 2 others have it.
Usb is great for users, but a nightmare for devs.
Now i have to investigate :-\
-
Can you try the attached firmware when you get a chance ?
Thanks
-
Oh boy, thanks! Great to know, that I am not alone :) will try the firmware asap
-
hey xavier, it seems stable now! great!! i rebooted about ten times, it worked every time.
curious, what did you change?
-
ok i see it on GitHub, wow how did you manage to find that out so quickly? it seems like a really unobvious thing...or did you have an old unoptimised firmware that was running nicely and you took it from there?
-
Haha... It was interesting an i learnt many things :)
I said previously that my development pfm3 did not have this problem although my others have the problem.
I realized it's simply because my dev pfm3 has the debug version of the firmware (without full optimization).
I searched a bit on the web, and found interesting articles why optimizations can break drivers (by reordering or even skipping variable value assignation).
This one is very good (not specific about drivers though) :
https://blog.regehr.org/archives/28
My first try was to try to add the pragma line in the STM32 USB code :
#pragma GCC optimize ("-O1")
And It worked :)
With O2 it also worked. with O3 it stopped working, and O3 is the default optimization flag for the release version of the firmware.
So the fix is simply this line :
https://github.com/Ixox/preenfm3/blob/v0.101/firmware/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_ll_usb.c#L48
--
Also I also wanted to come back to something i said :
The Midi drivers does not use the 8Mhz external crystal. It could, but in the preenfm3 the 48Mhz USB clock is wired on the HSI (high speed internal).
https://github.com/Ixox/preenfm3/blob/v0.101/firmware/Src/main.c#L263
It's good enough for the low speed USB involved.
Thanks again for pushing this problem.
-
What is really strange about all this, is that it still sometimes worked before, so the code was only partially broken? or variable ordering is dynamic even after compile time? puzzling...
btw, teensy 4 use a similar chip, no? they use usb2 for midi communication, maybe that would be more reliable with -O3
-
What is really strange about all this, is that it still sometimes worked before, so the code was only partially broken? or variable ordering is dynamic even after compile time? puzzling...
btw, teensy 4 use a similar chip, no? they use usb2 for midi communication, maybe that would be more reliable with -O3
No there's not dynamic ordering at run time in the cortex-M7.
I assume it's a problem of race condition between the main USB interrups and other threads. So sometimes it worked, depending when the first USB interrupts are called during the init process.
Just had a look, the teensy 4 use a NXP iMXRT1062 (the pfm3 use a STM32H743)
The CPU/core part is also a ARM cortex-M7. But all the rest (hardware implementation, registers, interrupts etc...) is different.
Midi is SUPER SLOW (31Kbits/s). The slower USB is 1.5Mbits /s so we're good (50 times faster).
And i'm confidant that using -O2 on this low level driver won't have any perf impact.
But it could be interesting some day in the far future to understand why the USB access from computer is so slow.
-
DIN midi has a baudrate of 31250, true. But USB midi can run at up to 480mb (usb 2) and some newer synths and controllers use that! If you have lots of modulation that can make a big difference. Usb 1 is also not very tight, given it has a polling interval (at least 1ms I believe) and hence midi clock is not very precise from usb...
-
DIN midi has a baudrate of 31250, true. But USB midi can run at up to 480mb (usb 2) and some newer synths and controllers use that! If you have lots of modulation that can make a big difference. Usb 1 is also not very tight, given it has a polling interval (at least 1ms I believe) and hence midi clock is not very precise from usb...
Midi Din5 is even worse : 0.7ms per note on or midi CC. Even USB1 can send 64 bytes every ms so much more information.
I was talking about the slower USB 1 which is still much better than DIN5, not the one the preenfm3 is using.
The preenfm3 uses "USB 2.0 12Mbits Full Speed" specification (with 1ms polling).
I would like someone to try sending 480mb/s of note on and midi CC to any synth :D
480mb/s works with a 0.125ms polling which is CPU intensive even when doing nothing...
-
I know I know. Still for clock DIN midi is better then usb, since a unsteady clock (caused by the 1ms polling) can mess with arps etc.
that aside, I am very happy the preenfm3 works over usb now and that it was such an easy fix! Thx.
-
Unfortunately, I just tried with the latest fw posted on page 2 (0.100z) and it still isnt working for me.
-
is your preenfm3 also always visible when in DFU mode?
-
Unfortunately, I just tried with the latest fw posted on page 2 (0.100z) and it still isnt working for me.
Please, confirm you see "0.100z" in the top right of the menu ?
In Menu > Config. Check Usb Midi is set to "In/Out".
After that double check you midi jack soldering.
-
It was flashed ok in DFU mode (was visible each time I set the jumpers to pullup the boot to VCC) so I suspect the soldering of the USB socket is ok (I also checked it under a microscope after cleaning the flux when I built it). It would be odd to be a soldering issue if it can be flashed over USB, wouldnt it ?
I previously checked it was the 0.100z fw (as shown on the screen) when I tested it earlier tonight
I also checked USB Midi was set to In/Out when I tested it earlier.
I wont have time to take it out of the case and examine the soldering again until the weekend.
I have got a development build going with stm32cubeide and have an stlinkv2 so if I get time over the weekend I can also look at debugging but I will double check the soldering...
-
It would be odd to be a soldering issue if it can be flashed over USB, wouldnt it ?
Correct. If flashing over DFU works, then midi should work. No need to examine again.