stm32l073 + LoRa

[Chris Oh]

Posted on February 14, 2018 at 11:19

Hello, I'm using stm32l073 + sx1272mb2das for lorawan experiments.

my problem is that stm32 board seems to stuck sometimes (in a random fashion). 

my source code has several timers to manage states of lorawan node (stm32). 

maybe the timers stop sometimes because of unknown reasons.

anyone know about this kind of problem?

kind regards.

[ab val]

Posted on February 14, 2018 at 11:40

Hi,

Are you using the lorawan stack provided by semtech?

[Andrew Neil]

Posted on February 14, 2018 at 13:03

my problem is that stm32 board seems to stuck sometimes (in a random fashion)

. 

anyone know about this kind of problem?

Surely, this is just a standard software debugging problem?

You need to find out where it is 'stuck', and what makes it 'stick'.

This is why we have things like debuggers, ST-Links, UART trace output, LED diagnostic outputs, etc, etc, ...

http://www.8052.com/faqs/120313

 

http://www.ganssle.com/articles/developingagoodbedsidemanner.htm

 

[Chris Oh]

Posted on February 14, 2018 at 12:05

nope. source by ST (i-cube_lrwan)

[ab val]

Posted on February 14, 2018 at 13:11

I have been working on lorawan node for a long time.

I have always used the stack from here: 

https://github.com/Lora-net/LoRaMac-node

 

You have code example. I never had any problem (on the region tested by them).

[Tesla DeLorean]

Posted on February 14, 2018 at 16:05

Well the interrupt priorities and blocking loops in the code could be a problem if you haven't thought about it.

Instrument your code so you understand what's happening internally.

[Chris Oh]

Posted on February 21, 2018 at 11:49

Hi, I use Rx continuous mode sometime in source code to get certain packet.

However, I found the device stuck at RX mode and do not capture any packet from random time. 

it seems like the device is not in RX mode that time. (and there is no interrupt event such as rxtimeout, rxerror, rxdone)

what is this kind of problem?

by the way, most devices works with no problem but a few have this trouble at random fashion.

maybe there is a problem with RX continuous mode..?

[Andrew Neil]

Posted on February 21, 2018 at 12:31

Chris Oh wrote:

what is this kind of problem?

It's called a bug. And, as already noted, de-bugging is an essential part of

any

development process - software or otherwise.

See the links posted at

https://community.st.com/0D50X00009XkX7ASAV

As

Turvey.Clive.002

‌ said, a standard approach is to instrument your code so that you can see what is (and isn't) happening.

most devices works with no problem but a few have this trouble at random fashion.

That is typical of a marginal design; ie, your design is barely within spec - or, possibly, slightly out-of-spec - so that you get away with it most of the time, but it fails when things happen to get a little worse than usual for some reason.

[Tesla DeLorean]

Posted on February 21, 2018 at 12:43

The stack has a annoying habit of dwelling in delay loops (or things like TCXO, turning around, sleeping, etc), and blocking in other threads of higher priority, during this time the receiver is NOT listening.

The VCOM code is particularly stupid.

Also make sure the timeout covers both the time between messages, and the time to receive the message. The latter can be quite a long time on high spread factor transmissions. ie when pinging GPS location at top-of-second you want a 1100-1200 ms timeout, setting it to 1000ms inevitably results in loss once it syncs up with the transmitter.