[Mikael Grah]

Thank you!

I tried it quickly, but that causes my application to crash at startup, with an out-of-memory error.

 ++ MbedOS Error Info ++
Error Status: 0x8001011F Code: 287 Module: 1
Error Message: Operator new[] out of memory

[Mikael Grah]

Some more data; I’m using mbed-CLI, compiling with GCC_ARM.

When I declare a large array (~50 bytes) for use in main, the dotlib crashes earlier with an mbedOS error stating that “new” could not reserve enough memory to complete the operation.

[Mikael Grah]

I’m actually looking for a solution to the same question – we’d like to use our own software for the xDot and some configuration needs to be stored i NVRAM. Is there a way to flash NVRAM using a regular .bin copy via the xDot-DK?

[Mikael Grah]

Not sure if it matters, but the main serial port is assigned to Port 14 \Serial14 on my Win 10 Pro computer on both xDots, but the debug port \thcdcacm0 is assigned to Port 15 on the newer xDot and Port 9 on the other one…

[Mikael Grah]

I just tested again, with both xDots, and the problem still persists. I flashed both xDots with the same .bin file, in the same USB port (I switched the xDot in between). After Reset, one of them shows a complete printout, including my added “Printf to debug port”, caused by:

printf("Printf to debug port\r\n")

The other xDot, with the same bin file only sends the printf-text and no LogInfo. The xDot sending Info messages also sends the defaul “[INFO] Set radio to public mode.” and “xDot Ready” from the init of libxdot.

The xDots are of two different batches; the first one (where the logInfo function works) has a DOM 2019 08 16, the second one is marked with DOM 2016 10 27. Could that have something to do with the behavior?

[Mikael Grah]

OK, great, thank you!

I’ll test with the latest firmware and see how it responds. This isn’t a major issue for us, but it’s good to know the reason for the behavior.

The debug pins are connected to an external debug port (for PC use). 🙂

[Mikael Grah]

OK, so the description above is 100% repeatable with xDot and AT firmware 3.2.1, as far as I can tell.

I did the following:

Boot up (USB to PC). Type the following commands manually @19200 baud:
+++\r\n
at\r\n

Of course, since the xDot is configured @115200 baud, I get garbage back. Switch to 115200 baud on the PC and send the following:
+++\r\n
at\r\n

The modem responds with the echo characters, excluding the \r\n:
+++at

The normal response would be (communicating @115200 baud from the start):
+++
Command not found!
ERROR
at
OK

This behavior is the same with 3.1.1 and 3.2.1 with both mDot and xDot.

Now, this is an issue for our design, as the “next generation” hardware will not be able to switch off the power of the modem.

Is there any way to get the Dots to “exit” the mode that they’re in? Like an Abort sequence?

[Author]

Posts