What is the ram size of Photon for user part firmware is available?

I use an array size is 31200 bytes as an video buffer.After that I was touch by many wired issue.
1.soft ap api stop work,but if I remove one function from setup() it will work,even the function body it is empty soft api not work
2.wired red blink,I do read through the user firmware code and can not find out why
After reduce the array size to 6240,it works.

Hi Ming!
Have you read the datasheet for the Photon?
https://docs.particle.io/datasheets/photon-(wifi)/photon-datasheet/

“STM32F205RGY6 Flash Layout Overview
Bootloader (16 KB)
DCT1 (16 KB), stores Wi-Fi credentials, keys, mfg info, system flags, etc…
DCT2 (16 KB), swap area for DCT1
EEPROM emulation bank 1 (16 KB)
EEPROM emulation bank 2 (64 KB)
Device OS (512 KB) [256 KB Wi-Fi/comms + 256 KB hal/platform/services]
Factory backup, OTA backup and user application (384 KB) [3 x 128 KB]”

It is about flash.

Have you tried the forum search?

Did you try System.freeMemory()?

15KB in itself should not be a problem, but how much RAM is the rest of your code using?
Can you transfer some immutable data into flash?


(Update: After your edit the numbers have changed from 15650/15610 to 31200/6240 which is a massive change and makes me think where did the original figures come from :wink: )

Yes I have seen this also. With some of the recent releases the amount of free memory has been reduced, so if you allocate sizeable blocks of memory (I was allocating about 18k), the amount of free memory obviously also goes down. The upshot of all of this is that if you start Soft AP (which uses a LOT) of memory your device will run out of memory and fault. I reworked my code to drop my 18k buffer to a 5k buffer and was able to run soft AP with no problems.

Sorry,I made a mistake.
When use 31200 bytes It is not work,reduce to 6240 bytes It works

How much RAM we should keep for heap and stack?

I am using latest system firmware too,I need a large array for a color screen.

IIRC the stack is set to 6KB but if you are using SW timers the timer thread needs another KB and when using the Application Watchdog that also needs some stack space for itself and the required heap space is hard to estimate as the demand is highly dependent on your actual code.

But tuning your program to the very limit is hardly a good idea as future system updates may nibble away some of the available RAM forcing you to stick with an older (potentially buggier) system.

BTW, what kind of color screen do you intend to drive and do you actually need a pixel buffer for it?

1 Like

The color screen blink when I refresh it,I have to translate 9bit each time so I have to use I/O not SPI to send data to screen,I am trying to use a buffer to fix blink issue.

Is there a way to keep blink red when an hard fault triggered?I have to do other work and can not keep an eye on led for a long time

You can't keep the device in panic mode, but you can check the reset reason when the device comes back from a crash.

I don't know where your blink issue exactly comes from, but there often are ways to avoid that effect by re-thinking/rearrange the actual screen updating.
Blinking often comes from clearing and redrawing areas which don't want to be redrawn but rather overwritten. For example, if you have "mutating" text, you could clear the background and then draw the text ontop of the cleared area - which would lead to flickering - or you better just select the correct backcolour for the text and just overwrite the previous text without clearing it at all - this won't flicker.

1 Like

Hi ScruffR, can I just clarify something you said.

if you are using SW timers the timer thread needs another KB

Is that if you are using SW timers that each timer thread needs another 1 KB?

Yes, but there only is one timer thread for all timers to share.

Understood. Thanks for the clarification!

I'm running a circular buffer and using the Software Timer to push data into the buffer every 60 seconds. I was also trying the application watchdog.

Based on what you're saying the Software Timer + Application Watchdog are eating up 2KB of the 6KB stack.

I'm wondering if using the Spark Interval Timer library would allow me to replace the Software Timer function to accomplish the same thing while possibly freeing up some of the 6KB stack?

Do you know if the Spark Interval Timer eats up the same 1KB or more of the Stack like the Software Timer function built into the Particle OS?

Not quite.
The application thread has its own 6KB stack and the other threads and the AWD also have their own stack. So the available RAM for all code is reduced by the sum of all these stack areas.

SparkIntervalTimer is not running in a seperate thread so it hasn't got its own stack allocated, but it will use some RAM, but I'd think less than 1K.

However if that 1K decides between make or break, I'd suggest you rethink the general design of your code - especially pay attention to anything that may allocate heap space. Especially since I've seen you were interested in using the Circular Buffer library, you need to be aware of it using dynamic memory allocation.

2 Likes

I did just start using the Circular Buffer library for some running graphs and I'm testing that out now with code that has been pretty stable.

Ideally, I want to have many circular buffers that are stored in the extra 1MB of FLASH on the P1. I know the Circular Buffer library is using Strings which is less than ideal for the stability of the Microcontroller.

I like this Circular Buffer Library because it's easy to understand and use but I don't know enough to tell if it's less than ideally written. I know the library was originally written for the Arduino, but that doesn't mean it's not efficient code.

With my current program System.freeMemory() stays around 46000. I'm not sure what the status of the RAM is though this is where the Stack Overflow happens I think.

Will storing these Circular buffers on the 1MB P1 Flash help any with stability?

@ScruffR @peekay123 @rickkas7 Is there any optimized Circular Buffer code that you could recommend over the library I'm currently using? I'm trying to optimize as I build out this project and I'm at 2200+ lines of code in the .INO so far.

For circular buffers in SPI flash I’d recommend using flashee-eeprom. There’s a mode specifically designed to handle circular buffers efficiently in flash memory.

1 Like

@paulm
It seems we must keep 22k byte free ram for SoftAP

Good to see we have a fixed target number to stay clear of thanks!