2024-01-25 05:09 AM
Dear ST Team,
Recently, we undertook a migration of our Firmware from LoRaWAN 1.0.2 to version 1.0.4 using the LoRaWAN stack available on GitHub ([Link to GitHub Repository: https://github.com/Lora-net/LoRaMac-node]). Here, SX1262 is the LoRa Transceiver and STM32L073RZ as MCU. We have successfully implemented and tested LoRa and LoRaWAN functionality with the new stack.
However, we have encountered challenges during the LCTT (LoRa Alliance Certification Testing and Tooling) certification process. Specifically, only the Device Activation Test is passing, while the others are not, as our End Device is not transitioning into Test mode. This issue persists even when using the STMWL55JC series controller EVK board.
For more details on tests, DUT is able to join the network with LCTT tool and LCTT can send COMPLIANCE_DUT_RESET_REQ command in the Downlink packet. Once the DUT does soft reset and after that DUT is directly starting the periodic messages as it detected itself as already joined to network. And the DUT is no longer in test mode. Due to which the other test like DUT pre-condition settings, Downlink sequence counter tests are all failing.
We appreciate your prompt attention to this matter and look forward to the opportunity to benefit from your expertise.
Thanks,
SAIKRISHNA
Solved! Go to Solution.
2024-10-01 09:25 AM - edited 2024-10-01 09:27 AM
Hi RMeij,
LCTT will send the COMPLIANCE_DUT_RESET_REQ Downlink packet for every testcase, and it expect the DUT(LoRa End Device) to get soft reset so that DUT can join to the network again with incremented DevNonce. This is handled in LmhpCompliance.c file LmhpComplianceProcess() via BoardResetMcu(). Here you can implement the soft reset according to your Board specifications. Orelse simply call LmHandlerJoin() function. It worked for me and LCTT test has passed.
2024-01-25 05:12 AM
US915 Band is used for Testing.
2024-03-04 10:12 PM
Hello @saikrishna and welcome to the ST Community :smiling_face_with_smiling_eyes:.
Sorry for our late replay. For such a purpose, it will be a good idea to contact the Our local sales office for more details about the LCTT.
Best Rgards.
STTwo-32
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-10-01 05:15 AM
Hello,
I am struggling with the same for LCTT. Does anyone have more info how to get the stack working with LCTT?
Gr.Remko
2024-10-01 09:25 AM - edited 2024-10-01 09:27 AM
Hi RMeij,
LCTT will send the COMPLIANCE_DUT_RESET_REQ Downlink packet for every testcase, and it expect the DUT(LoRa End Device) to get soft reset so that DUT can join to the network again with incremented DevNonce. This is handled in LmhpCompliance.c file LmhpComplianceProcess() via BoardResetMcu(). Here you can implement the soft reset according to your Board specifications. Orelse simply call LmHandlerJoin() function. It worked for me and LCTT test has passed.
2024-10-02 12:46 AM
Hi Saikrishna,
Thank you very much, this makes things more clear.
The mentioned reset function is empty, also the next call to OnTxPeriodicityChanged function is empty. Is there any AN or user manual which describes what has to be implemented for the LCTT with v1.0.4?
Gr.Remko
2024-10-02 10:35 PM
Hi RMeij,
For LCTT testing, the end device should have firmware that joins the network and sends periodic messages at regular intervals (e.g., 1 minute, 5 minutes, 10 minutes, etc.). During LCTT testing, after joining the LCTT network, the LCTT will send a periodicity change request, which will invoke the OnTxPeriodicityChanged() callback. In this function, you need to change the end device's periodicity to match the new value. If I'm correct, the new periodicity value could be 5secs.
And there is no User manuals or reference documents describing the implementation details for the LCTT with v1.0.4. But you can get the Device certification document for specific LoRaWAN versions where all the LCTT Testing procedures are described.
2024-10-21 02:04 AM
Dear,
The functions are implemented and they work all fine. Almost all the test are pased exept for;
TP_A_EU868_ED_MAC_104_BV_017 fails
TP_A_EU868_ED_MAC_104_BV_019_A This one fails at ID3 Uplink-Max Payload via Echo for SF12BW125. The other dr's are fine.
Any suggestion for these 2?
Gr.Remko