Crash on iterations (myDatalogEASY IoT)

Having a bit of an issue with my device crashing when trying to iterate over an array or whatever really. Here is some code that will trigger the crash:

const testBufLen = 8192;
static testBuf{testBufLen};

#callback timer2s(){
	new i;
	for(i=0; i<testBufLen; i++){
		// testBuf{i} = 127;

	setInterval(timer2s, 2000);

Error message:

# Run time error 1: "Forced exit" on address 000048f8

If I set testBufLen to a lower value, 4096 for instance it will run fine. But if I also uncomment the line that writes a value to the bin array it will crash again. Been racking my brain on this one as I have never encountered anything similar in other languages and devices. An guidance is highly welcome.

Hello @sveinTO,

PAWN execution time is monitored within the rapidM2M firmware. It must not exceed 200ms per processing cycle (e.g. timer callback function).

Or a little more precisely:
The Firmware installed on the myDatalogEASY IoT takes care of general tasks such as saving and transferring data and configurations. In the case of certain events such as the expiry of a timer or the receipt of characters via the RS232, the firmware calls the PAWN functions, which you as the user can freely program. The firmware monitors the processing time for these PAWN functions and delivers the error message you have detected if the function requires more than 200ms to process.

Kind regards
Microtronics Engineering

Initialisation of huge arrays may be solved by one of the following strategies:

a) use initialized variable - applies to one-time initialisation during app boot

static testBuf{testBufLen} = {0xfe, 0xfe, ...};  // the "..." fills up the full array with the value 0xfe

Note: 0xfe must be stated twize! A single 0xfe would result in {0xfe, 0xfc, 0xfa, 0xf8,…) - e.g. the numeric series of -2.

b) use “per cell” (e.g. 32bit) instead of “per byte” (e.g. 8bit) iterations

This is 4x faster than a byte-wise loop!

for( new j=0; j<testBufLen / 4; j++) testBuf[j]= 0x33333333;  // the 8bit contant "0x33" extended to 32bit "0x33333333"

To avoid the #229 compiler warning, use bufset() (32bit version of memset())

bufset( testBuf, 0, 0x33333333, testBufLen / 4);  // don't forget to divide the buffer size by 4

c) combine a+b to initialze blocks much larger than 32bit

This is approx. 50x faster than a byte-wise loop!

const tmpSize = 256;           // instead blocks of 4 byte we take 256 byte at once
new tmp{tmpSize} = {0x55, 0x55, ...};

for( new ofs=0; ofs < testBufLen; ofs += tmpSize)
	memcpy( testBuf, ofs, tmp, 0, tmpSize);

Thanks for both the replies. I see now in hindsight that I should have offered some more context on my issue.

I am interfacing with a device over RS232 that is ‘free running’, as in it spits out data continuously when powered. It has a 12 byte header in front of each data packet. So I have a buffer that is dimensioned such that when it is full it will always contain at least one header and a complete data packet. So my issue arose when I was iterating through the buffer looking for the header. I solved the issue with breaking down the search into smaller parts so the function would not exceed the allotted 200ms and just call it multiple times until the header is found.

Thanks for all the insights.