Building the Magus firmware

mcc 2020-09-21 19:33:01 UTC #41

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

mcc 2020-09-22 05:11:22 UTC #42

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 2020-09-22 09:31:46 UTC #43

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 2020-09-22 14:52:02 UTC #44

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 2020-09-22 15:15:20 UTC #45

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 2020-09-22 15:46:45 UTC #46

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 2020-09-22 15:49:07 UTC #47

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 2020-09-22 16:33:02 UTC #48

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

antisvin 2020-09-22 16:42:48 UTC #49

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 2020-09-22 16:55:36 UTC #50

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 2020-09-22 17:18:39 UTC #51

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 2020-09-23 21:19:58 UTC #52

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_Midi_ClassDriver) != USBD_OK)

{

  Error_Handler();

}

if (USBD_Midi_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




/* init function */				        

void MX_USB_DEVICE_Init(void)

{

/* Init Device Library,Add Supported Class and Start the library*/

#ifdef USE_USBD_HS

USBD_Init(&hUsbDeviceHS, &HS_Desc, DEVICE_HS);



USBD_RegisterClass(&hUsbDeviceHS, &USBD_Midi_ClassDriver);



USBD_Midi_RegisterInterface(&hUsbDeviceHS, &USBD_Midi_fops);



USBD_Start(&hUsbDeviceHS);

#else

USBD_Init(&hUsbDeviceFS, &FS_Desc, DEVICE_FS);



USBD_RegisterClass(&hUsbDeviceFS, &USBD_Midi_ClassDriver);



USBD_Midi_RegisterInterface(&hUsbDeviceFS, &USBD_Midi_fops);



USBD_Start(&hUsbDeviceFS);

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

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

mcc 2020-09-24 00:01:54 UTC #53

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...
1. 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?
2. Which USB_DEVICE middleware do I select, if I am building for the Magus?
3. Are there any other Magus-specific middlewares (or other one-off options) I need to activate in STM32CubeMX before building MidiBoot?
4. 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 2020-09-28 10:57:11 UTC #54

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 2020-09-28 11:02:00 UTC #55

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 2020-09-28 15:18:22 UTC #56

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 2020-09-28 16:01:15 UTC #57

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 2020-09-29 12:52:15 UTC #58

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 2020-09-29 13:01:41 UTC #59

It's happening! I've created a repo for the libs: https://github.com/pingdynasty/OpenWareLibraries
and a branch with the submodule and build changes: https://github.com/pingdynasty/OpenWare/tree/feature/submodule-libs

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

mars 2020-09-29 13:28:13 UTC #60

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