infrared remote crashes the device when frequency is set to 76000

[Didgitalpunk]

Describe the bug.

infrared remote crashes the device when frequency is set to 76000, regardless of the signal output path chosen (flipper, A7)

line 16 of furi hal interface specifies a max frequency of 56KHz.

Using a modified firmware with just that value set to 76000 instead of 56000 makes the flipper no longer crash, but still freezes before any command is sent when a button is pressed in the IR app.

Reproduction

example code to run:

Filetype: IR signals file
Version: 1

LEGO Spybotics Remote Control (4232rc)

CH 1

name: Ch1_OrangeNop_YellowNop
type: raw
frequency: 76000
duty_cycle: 0.330000
data: 1040 208 208 208 208 624 208 416 208 208 1040 416

expected behaviour: IR remote app sends the signal when button is pressed then stops when the button is depressed

actual behaviour: flipper crashes with a furi_check failed message on bootup when button is pressed,
OR
if using a modified version of furi_hal_infrared.h with line 16 set to 76000, flipper freezes and needs to be restarted

Target

Infrared

Logs

No response

Anything else?

No response

[Didgitalpunk]

After a bit of talk on the discord infrared channel (see from here ), this appears to be a hardware issue cause by how the signal is generated, specifically by using 2 hardware timers and Direct Memory Access (see furi_hal_infrared_configure_tim_pwm_tx and everything surounding INFRARED_DMA_TIMER)

[Didgitalpunk]

turns out it actually works with line 16 set to 76000 in furi_hal_infrared.h , I just had a bad build.
Aleksandr Kutuzov and Axum got it working, and after Axum shared his build with me, I confirmed it worked for good by controlling my LEGO spybotics unit with it.
https://cdn.discordapp.com/attachments/954422774141710366/1328686183634440213/V_20250114_122341_N5.mp4?ex=67879aef&is=6786496f&hm=812e96962da65a8e6752964e03a6a861cc37b1fe0d3d21f1f463412b3f8c077c&

[skotopes]

System limitation comes from how infrared uses timers and DMA channels: long story short 1MHz carrier will generate 1M DMA transaction, which is close to what Flipper MCU designed to handle.

Interesting thing: previous max value was chosen based on infrared app performance when it was in MCU flash memory. After we moved apps to SD this limit is no longer actual.

I've bumped limit to ~1MHz, but there is no guarantee that it will always behave as expected(it may fail under specific type of load).

[Didgitalpunk]

Awesome! Thanks for taking care of this so quickly!

Very interesting to know that moving things to the SD card pushed back the limitations a bit, makes you wonder what else could get a boost in performance out of that change!