I have a PSoC5LP Project which has been around for years.
This week I installed the latest PSoC Creator 3.1 Update, and now my system won't fully.
It is more or less operating normally, with the exception that every malloc() fails.
It's as though the system has suddenly ran out of RAM.
It is a very large project, but there is not actually a huge amount in RAM, and anway, it was working fine before I updated to Creatpr 3.1 and re-compiled everything.
At the end of compilation I get this message:
Flash used: 110520 of 262144 bytes (42.2 %). Bootloader: 16128 bytes. Application: 94392 bytes
SRAM used: 28453 of 65536 bytes (43.4 %). Stack: 2048 bytes. Heap: 128 bytes.
check the amount of heap (from which malloc() takes its memory) in the system tab of the .cydwr-file. You may reduce the stack depth and increase heap if you like.
I can do that, but I still need to know why my system was working before I updated to Creator 3.1 and isn't now.
Before creator 3.1 my system generally had several KB of free SRAM, now it has only 116 Bytes!! Something has gone wrong somewhere, and I need to find out where.
There might be some kind of issue with the latest component pack or compiler.
There was a version of creator that did not put into account the amount of flash and heap put aside. The latest version calculates differently and subtracts both these values from the total amount of sram. Have a look into this article.
Yes - but that would only have affected the data in the report.
My point is there have been no code changes, just the update to Creator 3.1 and suddenly the free SRAM in my project has gone from several KB to 116 Bytes!!! Some component somewhere has stolen all my ram!
Kenny, you just have to set your heap size to a reasonable amount. I just checked that and I could proof that each call to malloc() allocates the requested number of bytes + 8bytes for internal housekeeping. Your compilation reported that you have set your heap to 128 bytes only.
Here is my check-program
uint32 Count = 0;
uint32 Amount = 0;
void * Pointer;
#define ChunkSize 20
Pointer = malloc(ChunkSize);
if(Pointer == NULL)
return; // Set breakpoint here and check the local vars.
Amount += ChunkSize;
Yes, but I did not set my heap size to 128 Bytes. I have not changed anything since this was last built.
I see that the compilation reports says I have, but I have not! Somethign else changed it!!!
I did an almost exactly the same test as you, that's how I know I only had ~116 Bytes free.
I would like to figure out how updating to Creator 3.1 caused my heap size to become so small.
Anyway, I have manually changed it back, and it's working much better now.
(Back from Dinner)
Now that your project runs again we can relax!
What changed your settings? I would assume that Creator changed that values. Pre 3.1 malloc() did not take its memory from the heap as it should have done. It took the memory from the last-used ram position incrementing the address, while the stack runs from the upmost address down to lower addresses. A check was made to see if malloc() has run into the stack area. That crushed when you changed your stack manually to a memory-block retrieved by malloc() or when you tried to use a specific memory area for your own purposes. With 3.1 now the malloc() behaves like on any other system. Formerly you didn't specify any heap usage, so in 3.1 it was defaulted to 0x80, the stack size of 0x4000 is imho a bit overdone except you are allocating larger structs or arrays as local vars on stack.
Since your program has been running for years, I have a hunch that malloc has caused memory fragmentation. Can you eliminate the use of malloc and just declare an array?
> Since your program has been running for years, I have a hunch that malloc has caused memory fragmentation. Can you eliminate the use of malloc and just declare an array?
That doesn't make any sense at all. Memory fragmentaion would not survice a reboot!
It's clear what the issue is, the updagrade to creator 3.1 threw away my specified Stack and heap settings.
Yes, you're right, Kenny. I have written several memory managers (for PSoCs, too) and there is usually no problem with fragmentation. The times of systems stalling for a few seconds because of "garbage collection" (de-fragmentation of memory pools) are over because of new algorithms invented and used. Nonetheless the current implementation of malloc() has an overhead of 8 bytes per memory chunk requested which could be optimized down to 4 bytes when programmed more restrict.
I am afraid that you are often the "Lucky Guy" who tries to snatch a treasure but get your fingers caught in a mousetrap 😉 Let me tell you, you are not allone: When I buy 10 PCs for one of my customer I can be sure that one is not running at all, one is constantly striving against attaching to the network and a third one will not run any more after one day of installation work. No matter who delivers the computers, it always hits me. Thinking about to change my name to "Bob Murphy".
I've been really quite lucky with the hardware side of things, I've had several hundred boards made and they have all worked apart from a very few. Of those that didn't work, it was clear that the internal layers of the board had shorts, probably due to being mis-aligned with the outer layers.
The biggest headache has been the Creator software : i)Nasty bugs in the Emulated EEPROM which rendered my customers boards dead. ii)Dropping support for PSoC5 was a huge issue for us, and iii)Updating to Creator 3.1 borked the bootloader, binaries built with 3.1 cannot be bootloaded on to boards with (the same bootloader!) built using creator 3.0. So our customers are either stuck at the current release, or they have to bring the units back to us to be programmed using Miniprog-3.
I no longer design Cypress PSoC products into any of our new designs, I am done with the headaches. I have had NONE of these headaches from other suppliers such as Microchip and Atmel.