Building the Magus firmware

mcc · September 21, 2020, 7:33pm

Yeah, I got it out!! Thanks so much. Will try with the programmer tonight.

mcc · September 22, 2020, 5:11am

So, uh, here’s one.

Got the board out and the ST programmer connected (I think– the Owl-digital-pinout.pdf seemed kind of different from the actual board, there’s an entire second row of pins under where SWDIO et al are, but the 20 pins at the top seemed more or less the same so I’m hoping it was ok).

Tried to build the bootloader (with USE_IWDG). It says files were missing. I realized I probably needed to run STM32CubeMX. I opened MidiBoot/MidiBoot.ioc and hit Generate. Then I tried to build Midiboot. Compile failed, with:

make[1]: Entering directory '/mnt/c/Users/Andi/work/gh/OpenWare/MidiBoot'
./Src/stm32f4xx_it.c:151:6: error: redefinition of 'OTG_HS_IRQHandler'
 void OTG_HS_IRQHandler(void)
      ^~~~~~~~~~~~~~~~~
./Src/stm32f4xx_it.c:121:6: note: previous definition of 'OTG_HS_IRQHandler' was here
 void OTG_HS_IRQHandler(void)
      ^~~~~~~~~~~~~~~~~
/mnt/c/Users/Andi/work/gh/OpenWare/Hardware/common.mk:49: recipe for target 'Build/stm32f4xx_it.o' failed

I check VCS and go figure, STM32CubeMX modified MidiBoot/Src/stm32f4xx_it.c. Specifically it added a OTG_HS_IRQHandler, in addition to the one that is already there. There is no cube-update.sh for MidiBoot. Experimentally, I tried VCS reverting stm32f4xx_it.c and compiled again. I got this second failure:

make[1]: Entering directory '/mnt/c/Users/Andi/work/gh/OpenWare/MidiBoot'
In file included from ./Src/usb_device.c:48:0:
./Inc/usb_device.h:33:22: fatal error: usbd_def.h: No such file or directory

                      ^
compilation terminated.
/mnt/c/Users/Andi/work/gh/OpenWare/Hardware/common.mk:49: recipe for target 'Build/usb_device.o' failed

Reminder, this is ddfe79cf55f1 merged with a447765258d9.

Am I doing something wrong?

antisvin · September 22, 2020, 9:31am

That’s the kind of issues that would be solved by Martin’s proposal to store packages in repo (and not require rerunning Cube just to build a project after checkout).

You’re right that the first file has to be reverted after cube build. Looks like it has some manual edits to support IRQs for FS/HS USB and they don’t survive file export.

As for second header, it’s located in Middlewares/ST/STM32_USB_Device_Library/Core/Inc/usbd_def.h . This is a part of USB library that is normally generated by CubeMX. Is it present? I think that Cube has settings for exporting all dependencies or just project files, so maybe USB library wasn’t exported when you ran it.

mars · September 22, 2020, 2:52pm

MidiBoot is extra complicated because it has to support devices with either HS or FS primary USB interfaces. Sorry!
I will try to crack on with a library rehaul so that building the projects doesn’t have to be a superhuman effort.
ATM the best thing to do is to run the Cube generation, then reset all files in the subproject directory to their previous version.

mars · September 22, 2020, 3:15pm

USB MIDI Host : progress!

I made an attempt at restructuring the drivers so that data is received through the HCD interrupt. It seems to work really well, in fact so far I’ve not been able to get a stuck note.

Would be great to get some eyes on it:

mcc · September 22, 2020, 3:46pm

Okay, thanks. So would this be a correct rule to follow?

“Any file CREATED by the CubeMX generation should be left where it is. Any file ALTERED by the CubeMX generation should be reverted to VCS after generating.”

Is this the rule to follow for BOTH MidiBoot, AND Magus?

I noticed that most of the files altered by the CubeMX generation, all it did was alter whitespace…

mcc · September 22, 2020, 3:49pm

I’ll give that a try as soon as I’ve got the new bootloader installed and the white card re-inserted in my Magus! I might not be able to test Magus stuff until the weekend tho.

antisvin · September 22, 2020, 4:33pm

V21.0 means we’re not gonna see the release until the end of this cursed year?

antisvin · September 22, 2020, 4:42pm

