Search the Community

Hi...I'm am also in need of the STM32F4 CORE board and am upset modular addict is down. Located in states I am...anyone know where or how to acquire??? Thanx Danka,

Hi Everyone, Could anyone say me what are the things to do to port actually midibox stm32f4 on those board ? Is it only a question of PIN definition ? Do we have to modify cristal frequency ? Is it a long work to do ?

@Phatline now, that's a mystery - we'll find the culprit. As a bit of hopeful relief - during the dev time, i tested the LoopA on around 30 synths over here (MIDI OUT function) -> no problems with any of them. Let's narrow it down - a few ideas, in no particular order, just brainstorming: * do you have a USB power meter available? It shows the voltage of the USB bus and the power consumption of the connected device. You should measure quite close to 5.00V and a consumption of 0.50 amps, if the matias keys are illuminated. If the voltage is significantly lower or the current is higher, then something is wrong. When the case top is off, you could also measure 5V with a multimeter and check if it is significantly below 5V. * could you double check if you used 220R resistors near the OUT1-3 ports? * could you try to swap your USB cable? I've had bad cables causing strange problems, basically as the LoopA draws 500mA, you should also be able to detect this kind of problem with a drop on the 5V rail (first test) * could you remove the LoopA from its metal case and see if the problem persists (a long/uncut pin on the Core PCB could theoretically touch the case bottom and might cause a short?) * is the problem only occuring with any MIDI OUT connected to cc-looper/NordRack III or could you reproduce the problem happening also with other synths? * related: is the problem only occuring when the connected cc-looper/NordRack III devices are powered, or also when they are powered off? Is it also happening when they are powered off and not connected with their power cable to AC mains? * is the problem also occuring, if you power the LoopA via a USB power bank (no connection of the LoopA to AC mains supply)? * is the problem also occuring, if you remove the SD card from the LoopA and it enters testmode? * is the problem also occuring, if you flash the LoopA e.g. with MIDIbox MBNG (STM32F4 variant?) Just saw that Andy was quicker and posted a few other ideas - i think we should be able to figure this out. Many greets and have a good evening! Peter

@tago fully agreed! Looked into it a bit more, I think it is probably a simple linker config setting that is different between Mac/Linux/Windows - e.g. the newest LoopA version accesses a 64KB RAM block of core-coupled memory available on the STM32F4. When building on Linux, the extra RAM usage is put into the "data" segment, which is wrong: arm-none-eabi-size project_build/project.elf text data bss dec hex filename 220080 59040 123592 402712 62518 project_build/project.elf 20000000 D __ram_start 2002c968 B __ram_end This will crash the app, but it can be recovered from bootloader hold. On a Mac build, the extra RAM used properly goes into the bss segment and a ram_start_ccm linker memory region appears that is used: arm-none-eabi-size project_build/project.elf text data bss dec hex filename 220112 1440 181192 402744 62538 project_build/project.elf 10000000 B __ram_start_ccm 1000e100 B __ram_end_ccm 20000000 D __ram_start 2001e868 B __ram_end This then executes fine on the STM32F4 - if anyone (e.g. @TK. ?) knows what's the culprit, please shout - i'd otherwise investigate when there is a bit more time. Many greets, Peter

I was wondering about if/how it is possible to access different .ngc files on an SD card without using the MIOS Studio "detour". My setup consists of the STM32F4 and two external, bidirectionally connected, MIDI hardware elements, one of which is supposed to be used to control the other. The configuration of this setup is obviously defined by NGC/NGR/NGL files. I use a bunch of different ones (can be called from an omni-accessible "main"-screen) for the same setup, but if I want to choose an entirely different configuration setup I would do so by entering "load xy" in the MIOS Studio terminal. I would like to avoid that and set up a kind of "configuration" menu from which I can somehow choose between different .ngc files which I can load to the core the same way I would do by typing in "load xy" in the MIOS terminal. The goal here is to load different control files to control various hardware devices. If anyone has ever done anything like that I would love to hear how you guys accomplished that!

