E5-Mini locks up after MAC txDone when LOW_POWER_DISABLE == 1
jcwren opened this issue · comments
I've found that when LOW_POWER_DISABLE is set to 1 (in Core/Inc/sys_conf.h) that after sending the initial join packet, the board is locking up. I haven't yet hung a J-Link on it to see where it might be stopping. Setting LOW_POWER_DISABLE to 0 and the board operates normally.
Have you seen any such issue?
APP_VERSION: V1.1.0
MW_LORAWAN_VERSION: V2.3.0
MW_RADIO_VERSION: V1.1.0
###### OTAA ######
###### AppKey: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
###### NwkKey: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
###### ABP ######
###### AppSKey: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
###### NwkSKey: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
###### DevEui: 00:80:E1:15:05:03:ED:D3
###### AppEui: 01:01:01:01:01:01:01:01
###### DevAddr: 05:03:ED:D3
0s041:TX on freq 902500000 Hz at DR 0
0s416:MAC txDone
(stops here, nothing else happens)
I have never tried this setting. This would mean it does not work in sleep mode but it does in stop mode which is a bit strange as the latter is shutting down more stuff. You could try to include MX_I2C2_Init() in PWR_ExitSleepMode() (file stm32_lpm_if.c) to check if it makes a difference.
I'll take a look at that. On a different note, I have a LoRaWAN alternative for ForestWatch that you may be interested in. I'm not sure if it's appropriate to discuss on GitHub and you don't have any means of contact published in your profile. If you're interested, please drop me an email at jcwren@jcwren.com with ForestWatch in the subject line.
Turns out this is a result of the .ioc file having PB4 defined as DBG4_Pin, and my code initializing PB4 directly as an input. DBG1 through DBG4 are not used by the code, and I'm not certain WHY removing them from the .ioc file fixed the issue, as they're configured before my code re-initialized PB4 as a falling edge triggered interrupt. But regardless, at this point it works, and I'm tired of trying to figure out why that made a difference.
Thanx for your feedback! It would make sense if you used pin 4 on GPIO port A in your user code, as this is used for the radio. But on port B there should be no issues as you describe. Good to know that removing this pin from the .ioc fixed the issue!