Errr probably not quite correct in case MidiBoot. It has usbd-fs/usbd-hs dirs, but CubeMX would create the same files for whatever is configured for USB device in Inc/Src directories. I think that Cube’s files should be deleted, because we choose correct files from one of those 2 directories based on config header file.

There’s also usbd_audio_if.c/.h files that should be deleted (for Magus and probably MidiBoot with new USB stack as well).

Other than that this seems to be correct as long as you’re not trying to change any peripherals configuration. You may think that this is not something that you would do, but remember that Magus has expander ports for UART (requiring different settings for serial MIDI or digitalbus) and second one for I2C (again, could use different timings setting for protocol clock)

mcc · September 22, 2020, 4:55pm

Okay. But you’re not saying I shouldn’t revert things-- you’re saying I should also potentially delete some of the loose generated files?

Is it the case I must delete those extra generated files for correct code, or just that I have the option of deleting them?

antisvin · September 22, 2020, 5:18pm

Yeah, I think it would have everything necessary for USB, so extra files should be deleted and changed files reverted.

For non-USB files, reverting something may be required or not depending on reasons why it happens. In most cases cube would be overwriting files that were edited manually - this should be rolled back. There’s a possibility that there were some changes in ST-provided files which should be merged upstream, but this is much less likely.

antisvin · September 23, 2020, 9:19pm

Martin, I’ve noticed a minor regression in rollback of USB midi code in bootloader

New version:

github.com

