Next pralinetcv9.2.1 archport (#2991)

* Initial commit and pr for HackRF Pro (praline) arch-port to mayhem-firmware. Please see https://github.com/portapack-mayhem/mayhem-firmware/issues/2957. Added flash specifics for -DBOARD=PRALINE. This firmware only builds with toolchain v9.2.1 if hackrf codebase has -B arm in firmware/hackrf_usb/CMakeLists.txt.

* Updated CMakeLists.txt per coordination with @HtoToo. For -DBOARD=PRALINE FLASH_MB_SIZE and FLASH_MB_LIMIT_SIZE are now 4. Removed praline specific variable for FLASH limits.

* Updated chibios-portapack's board.cpp to support initialization of the HachRF-Pro (praline) FPGA. Added append_fpga_bitstream.py tool to ensure that praline_fgpa.bin bitstream can be appended to -DBOARD=PRALINE produced firmware. In order to ensure successful execution of append_fpga_bitstream.py to append the fpga bitstream we should expect that the bistsream will be located at 0x180000 in flash. This requires that FLASH_MB_LIMIT_SIZE must be 1.5, and FLASH_BYTES_LIMIT_SIZE must be 1535 * 1024. If we want to allow more or less space for the base firmware image sans the fpga bitstream the location of the bistream must be moved to a location other than 0x180000.

* Updated location of praline_fpga.bin bitstream to 0x380000 to allow more room for firmware. Firmware now has 3.5MB, or 2MB more available than before as coordinated with @HTotoo.

* Expanded #ifndef PRALINE to include og and r9 gpio and pin setup as coordinated with @HTotoo.

* Added note for PRALINE FLASH_MB_LIMIT_SIZE and FLASH_BYTES_LIMIT_SIZE to explain why we are using the 3.5 and 3584 values respectively as coordinated with @HTotoo.

* Next round of modifications derived heavily, if not entirely  from work done by @banandana at https://github.com/Banandana/mayhem-firmware. This commit should power on the HackRF Pro (praline) display, power on the fpga, and enable gpio, and provide debug utilties. There is still a lot of work to be done to fully enable the new praline board with this build and firmware architectural porting effort. However, hackrf-one boards do not seem to be adversely impacted by the #ifdef PRALINE statements, and CMakeLists updates, as far as I have been able to test.

* Ran format-code.sh. Updates for this commit are only due to formatting. Tested builds and they seem to work as exptected.

* Addressed fixes in firmware/application and firmware/baseband. Stream now flows to capture and looking glass. Issues were related to thread management. Issues were originally addressed by @banandana.

* Ran format-code.sh to allow for consistency with autoamted clang checks.

* Update hackrf ref repo to mayhem-portapack-hackrf next from https://github.com/portapack-mayhem/hackrf

* Addressed format edits necessary to pass clang-format check.

* Starting addressing Si5351 Clocks for radio sampling. These updates correctly set the Si5351 clock at start up. There appears to be an issue during runtime when testing with RX Test Init, Capture and Looking glass.

* Updated clock_manager.cpp to restore correct function introduced by @banandana when testing with Rx Test Init.

* Switched to using decimation for setting the sample rate without changing the Si5351 clock. This assumes that for the praline board Si5351 CLK0 runs at fixed 8 MHz (constant) and the FPGA decimates to get the desired sample rate. For example, for a 1 MHz sample rate -> Si5351 outputs 8 MHz, FPGA decimates by 8. There is still more work needed here, and potential verification that this is the correct way to operate with this new archteitecture.

* After deliberating on hackrf_usb hackrf_core.c and radio.c, and reviewing firmware/application/hw/si5351.cpp the original approach of using the aproach detailed in hackrf_core.c sample_rate_frac_set() lines 580-582, via the implementation in firmware/application/hw/si5351.cpp seems like the best place to continue testing efforts.

* Tested at ~2.4GHz (2.3 - 2.5) with lookgin glass and was able to receive signals. Added a Signal Path debug app to test gains, and readio mode (receive/transmit).

* Added two debug apps for the RFFC507x. Status View and Tuning View. This helped debug some of the potential issues with tuning.

* update submodule

* format code

* Small touch up merging latest next and ensuring build for HackRF One.

* Fix ui addition of max2831 debug display.

* Reverted edits to re: firmware/baseband/sd_over_usb/scsi.c and firmware/application/portapack.cpp. Source now builds, had to pull latest hackrf submodule.

* Skipped detect hardware for praline board to avoid backscreen in HackRF Pro praline board.

* Added UI debug display for max2831 like the rffc507x. Added Filter Band display and Mixer status to Signal Path Status debug display.

* Added ability to set Q: INV, or Q:NOR in Signal Path Status Debug view for testing. Also added display entries for the FGPA Ctrl register fir debugging.

* Added System Diagnostics which allows testing sample rate, q-inv, and dc blk

* Corrected LP - GPIO4[8], and GPIO4[9] issue which was preventing RF Amp, and LPF from chaning state. HackRF Pro (praline) now correctly changes state of LPF and RF Amp as expected.

* Corrected LP - GPIO4[8], and GPIO4[9] issue which was preventing RF Amp, and LPF from chaning state. HackRF Pro (praline) now correctly changes state of LPF and RF Amp as expected.

* Added consistency for testing.

* Added ui to debug whether rffc5072 is locking correctly. Also addressed rf_amp fixed in on state, such that it may now be able to be toggled in HackRF Pro praline setups.

* Updated format to support automated tests.

* format code

* Updated rffc5072 status view in ui_debug to help with debugging. Made updated recommendtions for merge from PR comments. Made updates to ensure resetx isn't reconfigured for output in rffc507x.cpp.

* Ran ./format-code.sh

* Added reference comment that addresses debugging in PRALINE to detail that when the capture app was requesting 15 MHz, it matched 15100000 which resulted in the 8.5M setting. To get the actual 15M setting (22.6 MHz bandwidth), I had to force a request at least 22 MHz while debugging.

---------

Co-authored-by: gullradriel <gullradriel@users.noreply.github.com>

firmware/application/radio.cpp

@@ -205,8 +205,10 @@ void set_direction(const rf::Direction new_direction) {
 #ifndef PRALINE
     baseband_cpld.set_invert(mixer_invert ^ baseband_invert);
 #else
+    // TEST: Force baseband invert for Praline (like r9)
+    // baseband_invert = (direction == rf::Direction::Receive);
+
     // Praline: Control Q inversion via FPGA register
-    // Assuming register 1 bit 1 controls Q inversion
     uint8_t ctrl_reg = 0x01;  // DC_BLOCK enabled
     if (mixer_invert ^ baseband_invert) {
         ctrl_reg |= 0x02;  // Set Q_INVERT bit
@@ -224,16 +226,6 @@ void set_direction(const rf::Direction new_direction) {
         led_rx.on();
     else
         led_tx.on();
-
-    // #ifdef PRALINE
-    //  Try with Q inversion OFF
-    // fpga_debug_register_write(1, 0x01);  // DC_BLOCK=1, Q_INVERT=0
-    // ssp1_arbiter.invalidate();
-
-    // If no signals, try with Q inversion ON
-    // fpga_debug_register_write(1, 0x03);  // DC_BLOCK=1, Q_INVERT=1
-    // ssp1_arbiter.invalidate();
-    // #endif
 }
 
 bool set_tuning_frequency(const rf::Frequency frequency) {
@@ -278,6 +270,17 @@ bool set_tuning_frequency(const rf::Frequency frequency) {
         mixer_invert = tuning_config.mixer_invert;
 #ifndef PRALINE
         baseband_cpld.set_invert(mixer_invert ^ baseband_invert);
+#else
+        // TEST: Force baseband invert for Praline (like r9)
+        // baseband_invert = (direction == rf::Direction::Receive);
+
+        // PRALINE: Update FPGA Q inversion when tuning changes
+        uint8_t ctrl_reg = 0x01;  // DC_BLOCK enabled
+        if (mixer_invert ^ baseband_invert) {
+            ctrl_reg |= 0x02;  // Set Q_INVERT bit
+        }
+        fpga_debug_register_write(1, ctrl_reg);
+        ssp1_arbiter.invalidate();
 #endif
 
         return result_second_if;
@@ -454,6 +457,27 @@ TuningInfo get_tuning_info() {
 
 namespace second_if {
 
+#ifdef PRALINE
+extern "C" {
+extern struct max2831_debug_t {
+    uint32_t requested_freq_mhz;
+    uint32_t calculated_n;
+    uint32_t calculated_frac;
+    bool set_frequency_called;
+    bool frequency_valid;
+} max2831_debug_info;
+}
+
+MAX2831Info get_max2831_info() {
+    return {
+        max2831_debug_info.requested_freq_mhz,
+        max2831_debug_info.calculated_n,
+        max2831_debug_info.calculated_frac,
+        max2831_debug_info.set_frequency_called,
+        max2831_debug_info.frequency_valid};
+}
+#endif
+
 uint32_t register_read(const size_t register_number) {
     return radio::second_if->read(register_number);
 }
@@ -468,6 +492,12 @@ int8_t temp_sense() {
 
 } /* namespace second_if */
 
+namespace rf_path_info {
+rf::path::Band get_current_band() {
+    return radio::rf_path.get_band();
+}
+} /* namespace rf_path_info */
+
 #ifdef PRALINE
 namespace fpga {