Issues while programming the Grove Lora E-5

A couple of weeks ago, I started trying to program my Grove Lora E-5 to work without an external MCU and my progress is as follows and the obstacles I encountered:

  • Out of the box the E-5 did wonders with the factory firmware being able to join my LoRa gateway and transmit packets without any issues, so I decided it’s time for the next step
  • I succeeded in erasing the factory firmware after a couple of days, so I could start uploading my own
  • I followed the steps from the LoRa-E5-LoRaWAN-End-Node github and was finally able to build all the projects inside with stm32CubeIDE but just once because after changing anything in the .ioc config the files would change and errors would ruin the project so I had to start over after every change I made there until I learned that the code generation is a no go
  • I built the LoRaWan_End_Node project and uploaded it to the E-5 but was greeted with some bad news

    We can see here, how just printing the Keys, DevEui, AppEui, and DevAddr takes almost 33 seconds to finish (while the factory AT firmware took about 5 seconds if I could remember correctly with the joining process and everything) which is really odd. After printing them out the joining process starts, it says that it has transmitted a packet but that said packet is nowhere to be seen in my Lora gateway dashboard and a couple of seconds after that it just restarts by itself
  • After seeing the disaster I had created I tried with another project from that same github repo - FreeRTOS_LoRaWAN_AT. I built it uploaded it and was greeted with more bad news
    (Check the image below in the comments)
    The 2 commands run are:
    AT+VL=3 - Setting the verbose to level 3
    AT+JOIN=1 Initiating the join procedure with OTAA
    So the first time I am able to run an AT command is at the 40 second mark which is 40 seconds of just printing the keys and initiating stuff, 25 seconds later we see the MAC txTimeOut error pop up. From my research, I found that the problem comes from a bad or no connection from the micro-controller to the radio (source: github). So now there are 2 options of what could have happened - the first one is something is up with the hardware and I have to get a new E-5 to continue the project I started. The second one - the firmware could be using the wrong GPIO to communicate with the radio.
    I tried changing the PROBE_LINE1_PORT and PROBE_LINE2_PORT from B12 and B13 to A4 and A5 respectively (which I found here check the comment bellow), but with no luck, I tried using all kinds of ports that I found on the specifications pdf (check the comment below) - page 5 - PA10 and PB14, PB4 and PB3, PC1 and PC0 - these were last measure tries (you could call them cries for help).
  • I tried debugging the RTOS AT Slave project more because it was the only one that didn’t restart after it failed to connect and put just a print line before and after every function call and can for sure say that everything goes fine through the whole procedure of joining and all the functions return an OK status and none of them crash.

I would be grateful if anyone could help in any way and I would be more than happy to share more if anyone is interested.
A more straightforward question is - can anyone provide me with a link to the factory AT Firmware so I can test if my hardware is working properly?

Second image:

A4 and A5 source: Grove - Wio-E5 - Seeed Wiki
The 3. RF Switch part of the website
Specifications pdf src - - page 5

After some debugging via the STM32CubeIDE I found out the issue (at least I think I did) - SUBGHZSPI_Transmit returns HAL_SUBGHZ_ERROR_TIMEOUT, which doesn’t stop the process all together but rather it goes through many loops to try to succeed with the function, which explains the long wait to print out the device information
I found some information about the issue here:
1 - ST Community
2 - Seeed forum