pingdynasty/OpenWare/blob/develop/MidiBoot/Src/usb_device.c#L74

    
      
          #else

          #error Invalid USB configuration

          #endif

            {

              Error_Handler();

            }

            if (USBD_RegisterClass(&USBD_HANDLE, &USBD_AUDIO) != USBD_OK)

            {

              Error_Handler();

            }

            if (USBD_AUDIO_RegisterInterface(&USBD_HANDLE, NULL) != USBD_OK)

            {

              Error_Handler();

            }

            if (USBD_Start(&USBD_HANDLE) != USBD_OK)

            {

              Error_Handler();

            }

          }

          /**

            * @}

Old:

github.com

pingdynasty/OpenWare/blob/master/MidiBoot/Src/usb_device.c#L70

    
      
          #if defined USE_USBD_FS

            if (USBD_Init(&USBD_HANDLE, &FS_Desc, DEVICE_FS) != USBD_OK)

          #elif defined USE_USBD_HS

            if (USBD_Init(&USBD_HANDLE, &HS_Desc, DEVICE_HS) != USBD_OK)

          #else

          #error Invalid USB configuration

          #endif

            {

              Error_Handler();

            }

            if (USBD_RegisterClass(&USBD_HANDLE, &USBD_AUDIO) != USBD_OK)

            {

              Error_Handler();

            }

            if (USBD_AUDIO_RegisterInterface(&USBD_HANDLE, NULL) != USBD_OK)

            {

              Error_Handler();

            }

            if (USBD_Start(&USBD_HANDLE) != USBD_OK)

            {

              Error_Handler();

But unlike the audio USB driver, MIDI USB requires non-NULL callback pointer otherwise it returns failure:

github.com

pingdynasty/OpenWare/blob/master/Source/usbd_midi.c#L548-L552

    
      
          #include "device.h"

          #include "midi.h"

          #include "usbd_midi.h"

          #include "usbd_desc.h"

          #include "usbd_ctlreq.h"

          

          static uint8_t  USBD_Midi_Init (USBD_HandleTypeDef *pdev, 

                                         uint8_t cfgidx);

          static uint8_t  USBD_Midi_DeInit (USBD_HandleTypeDef *pdev, 

                                           uint8_t cfgidx);

          static uint8_t  USBD_Midi_Setup (USBD_HandleTypeDef *pdev, 

                                          USBD_SetupReqTypedef *req);

          static uint8_t  *USBD_Midi_GetCfgDesc (uint16_t *length);

          static uint8_t  *USBD_Midi_GetDeviceQualifierDesc (uint16_t *length);

          static uint8_t  USBD_Midi_DataIn (USBD_HandleTypeDef *pdev, uint8_t epnum);

          static uint8_t  USBD_Midi_DataOut (USBD_HandleTypeDef *pdev, uint8_t epnum);

          static uint8_t  USBD_Midi_EP0_RxReady (USBD_HandleTypeDef *pdev);

          static uint8_t  USBD_Midi_EP0_TxReady (USBD_HandleTypeDef *pdev);

          static uint8_t  USBD_Midi_SOF (USBD_HandleTypeDef *pdev);

          static uint8_t  USBD_Midi_IsoINIncomplete (USBD_HandleTypeDef *pdev, uint8_t epnum);

This file has been truncated. show original

So either it should be passed like before or USBD_Midi_RegisterInterface should ignore it if can be used without a CB.

mcc · September 24, 2020, 12:02am

I have reverted all files back to develop + antisvin:update-parameters-broken (except for the files that enable IWDG). I am still not sure how to proceed. I am still getting the usbd_def.h not found error.

@antisvin said above the usbd_def.h header is supposed to be at Middlewares/ST/STM32_USB_Device_Library/Core/Inc/usbd_def.h. It is not there, there is no Middlewares/ or MidiBoot/Middlewares directory even. There is a ./Magus/Middlewares/ST/STM32_USB_Device_Library/Core/Inc/usbd_def.h.

If I look at the STM32CubeMX manual, it gives these instructions for installing a Middleware:

From the Mode panel in the Pinout & Configuration view, configure the RCC
peripheral by enabling the external clocks, master output clocks, audio input clocks
(when relevant for your application). This automatically displays more options on the
Clock configuration view (see Figure 96). Then, select the features (peripherals,
middlewares) and their operating modes relevant to the application.

I think this is the mode panel in question:

It looks?? like the reason there is no usbd is because USB_DEVICE middleware is “disabled”. But I do not know whether to select HS or FS for the Magus, and I do not know which of the several options to select.

So, @mars, I have 4 questions…

Is there some preconfigured build file for MidiBoot for the Magus I have missed? Or do I need to open MidiBoot.ioc and select a USB_DEVICE middleware by hand?
Which USB_DEVICE middleware do I select, if I am building for the Magus?
Are there any other Magus-specific middlewares (or other one-off options) I need to activate in STM32CubeMX before building MidiBoot?
Once I get MidiBoot in I would be happy to test your usbh irq PR. However, what about @antisvin’s issue above? Should I run the usbh irq PR from github directly, or should I wait for the issue antisvin raises to be fixed?

Thanks.

antisvin · September 28, 2020, 10:57am

Since Martin didn’t answer this:

use audio device class
pretty sure that you should rollback/delete anything that Cube generates outside of Middlewares/Drivers directories
current USB registration code would fail at runtime during device initialization, older version should be used. I’ve confirmed that it happens on another device with forked code.

antisvin · September 28, 2020, 11:02am

Actually, I don’t think it’s even necessary to build version of MidiBoot from develop branch. The USB code that needs testing is in Magus FW, not the bootloader.

mcc · September 28, 2020, 3:18pm

Thanks, good to know. But master midiboot at least does the IWDG correct (as long as USE_IWDG is set)? That was all I wanted for midiboot.

One more fiddly question. Do MidiBoot and Magus have to “agree” in terms of whether they’re using full speed vs high speed? That is if I set up MidiBoot with USB high speed, and then later I downgrade Magus to USB full speed, will that confuse anything?

antisvin · September 28, 2020, 4:01pm

Yes, IWDG code is present in master branch and I’ve used it before.

Firmware resets all peripherals when booting, so USB will be reset and configured from scratch after application jump. But it looks like both “full speed” and “high speed” peripherals are configured to use full speed - Martin explained a few pages earlier that high speed USB would required external PHY (additional hardware IC)

mars · September 29, 2020, 12:52pm

Yes in the HAL they refer to OTG_FS/HS to distinguish between the two peripherals, even if they are both configured as FS.

mars · September 29, 2020, 1:01pm

It’s happening! I’ve created a repo for the libs: GitHub - pingdynasty/OpenWareLibraries: Supporting code libraries for OpenWare firmware
and a branch with the submodule and build changes: GitHub - pingdynasty/OpenWare at feature/submodule-libs

Now I just need to go through the different projects and fix any build problems… Wish me luck!

mars · October 1, 2020, 8:33am

Magus and the Magus bootloader builds now.

Check out the branch, do a submodule init and update, and build as before. But pls make sure to do a make clean when you switch from one project to another, ie from bootloader to Magus!

git checkout feature/submodule-libs
git submodule init
git submodule update
make clean
cd MidiBoot && make PLATFORM=Magus all
cd Magus && make clean all

@mcc if you want to try my usbh changes then also do

git merge feature/usbh-irq