Upgrade to ChibiOS 17.6.3

[glowtape]

Posting this for first comments, whenever someone's bored. Or if someone wants to compile and test this.

Currently all F4 targets compile, except BrainRE1, where the newer HAL complains about some PLL stuff. Seems some mcuconf.h values aren't considered correct (anymore).

C:/Dev/Chibi/dRonin/flight/PiOS/Common/Libraries/ChibiOS/os/hal/ports/STM32/STM32F4xx/hal_lld.h:1647:2: error: #error "STM32_PLLI2SVCO outside acceptable range (STM32_PLLVCO_MIN...STM32_PLLVCO_MAX)"
C:/Dev/Chibi/dRonin/flight/PiOS/Common/Libraries/ChibiOS/os/hal/ports/STM32/STM32F4xx/hal_lld.h:1772:2: error: #error "STM32_PLLSAIVCO outside acceptable range (STM32_PLLVCO_MIN...STM32_PLLVCO_MAX)"

Benchtested on Seppuku, Revolution and OG Brain. They seem to last a while without rebooting, so I guess things are probably OK.

Quick memory check on the Revo, it loses 2124 bytes on the heap, gains 56 bytes on the fast heap. Former is probably additional code and memcore. Latter is due to the mainthread stuff from old ChibiOS disappearing, which sat in CCM. I cant force the new struct, that contains that, the readylists and so on, into CCM, though. Probably due to the extremely unique name of "ch".

I bet the loss of heap is probably going to cause grief for me, trying to get SPRF3E to link.

[glowtape]

Also, I need to eventually cull all the other compiler/ports crap. +1.5M lines lulz.

[glowtape]

OK, all targets compile.

F1: I don't have the pipXtreme.

F3: Benchtested the SPRF3e and it works. The others should probably, too.

F4: Benchtested the Seppuku, Revo and OG Brain, they work. The others should probably, too.

BrainRE1: It seems like there's more rigorous checks on the mcuconf.h settings in the new ChibiOS HAL that break compilation. I've added a bunch of simple bypasses to get it to compile. Untested, my RE1 is kaputt.

[tracernz]

It would be better to rewrite the commit bringing new chibi sources in to remove all the unused files. As-is this will inflate the repo size with objects that will never be used.

[glowtape]

I've been looking at it some more, and it'd involve including ChibiOS' stm32_registry.h header in the different StdPeriphs. I'd figure an unsuitably named define in the makefile is the lesser evil option.
--edit: Actually, I'm going to it anyway. It's not like we're going to move from ChibiOS anytime soon, or keep updating the StdPeriph.

[glowtape]

Yea, no, trying to work stm32_registry.h into it creates more drama around the bootloaders and flightlib, considering that I somehow have to stick it into pios.h for some situations.

[glowtape]

Mempools requires a function typedef called memgetfunc_t that's encapsulated within the memcore feature flag #ifdef in this version of ChibiOS. I moved it outside said section in the header, so we can disable memcore again and keep rocking the simple allocator (it works just fine).

[tracernz]

It would be good to report such things upstream and get them fixed rather than carrying them ourselves.

[glowtape]

I've been digging around ChibiOS some more, looks like it's unnecessary. I wanted it disabled in case something in the OS would start using it in unexpected places. But it appears only ChibiOS' heap allocator uses CoreAlloc, and we don't use their heap allocator, and some syscall (_sbrk_r) ChibiOS specifies, which fails with ENOMEM anyway when there's no memcore (does the same in 2.6.6 already).

They'd probably not accept it upstream for those reasons, anyway.

[glowtape]

Rebased. Reordered the commits topically (which Github doesn't really care 100% for apparently).

[glowtape]

We're losing 2140 bytes on the heap with this one. There's a bunch of more abstractions within ChibiOS, that seem to responsible for this. Maybe I should eventually spend some time figuring out where it goes to. We can make 1024 bytes back running the initTask stuff on main() as suggested elsewhere. CPU usage appears to be same between the two.

[mlyle]

jenkins, test this please

[glowtape]

Meh, SPRF3E flash overflow. Tonight, I'm gonna cherrypick those changes from the inverse mixer and LQG branches to slim it down, and see if it compiles and still runs.

[glowtape]

Pulled in two patches to remove Light Telemetry and HoTT Bridge. As well as the UI options (including Mavlink, which was already disabled). SPRF3e compiles now and boots fine. Also tried BrainFPV, Revo and Seppuku again.

[glowtape]

I just came to think of it... This would probably need to be tested on a PikoBLX with CharOsd (I don't have one). Trying to run the LQG branch on one of these with autotune and MSP enabled sent it over the edge into a boot loop. Given that the new ChibiOS uses a little bit more memory for internal stuff, the same might happen. If so, this should be postponed until an eventual deprecation of F3 at some later release.

[mlyle]

PikoBLX doesn't have OSD, does it?

[glowtape]

I don't know. Both @jhitesma and @ufoDziner tried the LQG stuff on their PikoBLX based 2" quads, and one was out of RAM and the other not. It seemed to involve CharOsd IIRC.

[glowtape]

Rebased on latest next, fixed up pios_thread renaming a ChibiOS function in WrapCurrentThread which's new, reworded the target-specific F3 commits because of the mcuconf.h consolidation. Otherwise still the same.

Tested on Seppuku, Revo, OG Brain and SPRF3e.

[glowtape]

I just notice that per task running time doesn't work. Wonder if that broke in the rebase or before.

[glowtape]

Jenkins, test this please.

[glowtape]

I don't know why ef_omnibusf3 fails, compiles fine here. Logs are pretty vague.

[glowtape]

I'm also having a bunch of random crashes. Sometimes things work for like 8-10 minutes, sometimes it crashes after 16 seconds. Given the TaskInfo.StackRemaining values are completely different between next and this, there's probably something with memory.

[glowtape]

Yeah, I'm pretty sure I made changes to pios_heap.c and they're gone. WTF.

[tracernz]

Can never be fixed because we will always have old bootloaders around.

[glowtape]

I mean the CRT0_FORCE_MSP_INIT thing. It's not set at all in this ChibiOS release. It's been set to TRUE by default in 18.x.

[glowtape]

Note to self: MemManage_Handler in loadable.c doesn't overwrite the weak alias of ChibiOS for whatever reason (noticed while poking around with objdump yesterday).

[glowtape]

Seems like a thread struct gets overwritten somewhere at some random point, and when the RTOS wants to switch to the respective thread, shit goes sideways. With ChibiOS 17, the thread struct moved to the other side of the stack memory allocation, so that's probably why it's happening here but not with old ChibiOS. Seems to happen with the Battery module enabled only for now, on Seppuku and SPRF3e. Gonna be a fun one to track down.

--edit: Definitely not the ADC stuff, since it appears to be always running.

[mlyle]

Does battery module need a bigger stack?

[glowtape]

Doesn't look like it. There isn't that much happening in it (from what it looks like to me). I bumped stack from 624 to 800 bytes and it still happens.

What's most irritating is that the time to the event varies a lot. Sometimes it happens at like 15 seconds, other times it takes like 300+ seconds. The only thing I noticed this round of poking at it, is that disabling the battery module, I can repeatedly go up to 1800 seconds without issues, where I usually stop.

I have to figure out how to track this. Probably hack up ChibiOS' context switching to store a pointer of the thread it's switching away from, which hopefully will be responsible for it.