Make Owl Great Again!

OWL Firmware
, , , ,
#21

Yeah, when I’ve just reflashed bootloader without making a full erase, it still wasn’t working after reboot. And since device doesn’t seem to even start firmware booting (display, LEDs were not initialized), it can’t be an issue with patches - that would manifest only after booting is done.

Regarding remote debugging, I often use it for troubleshooting the other firmware I’ve mentioned. But Magus debug build gives me an error due to flash size exceeded:

Build/Magus.elf section `.data' will not fit in region `FLASH'
region `FLASH' overflowed by 400 bytes

Btw, I’m using vscode with this plugin for debugging - Cortex-Debug - Visual Studio Marketplace . Would recommend to check it out.

#22

Well, no luck with any firmware files that I’ve tried. Then I’ve flashed debug firmware (without bootloader). With -O1 or -Os there’s enough space for debug firmware, and it looks like booting is stuck in a loop here:

Somehow HAL tick doesn’t get incremented - no idea why that started happening. It’s something that should be done by SysTick interrupt handler, so maybe something changed in Cube generated files and now we’re initializing RAM too early. But commenting out that line gives me a module that can boot. Except that there’s an error on display saying “failed to start program task” - not sure if that’s due to lack of bootloader, user patches, but I’ll restore bootloader and try loading something to check if that would solve it.

I’d say now would be good time to confess if you’ve uploaded firmware releases without testing it on every device.

#23

Ok, the error was just due to no patches on device. And I’ve flashed bootloader and then loaded firmware without issues. I hope nobody else is going to have bricked devices.

#24

I’ve just tested the upgrade procedure again, with the Magus.syx from github release 20.6, and it works for me.

Could you try adding __enable_irq() in Magus/Src/main.c line 198, before the call to SDRAM_Initialization_Sequence(&hsdram1); ?

I don’t know why interrupts would still be disabled for you at this point, seems very strange. Unless there are some other higher-priority interrupts firing away at the same time, but that seems even more unlikely.

#25

Ok, so I’ve reflashed last version (without delay loop) to confirm that it still works. Then uncommented HAL_Delay and enabled IRQs like you’ve suggested - that also booted. Then removed __enabled_irq again to double check that it’s not something else - that gave me a brick with wooden cheeks again.

Unless there are some other higher-priority interrupts firing away at the same time

Wouldn’t that just delay SysTick handler call if there’s higher priority interrupt (simply adding some jitter to our timing)? It seems like it would take a constant flood of interrupts to prevent SysTick from advancing.

#26

Oh wow. Worrying! I’ll take the v20.6 release down and add a call to __enable_irq().
Thank you @antisvin

#27

https://sysprogs.com/w/forums/topic/systick-doesnt-increment-in-stm32-cubemx-samples-when-executed-from-sram/

Could this be the reason why it worked for you? If you didn’t run it from flash, this could explain why you couldn’t reproduce the issue.

Also, it could be happening to other devices that have SDRAM, not just Magus

#28

I’ve tried firmware v20.5 with which I had no problems before and now I get the same hanging after flashing. This could mean that the issue is caused by specific bootloader version - maybe you should try testing it with latest MidiBoot if your Magus was running older one.

We disable IRQs in bootloader before jumping to application - OpenWare/main.c at master · pingdynasty/OpenWare · GitHub . So it makes sense that they should be enabled later explicitly - I can’t find where we do that.

I wonder if disabling IRQs was working the same way before this commit - added missing getFirmwareVersion() and changed to use __disable_irq()… · pingdynasty/OpenWare@b1f6ee9 · GitHub - not sure how much accessing register differs from ASM call that CMSIS does.

#29

We don’t run code from SDRAM, but we do run patches from SRAM. I think in that case the poster just forgot to set the VTOR pointer correctly.

#30

Huh, interesting.

The previous way of disabling interrupts was with RCC->CIR = 0x00000000. That is also executed in SystemInit(), which is still called before entering main.

#31

Okay so I can confirm that the change in the bootloader causes the firmware to hang unless __enable_irq() is called, which previously it wasn’t.

I’ve published a new Release v20.7 which fixes this

If you’ve flashed v20.6: don’t panic!

The bootloader change was introduced in Feb this year, and no products have shipped with this version. So it is only if you’ve built and flashed a new bootloader yourself that this could be a problem.

#32

I think this is not so simple. I wasn’t running an updated bootloader when I’ve initially ran into this issue. So it looks like it could also happen for users that haven’t upgraded bootloader. Also, it may not even be due to bootloader code alone, but compiler version used to build bootloader or something like that.

Unfortunately I don’t have other Trilogy devices for testing and don’t have access to original bootloader image

#33

My understanding is that it was the change in the bootloader that is the issue, and there’s no way that bootloader (which was not released) could boot any pre-20.7 firmware successfully.

As for your original problem, perhaps it was something else completely - wrong firmware for example?

Testing the firmware for which hardware it has been compiled for is a nice idea. We’d have to just add an identifier before or after the isr_vector. I’d be tempted to put it before, since the length of isr_vector varies with hardware.

I’m also keen to enable the IWDG watchdog to make the risk of accidentally bricking a device much less likely, be it by a dodgy firmware, a patch, or corrupted flash process. I’ve pushed a new branch:

If you have a chance to test it (@antisvin or anyone else who is brave and has access to a hardware programmer!) it would be good to have it verified that it works not just for me. The main updates are to the bootloader, which now initialises the IWDG watchdog to trigger after 8 seconds, unless its timer is reset in that period. When the IWDG triggers, the device is automatically reset. So if you flash the new bootloader and let it start up an old firmware, then it should reset to bootloader after max 8 secs because the firmware doesn’t ‘feed the dog’ (ie reset the IWDG timer). To prevent it doing that, just compile and flash a new firmware from the same branch, which includes the timer reset.

#34

Ok, I guess it’s possible that it was flashed with wrong FW like I thought initially, then I’ve turned off Magus expecting that it can be reflashed and forgot about the whole incident until I’ve turned it on a few days later. It’s impossible to tell difference for those cases based on device behavior.

So I’ll flash bootloader and rebase my FW from that branch. I’ll just run it for a few days to see if I can notice any issues during normal usage and will try to flash a few broken firmwares when I have some time for this kind of fun.

Btw, it sounds like IWDG would not be able to work if interrupts were disabled by mistake again. Maybe we should check that they are enabled early on and jump to bootloader if that’s not the case?

#35

Can confirm that it worked for me. Old FW returned to bootloader on timeout, rebased version is running. Are you planning to add bootloader update command or just let users do it themselves with a programmer if they wish?

1 Like
#36

Looks like there’s an issue with current OpenWare running on Owl. Half of output audio buffer gets filled with zeros. Not sure if its regression from multi-channel audio update (it certainly wasn’t tested on Owl as codec code wasn’t even compiling) or could be something related to Cube version update that I’ve made later.

#37

It looks like there’s no issue in code itself (i.e. buffer sizes are correct), but somehow HAL_I2SEx_TxRxCpltCallback is not being called. HAL_I2SEx_TxRxHalfCpltCallback gets called as expected.

This is the issue that we’ve got: ST Community

Also here with more discussion: I2S DMA Complete transfer IRQ is not used on circular mode · Issue #8 · STMicroelectronics/STM32CubeF4 · GitHub (note that the “workaround” that someone linked to is not for this issue)

So let’s thank STM32 for yet another HAL update with broken code.

#38

List of issues that have been fixed and are awaiting being merged to upstream:

  • gate input wasn’t working (missing interrupt)
  • I2S got broken on cube upgrade, I’ve found and ported fix that was used for previous cube version
  • ADC inversion fix for modular can be used based on extra hardware device ID
  • ported patch selection from old FW
  • MIDI bootloader, finally! (didn’t plan to do this, but somehow I had unlocked bootloader section that got overwritten because offset for FW update wasn’t set)

I think this covers all outstanding regressions from new firmware, other than things not implemented in FW itself yet (i.e. changing audio buffer size).

1 Like