Using SRAM variables during debugging?

Discussion to talk about software related topics only.
Post Reply
IanH
Posts: 2
Joined: Mon Nov 23, 2020 3:27 am

Using SRAM variables during debugging?

Post by IanH »

I have a simple program that uses most of the mod5282 processor time running a level 6 interrupt. This retrieves data from the qspi buffer, averages it and stores the result in an array and then refills the transmit buffer. The sampling rate is 100KHz.

I would like to put a handful of variables commonly used in the interrupt into SRAM. Looking at the 'sram performance gains application note' I see that constants.h does not move variables to sram in debug mode. Why?.

When I compile the release version of the code and download it, the program crashes, what are the most common issues that could cause a program that runs in debug to crash in release - any pointers to ideas please?.

In other eclipse embedded development systems (without exception IIRC) it is possible to inspect the Special function registers as well as the processor registers, globals etc. Is there a way to do this in netburner please?.
User avatar
pbreed
Posts: 1080
Joined: Thu Apr 24, 2008 3:58 pm

Re: Using SRAM variables during debugging?

Post by pbreed »

Release mode is significantly faster and more reliable than than Debug mode.

If your doing user written ISR's 99% sure your problem is compiler optimization and volatile...

Any variable that is changed in the ISR (or a hardware register, or a differnt task) and then expected to be read somewhere else needs to be marked as volatile...


The classic case is:

//Global
bool OkToRun;

ISR
{
OkToRun=true;
}



Task....

while(!OkTorun)
{//do something else
}

//Run....
//This code never runs.....

The compiler sees that the //do something else code does not touch OkToRun.
So it only ever checks it once... no point in testing a variable that never changes...
The compiler optimizes the check away....

So if something other than the local code (say an ISR , a hardware register or additional task)
changes the value it needs to be marked volatile.
You will note that all the hardware registers in the sim structures are marked volatile.....

So it should be

volatile bool OkToRun;

Then it will work as you expect in release mode.
IanH
Posts: 2
Joined: Mon Nov 23, 2020 3:27 am

Re: Using SRAM variables during debugging?

Post by IanH »

Hi,
making the strings used in tasks 'global' seems to have fixed this (messily), perhaps the debug mode allows more stack space for tasks since it isnt using sram?. It appears dangerous to allocate many local variables in tasks - though I am not sure how to quantify the stack headroom. IIRC the code worked on a mod5272, but not on the current mod5282. Perhaps the mod5272 uses the larger sdram for such storage, since it only has 4k of sram.
Cheers
User avatar
TomNB
Posts: 538
Joined: Tue May 10, 2016 8:22 am

Re: Using SRAM variables during debugging?

Post by TomNB »

Hello,

A few strings declared in a task should not be a problem. Unless they are very large. A better way than moving declarations out of the task is to use the static keyword for the declaration. That way they are stored in global space, but declared in the function. The rtos is designed to work over very wide range memory, from a single chip to large amounts of external ram. So the default task size is 8k bytes. When you create your own tasks you can make them whatever size you wish. If you want to change the system defaults you can do that in the constants.h include file.

For myself, if I declare anything large as a variable in a task, I prefer to use static, that way I don't have to worry about stack space.
Post Reply