Skip to main content
Chris Oh
Associate
February 14, 2018
Question

stm32l073 + LoRa

  • February 14, 2018
  • 3 replies
  • 1924 views
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.

    This topic has been closed for replies.

    3 replies

    ab val
    Associate III
    February 14, 2018
    Posted on February 14, 2018 at 11:40

    Hi,

    Are you using the lorawan stack provided by semtech?

    Chris Oh
    Chris OhAuthor
    Associate
    February 14, 2018
    Posted on February 14, 2018 at 12:05

    nope. source by ST (i-cube_lrwan)

    ab val
    Associate III
    February 14, 2018
    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).

    Andrew Neil
    Super User
    February 14, 2018
    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

     
    A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
    Tesla DeLorean
    Guru
    February 14, 2018
    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.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Chris Oh
    Chris OhAuthor
    Associate
    February 21, 2018
    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
    Super User
    February 21, 2018
    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.

    A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.