Unable to connect Lora Wio-E5-dev kit to The Things Network console using STM32CubeIDE

We tested LoRa wio e-5 using AT factory firmware initially and it worked fine.Now after erasing AT firmware and using STM32CubeIDE we are trying to connect wio-e5 dev kit to the things network LNS with our sensecap m2 gateway which is also connected to TTN and sending data, but our wio-e5 is not connecting to TTN application server. We followed the seeed studio’s github documentation for this. We have set our dev eui, join eui, and appkey in the macros of se-identity.h file in STM32CubeIDE according to our generated TTN application server details.

LoRa wio-e5 configuration:
STM32 configuration:

Package: Lorawan_endnode_main (with HAL for STM32WLE)
Mode: OTAA
Region: EU868
Low power mode: disabled

TTN end device configuration:

Frequency plan: Europe 863-870 MHz (SF9 for RX2 - recommended)
LoRaWAN version: LoRaWAN Specification 1.0.2
Regional Parameters version: RP001 Regional Parameters 1.0.2 revision B

We didn’t modify anything in the se-identity.h other than the above mentioned EUI id’s.
Problem:
Wio e-5 is not joining the TTN network even after correctly following all the steps mentioned in the seeed studio’s github documentation
14:34:37.496 → APP_VERSION: V1.1.0
14:34:37.496 → MW_LORAWAN_VERSION: V2.3.0
14:34:37.496 → MW_RADIO_VERSION: V1.1.0
14:34:48.480 → ###### OTAA ######
14:34:48.782 → ###### AppKey: E1:5E:40:34:76:81:F5:16:07:60:00:CC:37:00:35:10
14:34:48.782 → ###### NwkKey: E1:5E:40:34:76:81:F5:16:07:60:00:CC:37:00:35:10
14:34:48.782 → ###### ABP ######
14:34:48.782 → ###### AppSKey: 21:7E:15:16:28:41:D7:A6:74:F7:E1:88:01:CF:4F:3C
14:34:48.782 → ###### NwkSKey: 21:7E:15:16:28:41:D7:A6:74:F7:E1:88:01:CF:4F:3C
14:34:59.915 → ###### DevEui: 2C:F1:F5:20:41:20:AB:8C
14:35:00.226 → ###### AppEui: 52:51:20:69:2E:54:48:26
14:35:00.226 → ###### DevAddr: 15:F9:45:F1
14:35:10.379 → 32s894:TX on freq 868100000 Hz at DR 0
14:35:32.175 → 54s676:MAC txTimeOut
14:35:33.910 →
14:35:33.910 → ###### = JOIN FAILED
14:35:58.169 → 80s677:temp= 27
14:35:58.169 → 80s677:VDDA= 254
14:36:04.850 → 87s350:TX on freq 868500000 Hz at DR 0
14:36:26.633 → 109s140:MAC txTimeOut
14:36:28.341 →
14:36:28.341 → ###### = JOIN FAILED
14:36:28.385 → 110s892:temp= 26
14:36:28.385 → 110s892:VDDA= 254
14:36:35.036 → 117s564:TX on freq 868100000 Hz at DR 0
14:36:56.816 → 139s346:MAC txTimeOut
14:36:58.567 →
14:36:58.567 → ###### = JOIN FAILED
14:36:58.567 → 141s098:temp= 26
14:36:58.567 → 141s098:VDDA= 254
14:37:05.236 → 147s769:TX on freq 868500000 Hz at DR 0
14:37:27.040 → 169s564:MAC txTimeOut
14:37:28.759 →
14:37:28.759 → ###### = JOIN FAILED
14:37:28.759 → 171s316:temp= 27
14:37:28.759 → 171s316:VDDA= 254
14:37:35.472 → 177s988:TX on freq 868500000 Hz at DR 0
14:37:57.225 → 199s786:MAC txTimeOut

Any suggestions on how to solve this issue?
Thanks in advance for the solution.

The DevEUI, AppEUI, and AppKey in the se-identity.h file should exactly match the values provided in the TTN console. DevEUI and AppEUI should be in MSB format (Most Significant Byte first). Some platforms, including TTN, may use LSB (Least Significant Byte) by default. Verify the byte order.

are you sure TTN uses little endian format because I couldn’t find info anywhere saying it uses little endian. Also, while testing, initially, using factory AT just copy pasting the EUI’s from the serial monitor into the TTN console worked fine. Anyways, I will try and get back to you.

Actually TTN is using big endian by default (MS Byte first), so any other problems you could suspect?