@tago as far as i understood, more RAM was required to drive new WS2812 LEDs, e.g. for LED-ring applications with hundreds of LEDs. As NG already requires some RAM, this then required access to the "high memory" part of the STM32F4 - its main memory is segmented in a 128kb main memory and a 64kb ("high mem") block. I guess your old NG apps that still work well don't have this addition (number of supported LEDs increased). Our toolchains in Linux and Windows seem to have trouble building an app like that - i'd guess it must be something simple like a compiler flag or such. As a solution for you and if your app does not depend on these LEDs, you could look for the git commit raising the number of these LEDs and reverting it back (just for your own app, of course). It would then require less RAM and should work again when built on Windows/Linux. Not guaranteed though, but maybe worth a try :). But this is of course no good solution - so, if someone is able to find out why it won't work under Windows/Linux (e.g. by looking at the differences to the Mac toolchain), this bit of insight would also be highly welcome from my side, as i currently need two machines for building apps that require more than 128kb of RAM :). Many greets, Peter

@latigid on thanks for the trace picture - and good idea about inspecting the waveshare! Good point to mention the crystal and cap removal and the necessary changes to the top headers there! @Altitude I'd also recommend checking, if the connection from PA11/PA12 to the STM32F4 MCU on the waveshare board itself might be interrupted for some reason, e.g. some dodgy soldering on the daughterboard header top on the PA11/PA12 pins by Waveshare :). To check with a DMM, you could visually trace these two pins back to the STM32F4 and measure directly from the MCU pin to R30/R31 on the LoopA Core, to see if there is connectivity. Just tried this, the traces are nicely visible on the Waveshare PCB and with a loupe/magnifier you can relatively easily see where PA11/12 go to the STM32F4, then you'd just need a fine multimeter probe tip to check where those two USB signal lines are interrupted on their way to R30/R31 on the core. If there is MCU connectivity to R30/R31, a last check would be to test the USB socket itself, i've never had a fault there, but there's always Murphy's Law :). I've also just compared pictures of your soldering with high-res video tutorial images of the board - can't really see a difference - i think it looks all good. Many greets, Peter

>..Before you desoldered the Waveshare daughterboard, i would have guessed the STM32F4 might have been a dud, maybe bad flash memory... But if it starts up and boots the app when powered by mini USB, that's clearly working. And as you said, it must be some connection to the USB port... I thought that too so I swapped the STM chips and it behaved the same way so it wasnt the chip. That was further proven when I took the core off and that worked by iteself. Its something on the mainboard thats hanging it up.. >did you have the onboard Waveshare power switch moved from "USB" to "5V In", when it was installed in the LoopA core? yes. now that the core is off I'll trace back to the USB socket when I get some time. Either its something stupid that I missed (likely) or some weird edge case issue (unlikely)

@Altitude Thanks for the good quality pictures - soldering really is super clean! Will compare your pictures this evening with a working core PCB and report back if i see some differences. Before you desoldered the Waveshare daughterboard, i would have guessed the STM32F4 might have been a dud, maybe bad flash memory... But if it starts up and boots the app when powered by mini USB, that's clearly working. And as you said, it must be some connection to the USB port... Question that was probably asked before: did you have the onboard Waveshare power switch moved from "USB" to "5V In", when it was installed in the LoopA core? That's the only thing that could explain it, i think - if that switch was not moved to 5V, the Waveshare board wouldn't get proper power and would not start up when powered by external LoopA Core USB. Two red small power LEDs should be lit on the Waveshare board when all is well. You made sure of that probably, but to be sure just wanted to mention it anyways :). If it's a hardware defect on the LoopA core or the Waveshare, we're glad to send you replacements of course, but it would be great to trace it and find the problem - thanks again for the tests and your patience! @latigid on: could we try to trace the USB signal pins from the STM32F4 microprocessor right to the USB port on the LoopA core? Which connections would need to be tested? Best regards, Peter

So at one point during my development of an app on NG basis on a STM32F4 core, my SesEx tool stopped working. I used it to send messages to both a Mackie C4 and a Korg M3R, which both responded in the beginning. The confusing thing is, that I can still communicate with both via my .ngc and .ngl scripts. I address them both by their ports (Macke on MIDI port 1 = 1000100000001000; M3R on MIDI port 2 = 0100010000000000) and there it works! Still something must have been misconfigured on the way and I can't imagine what, because I'm still pretty much in the beginning. I also used to get SysEx dumps form the M3R on request, which also stopped working..

Hi Florian, this sounds very good for me and meets exactly my original imagination! It fully fits to my plan and you mentioned one thing that is important: you used the same board STM32F4 for both -- the NG as well as the KB software. Out of the KB threads I assumed for a long time that it can only be realized with the LPC17 board and somehow there were some inconistencies in Thorsten's documentation that confused me. I also had a look on your github page that finally convinced me that I'm on the right track! Now I can sleep much better again and proceed with the mechanical work... Thanks & and best regards to Toulouse (I was there last time 20 years ago for business -- you have nice restaurants over there, for instance the Caves de la Marechale ), Andreas

