problem with low votage

Home › Forums › mDot/xDot › problem with low votage

Tagged: 

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • March 6, 2017 at 9:48 am #17673
    Martin Pelletier
    Participant

    Hi,
    on my bench test i have multiple systems with the mdot.
    this morning i noticed i got an error on one system. I got a low battery and the system has stopped. So i put a new battery but the mdot module has never worked again. i checked it on debug mode and i got this message:

    [ERROR] File from flash wrong size. Expected 1024 – Actual 502
    [ERROR] SPIFFS_open failed -10002
    [ERROR] SPIFFS_open failed -10002

    is it due to my empty battery?? is it normal?
    is it lost its configuration?
    is it possible to reprogram it?

    March 6, 2017 at 10:32 am #17675
    Mike Fiore
    Blocked

    Martin,

    This is a known issue with older code. It is possible for the filesystem on the external flash to get corrupted when VDD starts to droop. We’ve implemented protection that significantly reduces the chance of this happening in our latest firmware & library.

    Please open a support case and we can help you get your mDot back up and running.

    Cheers,
    Mike

    March 6, 2017 at 1:06 pm #17679
    Martin Pelletier
    Participant

    Thx Mike,
    very appeciated!!

    My software used this library:

    mbed-os -> 2742:5faf4b2
    libmdot-dev-mbed5 -> 80:e85c370

    is it correct? or should i used somthing else?

    regards

    March 6, 2017 at 1:31 pm #17680
    Mike Fiore
    Blocked

    Martin,

    The library version you’re using is indeed the most recent dev version. It takes steps to protect the flash when the voltage is too low to write. This seriously reduces the chances of filesystem corruption. However, the log output does look like the filesystem might be corrupted.

    libmdot-dev-mbed5 -> 80:e85c370 was compiled against mbed-os-5.3.4.
    mbed-os -> 2742:5faf4b2 is mbed-os-5.3.6 (you can see this by clicking “revisions” for mbed-os).

    We recommend using the same mbed-os version in your application as the one the dot library was compiled with for maximum compatibility.

    I’m not saying that using a slightly different mbed-os version caused the flash corruption, but I do recommend changing to mbed-os 2740 (5.3.4).

    If you open a support case, we can help get your mDot back up and running.

    Cheers,
    Mike

    March 6, 2017 at 1:35 pm #17681
    Mike Fiore
    Blocked

    Martin, another question…

    Was your application interacting with the filesystem using the API in the Dot library or another method?

    March 6, 2017 at 2:10 pm #17682
    Martin Pelletier
    Participant

    Ok i will be aware about matching both of them. I am using the API.

    i was a bootloader firmware and i erased my flash and reprogrammed my node id and now it is working fine 🙂

    so i am little afraid because i was last update!!

    i will put the mbed-os 5.3.4 and i will make some test with batteries almost discharged.

    regards,

    March 6, 2017 at 2:57 pm #17684
    Martin Pelletier
    Participant

    Another subject:

    I used peer to peer with 4 slaves (wake up every second and send their status) and one master (receives their messages and send them an ACK).
    It is working!!

    But sometime I got this error on one slave debug port: [ERROR] Send failed : code 10. Do you know what does it mean? Is it because it sends a message at the same time than another slave?

    regards,

    March 6, 2017 at 4:29 pm #17685
    Mike Fiore
    Blocked

    Martin,

    That error code means the mac layer is busy with the previous transmission. If your device has TRACE logging turned on, you should see the following from the debug port: “Link is busy with previous send”

    One slave wouldn’t know if it was transmitting over another slave or not, so that’s not the issue. This error usually happens when attempting to transmit too soon after the previous transmission.

    1s is not a lot of time to TX a packet and RX an ACK, depending on the datarate and frequency band. Does the issue go away if you increase the interval between TX for the slaves?

    Cheers,
    Mike

    March 7, 2017 at 7:59 am #17686
    Martin Pelletier
    Participant

    Hi Mike,
    if i increase the interval, yep the issue goes away!

    But i use this function before to use the send()
    if (!_dot->getIsTransmitting()) //true if currently transmitting
    …

    Should i use other thing? ie getIsIdle() to be sure the receiver is ok too. Because i think if i use multiple slaves, each slave receives the packet of the other slaves not only the master ack. So if the slave try to send a packet while the receive a packet from other slaves, is it possible this will generate the send error??

    Note: I have my own protocole and slaves packet are always rejected from slave receiving because it waits for specific ack packet.

    regards,

    March 7, 2017 at 9:01 am #17687
    Mike Fiore
    Blocked

    Martin,

    I think you’re on the right track. Making sure the slave is idle before trying to TX is likely to resolve the issue, I think.

    Cheers,
    Mike

    March 7, 2017 at 9:45 am #17688
    Martin Pelletier
    Participant

    Great thanks Mike for your help!! Very appreciated 🙂
    I am gonna replace it with getIsIdle() and see it…

    Concerning the battery issue, we have tested a slave at least 4 times with a discharged battery and sounds good up to now.

    regards,

    March 8, 2017 at 3:40 am #17696
    Andrew Lindsay
    Participant

    I’ve been looking at the changelog and is shows that libmdot-mbed5 2.0.16 has the fix, but the revision details for libmdot-mbed5 show it is only at release 2.0.15:

    Revision 57:610f9e955516
    mdot-library revision 2.0.15 and mbed-os revision mbed-os-5.1.5

    Can you confirm this fix is in the production release or that it is only currently available in the dev version of the library? If only available in the dev library, when is it scheduled to be pushed into the production library?

    thanks

    Andrew

    March 8, 2017 at 7:43 am #17699
    Mike Fiore
    Blocked

    Andrew,

    You’re correct. The fix is currently only in the development build.

    I’ll be pushing out a 2.0.16 production build for mDot in the near future.

    Cheers,
    Mike

    March 8, 2017 at 12:45 pm #17718
    Martin Pelletier
    Participant

    Hi Mike,
    if i got send error, do i need to do something if i want to send it again?
    (add delay, clear buffer, init something??)
    if i have 3 send errors in a row, i do this: dot->resetCpu() but it is drastic!!!

    Ack_timer.start();
    while ((_dot->getIsIdle() == false) && (Ack_timer.read_ms() < timeout));
    Ack_timer.stop();
    Ack_timer.reset();
    if (_dot->getIsIdle())
    {
    status = _dot->send(SendVector,false);
    if (status == mDot::MDOT_OK)
    …..
    }

    regards,

    March 9, 2017 at 3:05 pm #17753
    Martin Pelletier
    Participant

    Hi Mike,
    i made other tests with debug mode and trace mode.
    and when i got this error ‘Radio Rx CRC error’ after that the mdot generate ‘send failed: code 10’ for the next radio sending and more.

    If i disable the CRC ( dot->setCrc(false) ), the slave interface works pretty good. I don’t need the CRC because on my own peer to peer star network, i already manage it!!

    regards,

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 15 total)
  • You must be logged in to reply to this topic.