Listen Mode (possible bug)

I am. The error is there if a USB serial is connected or not though. What should I test? Turn off all Serial?

I would say it affects the CLI setup more over USB, but it would be interesting to know what you find when you disable Serial USB debugging log handlers.

I’ve now removed ALL references to Serial. We do not use the LOG class. This produced an interesting effect: the device was no longer capable of deleting all passwords by holding Setup-button for 10 seconds? It could enter Setup, but holding the button did not trigger the deletion of the passwords. This was using 0.8.0-r4 on the device.

I then downgraded to 0.7.0 and now clearing the passwords by holding Setup button displayed the exactly same bug as before - fast blinking blue followed by fast blinking red. Setup still hangs (through both iOS/Android and CLI as before) :-/

@jenschr Hmm, that’s odd, can you check if you have the bootloader installed with the CLI:

particle serial inspect

Also, one nice thing about the logging API is that if you use Log.info("my debugging %s", "is awesome!"); in your code, you can simply comment out the Logging handler to disable it SerialLogHandler logHandler(115200, LOG_LEVEL_ALL); and that’s just the most basic benefit.

If I do “particle serial inspect”, I get this:

Could not get inspect device: Serial timed out

?

You need to be in listening mode. If you were, try safe listening mode. Go into safe mode, then while in breathing magenta, hold the SETUP/MODE button to go into safe listening mode (also blinking blue). If you need to go into safe listening mode with your firmware installed to do a particle serial inspect, that’s interesting in itself because your firmware is preventing those commands as well.

So if I go into Listening mode by holding Setup for 3 seconds, I get this:

$ particle serial inspect
Platform: 8 - P1

That's it. If I go into Listen mode from Safe mode, I get this:

particle serial inspect
Platform: 8 - P1
Modules
Bootloader module #0 - version 101, main location, 16384 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 207, main location, 262144 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #2 - version 207, main location, 262144 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 207
Bootloader module #0 - version 7
User module #1 - version 5, main location, 131072 bytes max size
UUID: C2D5F69A8BA2C7403A159519014D6DCFF9E8620968EDE0CEA9E5D36F2FB16FB0
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #2 - version 207
empty - factory location, 131072 bytes max size

This is repeatable. So yeah... I think @rickkas7 will find this interesting?

It seems your firmware is using SYSTEM_THREAD(ENABLED) and is probably still doing stuff to Serial (or other resources shared with system) while the device is in LM - since your firmware is not running in Safe LM, things work as expected.

@ScruffR SYSTEM_THREAD(ENABLED) is not used.

I know because we tried using it about a year ago and it caused stability issues. It does not exist in our code.

Any idea? Do you need code to replicate? Cc @BDub

Hey @jenschr! Can you throw a call to System.freeMemory() in your firmware and let us know what you get back? It doesn’t tell the whole story since it’s reporting heap size and not accounting for fragmentation, but it’s at least another clue. In the meantime, I’ll investigate how large a chunk of memory listening mode needs.

1 Like

Weekend caught me here, but I now did a test and System.freeMemory() reports free memory to be 17296. This is after removing a 10k buffer that we suspect to be related to the problem. The error still persists with this much free memory though.

I’ve gone back in our GIT repository and found that the error started occurring late April. At this point in time our freemem reported 23704 bytes and the compilation stats were like this:

text data bss dec hex filename
74220 2124 27028 103372 193cc /workspace/target/workspace.elf

On purpose, our code does very little dynamic allocation. If we remove features in our firmware so that we approach 21Kb free memory, it’ll start to work. With 20448 bytes, it still exhibits the problem, so it looks like there’s a limit somewhere near that number in our case. Does that fit with what you’ve found @bsatrom?

This is the compilation output at the point in time when things start working:

text data bss dec hex filename
80716 2144 29500 112360 1b6e8 /workspace/target/workspace.elf

Hey @jenschr, I haven’t been able to run those tests on my end yet, but I will today. My plan is to take a simple sketch and run the memory down bit-by-bit, go into listening mode and see where things fall down. :slight_smile: I’ll keep you posted!

3 Likes

Hey @jenschr I’ve been working on this off and on over the last few days and I’ve determined that the failure point on my Photon (which should be true of the P1 as well) is around 21496 bytes. Are you able to optimize your firmware to get from 17296 to 21500+?

3 Likes

Hi Brandon,
Thanks for confirming this! Pretty sure we can slim it down. It just needs some creative thinking :slight_smile:

J

3 Likes

Glad to hear it, @jenschr. We’ll also do some investigating on our end to see if we can find any ways to save when one enters SoftAP mode. And I’ll also make sure the current state here gets captured in the correct places in our docs. Thanks for bringing it up!

@bsatrom,@ScruffR - Quick clarification :

What is “free memory” here referring to ?
Is this free-memory needed BEFORE entering Listening mode ? Or
Is this free-memory needed AFTER entering Listening mode ?

Also - how does “bss” (in the compile report) fit into this “free memory” definition ?

Thanks,
Dhaval

Roughly speaking total RAM - (bss + data) = free memory on start-up. After that dynamic memory allocation will reduce free memory.

2 Likes

Thanks - that helps !

Any word on the other question :

What is “free memory” on this thread referring to ?
Is this free-memory needed BEFORE entering Listening mode ? Or
Is this free-memory needed AFTER entering Listening mode ?

You should have the said amount of free memory before entering LM in order to even be able to successfully enter LM.

1 Like