Hi Famtom, thanks for the feedback! I was not aware of it. I have the STM32F4 Board already in place, so I guess the only chance to change to more than 16 velocity values is to change it somewhere in the NG software. Or is there any physical limitation for the 16 values instead of the 128 that can't be changed in the software? I didn't dig deep into the software yet... Right now I'm taking care about the mechanics, and as soon as this is done I'll take care about the software and electronics. My original goal was just to use what I have in place, and this is the TP/40WOOD and the STM32F407 board. Both I already got years ago, but didn't have the time to build a real master keyboard out of it. And now I have the time to build -- since my retirement approaches... Or do I really need the LPC17 core for the KB instead of the STM32F4? Thanks, Andreas

@momelq thanks Robert, that all makes sense - i'll notify you when there is a prerelease version with the temporary piano effect available for testing :). The STM32F4 is a quite powerful MCU and there are still resources left - the sequencer engine eats not up that many cpu cycles, the rest is used as a low-priority background task for the display refreshes. So, if we add a CPU-hungry subroutine on a clip, the worst that would happen first is that the screen refresh rate goes down a bit - but of course, it all depends on how complex the algorithm would be. We've also got a bit of RAM to spare (depends a bit on the resolution of the CC storage). If you want to describe the algorithm (via email is also possible), i'd be all ears, but can't promise anything! :) No temporary sustain FX then, it's probably really not necessary or could even be manually activated with separate sustain pedals of the connected synths. Have a nice evening and best regards! Peter

Hi Florian,, I have now nearly the same project in front of me: Generating -- out of a naked TP40WOOD from Fatar that I got some years ago -- a MIDI Keyboard like the Doepfer LMK4+. Doepfer charges 1500€ for this, and the solution with MIDIbox is much, much cheaper, thanks to Thorsten! I'll use the STM32F4 on a MIDIbox NG baseboard plus DIO_Matrix plus MIDI_IO plus AINSER8 (for the wheels and Pots) plus a 2x40 LCD blue plus a MBHP_DIN for the 24 Keys. So the same functions as the LMK4+ and a very similar control panel. But much cheaper. Will see how it works... Next phase is the Mechanics for the whole thing, and then the Electronics and the SW. May be I'll contact you at a later stage if I have questions. Especially the SW development might be a pitfall... Cheers, Andreas

So I am planning to build a microcontroller as an interface between a Mackie C4 Pro and, theoretically, any kind of Hardware/Software component. The component that is to be controlled will be determined, and the configurations specified, by templates which will be stored on an SD card. To realize this I will be using the STM32F4 module with the SD card interface and a MIDI 2x2 module. Eventually another 2x2 is planned to additionally connect a MIDI keyboard. I am a newbie to the MIDIbox forum so I started researching and decided to take the NG project as a starting point. To me this means that in order to implement this I need to alter the .ngc .ngl and .ngr files to a) have a communication with the Mackie that will, basically, always stay the same and b) generically prepare the other side of the microcontroller so that the user can specify the mappings to his hardware/software himself. RPN, NRPN and SysEx must be possible. This of course means that the chosen parameters and their state will be required to be displayed on the Mackie's displays, which, after reading the NG and STM32F4 specifications, I think is possible. A final requirement is that the configurations will have to be stored into a textfile (I was thinking XML) so that the user won't need to actually open the .ngc files and do his settings there, but rather that on startup the device considers the textfile as belonging to a certain configuration file, checks if something was altered in the textfile, if so applies it to the configuration data and then sets that up as the current configuration state. What do you guys think? Does that sound possible? Did I choose the right components? And has anyone ever done something similar and encountered problems that maybe I could encounter too?

