fix(f4): re-enable pre-fetch, instruction and data cache

[raphaelcoeffic]

This was disabled by mistake in #6183.

Fixes #6816.

[3djc]

Fix confirmed, and benefits the radio overal too

Needed for 2.12 too please

[gagarinlg]

Ouch

[gismo2004]

Is that maybe also related to this: #6901

[pfeerick]

Is that maybe also related to this: #6901

Doesn't appear to be... I am starting to suspect it is baud rate related.

[pfeerick]

After replicating the dropouts / no module telemetry, both module telemetry is back and link appears stable again /w external MPM and DSMX & AFHDS2A on TX16S

[gismo2004]

Is that maybe also related to this: #6901

Doesn't appear to be... I am starting to suspect it is baud rate related.

Are you sure? On my V16 this seems to fix it? Before this fix, when setting the external ELRS module to 5.25M it was basically not possible to correctly load the elrs.lua and in the log, I have seen a lot of XF CRC errors and such while trying to open it. Now with this patch I can set it to 5.25M again without “noticeable” issues. I don't know if there is something else in the background I don't see, but for me, this looks excellent. @planemann2000 maybe you want to give the latest nightly a try --> #6901?

Also the overall performance is wayyy better now. I am working on a widget where I have added a refresh to refresh time logging to see if I can improve things. The average time was something like 120ms and when connected to FC/telemetry, this time increased to 230 - 260ms. Now with this patch i am down to 50ms in "idle" and 50-100ms when telemetry is connected.

@raphaelcoeffic @3djc AWESOME improvement! Thank you very much!

[3djc]

But be aware that on ELRS team request, we will be removing 5,35mbps for external modules (#6923), and no, it is not related to the prefetch issue, but to ongoing, years long, issues. While it might appear to work fine at 5,25, it doesn't (more info in that PR)

[gismo2004]

Yes, I am aware of this request, and I have noticed that they are using a logging that basically counts these errors:
TRACE("[XF] pkt len error (%d)", pkt_len);
TRACE("[XF] CRC error ");
Without this patch, I had those errors in the log occasionally when setting it to 5.25M, but not anymore now. (at least not in the last 2 hrs :-D)

That's the reason I am asking... It's been a long story already for me too: Discord And yes, I am aware that there are more radios out there than my V16, but I just wanted to mention it, just in case.

[3djc]

When I meant long,I did not mean monthes long, but years long

[gismo2004]

Don't get me wrong, please; I would rather not stop #6923 from being merged. I am totally fine with 3.75M, I just wanted to point out that this patch has improved “something” on my V16 in that direction. But since I haven't owned the V16 for years, I can't tell anything about that history; thus, I have absolutely no knowledge about the initial issue.

[frankiearzu]

Tested with TX16/Boxer, External Modules: Lemon DSMP, Multi-Module, XJT. All good.

With the external ELRS, channel/servo operation is OK, but about 75% of the time, the ELRS LUA doesn't finish loading the menus (@333hz). It reaches about 75% and stays there. I think there is another ticket for it.

[pfeerick]

Baud rate of the ext. module is important to know here. 400k should be ok up to 333hz, but I usually use 921k since that opens up the option of 500hz and gives a little more room for error. 5.25M is not recommended any more for external CRSF on for STM32F4 radios (3.75M is the highest recommended baud rate, thus applies to both radios).

[planemann2000]

Stan On Tuesday, January 13, 2026 at 12:17:30 AM CST, Peter Feerick ***@***.***> wrote: pfeerick left a comment (EdgeTX/edgetx#6979) Baud rate of the ext. module is important to know here. 400k should be ok up to 333hz, but I usually use 921k since that opens up the option of 500hz and gives a little more room for error. 5.25M is not recommended any more for external CRSF on for STM32F4 radios (3.75M is the highest recommended baud rate, thus applies to both radios). — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>