As the title suggests, I am trying to diagnose an unknown issue with the LoRa-E5-HF module. I do not expect an exact solution because I understand this might be a very specific situation, but what I am looking for is some direction.
We are using PuTTy and an STLink probe to output logs over the serial connection. With the current firmware we are running on it, we do see that the module is starting up, but we don’t get much else useful output to work with.
What I am trying to figure out is if there is firmware that could be flashed onto this that would help in the diagnosing process that may potentially output some more useful information. Perhaps some way of indicating if the board is underpowered or burned out or really anything useful.
We have this module built into a board that we are using for one of our devices, and we are using STM32CubeProgrammer to flash it with some custom firmware. We don’t think its the firmware, because we have a previous version of the board using the same module and firmware and it worked just fine (dozens of these working boards). It is just on the newest version that it does not work. Out of ten prototypes, only three worked successfully. So it seems to point to a hardware problem.
I know it’s a pretty specific case with the custom firmware and all, that’s why I’m trying to see if there is something out there I can flash that is more known, or verbose, or perhaps with some documentation.
I am fairly new to hardware debugging on this level, so I would be grateful for any advice on the matter.
You need to connect to it while it’s in bootloader to update FW. One way is to power up while holding RESET pin low, connect, then release RESET pin to modify FW.
We did not really find a solution to this issue. We think it is related to the manufacturing process, whether it was a bad batch or it was from the board assembler. We did some troubleshooting by modifying our firmware to add print statements to the console for each phase of the initialization process. We found that the startup on these bad chips always hung on the “subGHz_phy” module (and always for about 23 seconds), which as far as we can tell, seems to indicate that there is something physically wrong within the chip. Out of a few hundred, we had something like a 30% failure rate. Pretty rough.
We had our assembler send us back our LoRa chips, and we flashed them before they were assembled. And they all flashed. This seemed to point to the assembler. We let them know, and they must have changed something in their assembly process, or we have moved past the batch that was bad, because now they are pretty reliably working in our latest batches that we did not pre-flash.
It is still a mystery to us, but if your problem is the same one we were having, it seems to have something to do with that “subGHz_phy” module, which from what I understand, is one of the main bridges between the firmware and the hardware.
I hope this helps point you in the right direction.
I’m sorry to tell you.
We have a reminder in the Wiki about brushing your own firmware: If you choose to brush your own firmware, you will no longer be able to brush the factory firmware.