Hi ! im trying to build a cheap cdj-styled usb-mp3-player with a raspberry and i went into trouble with the midi-messages from my STM32F4-Core Midibox. I got some pitchfaders, buttons and encoders which i want to use to test walmartone MIXXX(a DJ-SW)-performance. On my windows-machine everything works like a charm with Traktor. I receive the messages with the amidi -p hw:1,0,0 -d command. hw:1,0,0 is the adress of the midibox. For the pitchfaders (midipitch-message) i receive 3 bytes as desired. I use the SendPitchBend-Command for that. For Buttons (MIOS32_Send_CC) i receive lots of junk with the right message at the end: F0 00 00 7E 32 00 0D 40 42 75 74 74 6F 6E 20 38 20 67 65 64 72 75 65 63 6B 74 00 F7 BE 08 7F It should be (Channel 15 CC 08 Value 0x7F) For encoders (MIOS32_Send_CC too) there are also lots of junk bytes in the message: BE 1E 7F F0 00 00 7E 32 00 0D 40 45 6E 63 6F 64 65 72 20 30 3A 20 31 00 F7 In this case the right Message is at the beginning: (Channel 15 CC 30 Value 0x7F) How to get rid of that junkbytes? MIXXX works fine on the pitchfaders but it cant read the buttons and encoders. I already tried to compile my app without MIOS32_USB_MIDI_USE_AC_INTERFACE 1 as i need that setting for windows but there was still the junkbytes in it. Anyone experiend something like this on Linux? How to get rid of these junkbytes? For me the junkbytes doesnt make any sense. But they are always the same at the specific buttons and encoders....

Hello all, After a long time with practically no time to continue my project I have decided to downscale my project. That's why I'm selling a lot of stuff: 1x STM32F4 Core Module Board+ STM32F407G-DISC Assambled, tested and working (no sd card), use at own risk 1x MF_NG Module + PIC Assembled, tested and working, use at own risk 3x MF_NG Module + PIC Assembled (1 board missing 1 IC), not tested 1x Custom MF_NG Module (no PIC) Partly assembled, not tested 1x Custom MF_NG Module (no PIC) Not assembled 1x DOUT Module Assembled, tested and working, use at own risk 1x MIDI IO Not assembled 26x 100mm Alps Motor N fader (some o-lead, some normal lead) Unused, only mounted, no caps 2x 19 inch frontfpanel from dibond (aluminium, plastic, aluminium) 1 with cutouts for 16 faders, OLEDs and led VU meters 1 with cutouts for 8 faders, OLEDs and led VU meters and 2 Steinberg CMC cutouts Preferably selling it as one lot, but I might consider selling individual items. (I might keep de STM32F4, but not sure, defends on the offer) Make me an offer. Shipping costs for buyer.

Seq V4 for sale $600 usd. Midibox SeqV4. in great condition. STM32F4 core. It has 2 IN, 6 midi OUT and 4 midi IN & OUT on the USB (when used on a Mac). It has the OTG mod, a USB type A port to hook up controllers in host mode. Updating can still be done by switching to device mode. Modified power section to accomodate the updated core. Ultimate dawless!.

Winter time is DIY time - and this year I decided to explore the capabilities of the ESP32 platform. There might be synergies with MIOS32, but I'm very sure that I won't fully integrate this Microcontroller into the MIOS32 ecosystem --- this hasn't been considered 10 years ago when I started with the 32bit platform, and it would take too much time to make everything compatible (with many compromises - e.g. no native USB support, and we know that this is important for best performance!) However, I think that ESP32 is a pretty good companion device to a STM32F4, hence potential candidate for future MIDIbox enhancements. E.g. the NodeMCU ESP32 available at Reichelt for 10 EUR supports Dual-Core (!) @240 MHz with WiFi and Bluetooth, 512k RAM, 4MB external Flash, incl. USB programmer on PCB - compare this with a PIC18F*! ;-) I started with Bluetooth, and the result can be found here: https://github.com/midibox/esp32-idf-blemidi This so called "BLE MIDI" service should work with any OS which supports this protocol. So far only tested on MacOS and iOS... but it should also work with Linux and Win10. This will be the basis for further experiments at my side - I'm able to communicate with the device via MIOS Studio. :-) (however, application download has to be done with the ESP32 ecosystem - means: the appr. esptool.py based bootloader) In future also a WiFi connections as demonstrated in Pedalino might be possible, but I'm not there yet - focus is on the application itself, knowing that the MIDI interface options won't be so fast like known from the STM32F4 based platform. E.g. how accurate can we control a Motorfader with the PWM LED outputs of a ESP32? If it works, it could be connected like a MBHP_MF_NG module via traditional UART based MIDI to a MIDIbox NG. And will it be possible to control a SRIO chain? Might be interesting for a future BLM16x16+X with (only) optional WiFi and Bluetooth connects. Best Regards, Thorsten.

