OOM Errors with ample memory on Teensy LC

Status
Not open for further replies.

vince.cimo

Well-known member
Hi guys, I'm running into a strange issue where after upload, my Teensy LC becomes unresponsive seemingly due to out of memory errors, even though my data usage is well within the limits.

For example:

I have an data array with 5 values; on upload, the data usage is calculated as follows:

DATA: [===== ] 54.3% (used 4448 bytes from 8192 bytes)
PROGRAM: [==== ] 40.9% (used 25996 bytes from 63488 bytes)

When I compile and upload, all of my serial.print lines work fine and the program works great.

If, without changing anything else, I increase the size of my array to hold 6 values, the data usage is calculated as such:

DATA: [====== ] 57.8% (used 4736 bytes from 8192 bytes)
PROGRAM: [==== ] 41.0% (used 26004 bytes from 63488 bytes),

But my program is unresponsive.

Are the calculated memory usages not indicative of what's happening at runtime? Is there any way I can see where i'm at during runtime with memory usage?
 
Without seeing code … speculation is that the array increase is resulting in creating or exposing array index handing errors, that is data is written outside the allocated array space?

Perhaps :: there was an error indexing beyond the array boundaries - but it didn't fail because it wasn't trashing anything critical

OR:: the array extension was not properly accounted for everywhere
 
To test this out, I created a separate variable outside of the array, which functionally would occupy the same amount of memory..

For example:

Datatype array[5]
Datatype memoryPusher

Should have the same effect as:

Datatype array[6]

Without the possibility of handling errors. The same behavior persists...
 
To test this out, I created a separate variable outside of the array, which functionally would occupy the same amount of memory..

For example:

Datatype array[5]
Datatype memoryPusher

Should have the same effect as:

Datatype array[6]

Without the possibility of handling errors. The same behavior persists...

That seems logical - but not sure there is a rule or expectation that the allocations would in fact be done that way through compiling and linking. Or the problem could be more than an off by just ONE error?

Also Datatype indicates an unknown structure? So errors may be within structure elements as there is no idea what is in there in the form of fundamental types or arrays or ???
 
Hmm yeah the reason I left it generic is because it's a custom datatype.

Here's the actual initialization causing issues:
(if I change NUMBER_COMMANDS from 5 to 6, hell breaks loose)

DLCommand commands[NUMBER_COMMANDS];

The DLCommand class:
Code:
class DLCommand {

	public:
                DLCommand();
                DLCommand(uint64_t command, DLled * _led, unsigned char _buttonNum, DLObserver * _dataLooper);
                DLObserver * dataLooper;
                DLled* led;
                unsigned char * state;
                bool toggle = false;
                void sendSysEx(); 
                void execute();
                void checkLed(bool onOff);
                void checkDLCommands();
                ee_storage_typ ee_storage;
};

The ee_storage_typ class:
Code:
typedef union
{
		commands_typ commands;
		uint8_t asBytes[BYTES_PER_COMMAND];
		uint64_t the_big_blob;
} ee_storage_typ;

The actual implementation code inside DLCommand.cpp is super benign and should have any errors on initialization of new variables. I'm pretty sure this is memory related.
 
Status
Not open for further replies.
Back
Top