More user application memory needed

I’ running out of program memory. (‘APP_FLASH’ overflowed) on my photon

I’m I right to understand that the user application is limited to 128k?

What can I do to increase this limit without having to change my code?
Is working in modular mode instead of with 3 firmware (part1, part2 and user part) is a good solution?

In my case, the devices will never be connected to the internet and the firmware updates (if there are needed) will be made over wifi (softap) or usb.

What is the actual size of part1 and part2?

Thanks!

1 Like

So I compiled locally using modular=n and my application now compile without error. I was able to flash over dfu and confirm that everything is still working.

The bin file size is 533k with 0.6.0 and my user application that is just a little bit over 128k

I have now over 350k free space. Nice!!!

I’m about to ship my products to my customers this week. Any advice regarding the modular firmware that I should be aware of?

@Suprazz Nice! That’s a huge bump in program memory.

So what exactly did you remove and what functionality did you loose?

I didnt remove anything. I only compiled the firmware in single file mode instead of modular (part1, part2 and user part).

I could be wrong and it might not be an issue for your product, but this way OTA flashing may not work anymore.

1 Like

@Suprazz @ScruffR What exactly is happening to free up 222kb of extra application memory?

I have a feeling I may need more than 128kb of application code on my main project but I have not crossed that bridge just yet so it’s nice to hear about things like this but I’m not clear on exactly what is being lost feature wise when doing this.

@BDub @Mdma If you guys are around could you chime in on this just so we know what’s up. :smiley:

1 Like

BTW, I have a total of over 350 + 128. Around 475-500 kb of flash available.

But I have fews issues right now.
You’re right @ScruffR the OTA flashing return this error if I try to use the feature again: Flash device failed [object Object]

I also have new very strange bugs that I didnt had before… Most of them related to the SoftAP

Everytime I find a solution for a problem, I create at least 2 other problems! :@

1 Like

Is it possible to play with INTERNAL_FLASH_SIZE without breaking anything?

Paging @mdma, perhaps he can shed some light on what is going on. I would imagine that with monolithic firmware there aren’t any “gaps” between system parts 1, 2, and the user firmware which is where you are getting your “extra” memory back from.

Yes exactly. I’m using the unused space of part1 and part2. I understand that the dev want to keep free space for development but 128k for big projects is not a lot of memory. I need more!

I realized that even if I’m not using OTA, I’m using OTA functions to program the device from the softAP so it look like it’s a big issue and there is too much information missing to continue using the mono firmware.

How can I take part1 and part2 extra space to increase the 128k of the user application? I dont mind not being able to use other firmware than 0.6.0.

I’ve been reading on this all evening:

const module_bounds_t module_bootloader = { 0x4000, 0x8000000, 0x8004000, MODULE_FUNCTION_BOOTLOADER, 0, MODULE_STORE_MAIN };
const module_bounds_t module_system_part1 = { 0x40000, 0x8020000, 0x8060000, MODULE_FUNCTION_SYSTEM_PART, 1, MODULE_STORE_MAIN };
const module_bounds_t module_system_part2 = { 0x40000, 0x8060000, 0x80A0000, MODULE_FUNCTION_SYSTEM_PART, 2, MODULE_STORE_MAIN};
const module_bounds_t module_user = { 0x20000, 0x80A0000, 0x80C0000, MODULE_FUNCTION_USER_PART, 1, MODULE_STORE_MAIN};
const module_bounds_t module_factory = { 0x20000, 0x80E0000, 0x8100000, MODULE_FUNCTION_USER_PART, 1, MODULE_STORE_FACTORY};
const module_bounds_t* module_bounds[] = { &module_bootloader, &module_system_part1, &module_system_part2, &module_user, &module_factory };

const module_bounds_t module_ota = { 0x40000, 0x80C0000, 0x8100000, MODULE_FUNCTION_NONE, 0, MODULE_STORE_SCRATCHPAD};

So if I understand well, there is
256k for part 1 and almost everything is used.
256k for part 2
128k for user
128k for default app?? What is this exactly? OTA and listening mode? Is there a way to shrink that? How can I build this part and resize. I can do it for part 1 and part 2 in /modules/part… doing a make clean all.

I tried to change the part 1 size by changing the values in the code and by modifying the make files and it seens to work but there is almost no free space in part 1 so the make failed with app size too big…

and 256k for module_ota. This is only for OTA upgrades so we can store the upgrade temporary before we can validate and load it on the device?

Maybe this could be a solution for me because I have an external flash memory that I’m already loading the firmware to temporary…

Thanks!

1 Like

I really need more than 128k of user memory. I understand why it’s done this way but when you first look at the specs of the chip, it says 1mb so you think that you’re good but when you realize that’s only 128kb, its really bad.

I think the best solution for me would be to not use the 256k reserved for ota and put that on the external memory instead.

Any suggestions on how to do that?

Thanks

If there only was such thing on the Photon :wink:

Why not. I have an external memory.

@Suprazz, the system firmware is open source. The original Spark Core used external flash for storing keys and other items (not sure about OTA). You can modify the source code to suit your needs.

In Arduino land, besides the bootloader, you need to load ALL the libraries so even 1MB would be deceptive. The 128KB on the Photon is "un-taxed" by all the functionality embedded in the system firmware. Perhaps you need to either rethink how you are using the Photon or consider a different platform. Can I ask what in your code is requiring more room?

2 Likes

Open source is a thing. Working on the system firmware is not that user friendly. It’s a little bit hard to figure out how to do that and how to start debugging it. I’m used to work with Microchip uC with programmers and IDE.

Regarding the photon, the only reason why I used this uC is because if the embedded wifi and size. I thought it would be easier to begin with something like this but at the end, I had many issues and limitations.

The photon is used in a car gauge with oled 160x128 display. Multiple font are used so this is where the major part of the application memory is used.

The rest is SPIFFS library, HTTP SoftAP and all the code to analyse the data.

Any serious project will need more than 128kb but it look like most of the people (like most of the arduino users) will only use a fraction of the capability of the uC.

I’ll review the system firmware code to see if I can figure out how to merge photon and core code to use OTA on the external flash instead of using the program memory.
If you have any guides or great place where it’s explained how to play with system firmware, I would like to see that. I can already compile on my computer with gcc and I can program with dfu easily so I’m not that far.

@Suprazz, GUIs are real space eaters and the reason why I asked. This is usually why I recommend HMI displays for these applications, including the 4D Systems and Nextion units. They take all the UX/GUI heavy lifting away from the uC. They do, however, increase cost.

I don’t disagree with you on the need for more flash and RAM and I am lobbying Particle for a next-gen Photon with a heftier processor. In the meantime, perhaps @mdma can provide guidance in making more flash available to the user, if possible. For playing with the system firmware, a good place to start is here. :smile:

In my case, the dimensions and cost was the issue. I could not use the 4D systems unit for this reason (but I tried one and it works very well btw!).

I’ll start working on this in the next few days. I’ll document what I find here.

Thanks!

1 Like