Hi Karg, I tried switching the voltage toggle to all positions on the STM32F4 but it doesn't resolve the problem. It is on 5v in. Followed the video tutorial to prepare the core. The displays appear to be 3,3v on the Midiphy shop. How can I proceed further? Thanks!

Can anyone confirm that this simple code Work/not Work? j5pinget.zipj5pinget.zipj5pinget.zip anyone with a STM32F4 can test this.... the code should not hang your device since it is only call every second. thx 4 help. #include <mios32.h> #include <FreeRTOS.h> #include <task.h> #include "app.h" // Init J5A+B Pin 0 as ANalog Input void APP_Init(void){ MIOS32_BOARD_J5_PinInit(0, MIOS32_BOARD_PIN_MODE_ANALOG); MIOS32_BOARD_J5_PinInit(4, MIOS32_BOARD_PIN_MODE_ANALOG); } void APP_Background(void) {} // Get J5A-B Pin 0 every second void APP_Tick(void){ static int seccount = 0; // init counter seccount++; if (seccount > 1000) { seccount = 0; // reset counter static s16 state = 0; // Get J5A0 state = MIOS32_BOARD_J5_PinGet (0); MIOS32_MIDI_SendDebugMessage("J5A-Pin0: %d ", state ) ; // Get J5b0 state = MIOS32_BOARD_J5_PinGet (4); MIOS32_MIDI_SendDebugMessage("J5B-Pin0: %d ", state ) ; } } void APP_MIDI_NotifyPackage(mios32_midi_port_t port, mios32_midi_package_t midi_package){} void APP_SRIO_ServicePrepare(void){} void APP_SRIO_ServiceFinish(void){} void APP_DIN_NotifyToggle(u32 pin, u32 pin_value) {} void APP_ENC_NotifyChange(u32 encoder, s32 incrementer){} j5pinget.zip

Do you mean the original STM32F1 based core: http://ucapps.de/mbhp_core_stm32.html or the more recent STM32F4 based core? Compare: http://ucapps.de/mbhp_core_stm32f4.html I maybe have one of the STM32F1 boards, not stuffed, available. I can only confirm on Friday this week as I'm travelling....

I have: 2 x MBHP_CORE_STM32F4 complete with stm32f4 discovery. 2 x MIDI IO 2 x DIO_MARIX module 1 x AINSER 1 x LCD 20x4 I'm not using. Located in Sweden. Give me a fair offer and it yours. Prefer contact via email as I rarely check the forum: albin.stigo@gmail.com SOLD Best regards, Albin Stigö

Hey people, I cleaned up my room a bit and found some PCBs I do not need anymore. Here we go: This is something I developed years ago! It has a PCB with 8 encoders with LED rings. Although they look blue, they are not. The LEDs (0603) are white! As you can see the PCB an be connected to a standard DOUT-module even without any resistors. The LEDs won't get damaged. I did a mistake in the wiring of the LEDs at this point. So if you follow the official LED-Matrix-Pattern, you will get crazy results. But anyway: This is a software-thing. If you change the matrix-pattern, they work perfectly. I'll advice you about it if you buy it. I have two of those available. On one of them I needed to fix a trace (3rd. picture on the left). But it's perfectly working. Encoders are Bourns PEC16 with integrated switch. Underneath there are three IDC connectors for the encoders and switches that can be directly connected to a DIN-module. Price: 30€ each o.b.o. Next is a LRE: It has warmwhite LEDs. Lower row is mounted on spacer, the others not. Encoders are PEC16 with integrated switches. On the switch-header I soldered a flat-cable directly. So if you don't need it you have to remove it. Price: 35€ This is PCB where you can mount encoders on the top. Necessary shiftregisters have to be mounted on the backside. It's SMD, but can be soldered with a good soldering iron without any problems. No need for SMD-equipment like reflow-oven. Price: 3€ each STM32F4 Discovery! Price: 15€ each AINSER8-module assembled. Price: 6€ each AINSER8-PCBs. Each PCB includes three layouts. I will not cut those in pieces. You have to do it by yourself. Price: 4€ each PCB (=> 3 AINSER8 Layouts) AINSER64-PCB Price: 5€ each (two available) DIO-Matrix-PCBs. Each PCB includes two layouts. I will not cut those in pieces. You have to do it by yourself. Price: 4€ each PCB (=> 2 DIO-Matrix Layouts). GM5x5x5-PCB Price: 5€ That's it for now! I'm located in Berlin, Germany. Best, Chris

i try now to mod it this way... going directly with analog signals to STM32F4: