Validating a Buffer is Properly Being Stored in RAM2

[samscudd]

Hi all!

I'm trying to take advantage of the RAM on the Teensy 4.1 to have a little memory buffer that we can use for diagnostics when errors occur in my system. The memory buffer is just a CircularBuffer (using the arduino library) that is filled with CAN_message_t data types from the FlexCAN_T4 library.

I'm using the following code to declare and initialize the data_buffer in RAM2:

/**
 * Declare location in memory that is the size of the CircularBuffer that will store the
 * CAN messages and then declare the data_buffer without initializing it so it is global
 */
DMAMEM uint8_t buffer_storage[sizeof(CircularBuffer<CAN_message_t, BUFFER_SIZE>)];
CircularBuffer<CAN_message_t, BUFFER_SIZE> *data_buffer;
 
/**
 * Initializes the data_buffer in the allocated memory set aside for the buffer using the
 * new (address) syntax for creating the object
 */
void setup_buffer() {
  data_buffer = new (buffer_storage) CircularBuffer<CAN_message_t, BUFFER_SIZE>();
}

This seems to work. When I build the code, it shows that the RAM2 space is now being used:

teensy_size: Memory Usage on Teensy 4.1:
teensy_size:   FLASH: code:99568, data:9728, headers:8460   free for files:8008708
teensy_size:    RAM1: variables:25056, code:93640, padding:4664   free for local variables:400928
teensy_size:    RAM2: variables:372448  free for malloc/new:151840

This being said, I would still like to validate that the data buffer is being stored as intended in RAM2 during runtime and I would like to include this check in my test suite? Is there a way to check this?

 

[PaulStoffregen]

Is there a way to check this?

Sure, just cast a pointer to the data to an int and print it.

Serial.println((int)data_buffer, HEX);

You can also find the .map and .lst files the compiler creates in a hidden temporary folder.

 

[samscudd]

Thanks for the response Paul.

So if I cast a pointer to the data, what value should I be looking for to ensure it is within RAM2 on the Teensy?

Cheers,
Sam

 

[defragster]

Was going to say look here: https://www.pjrc.com/store/teensy41.html#memory

That shows the memory but doesn't seem to detail the address ranges of the memory

They are like this where RAM2 seems to be the RAM portion of:

MEMORY
{
    ITCM (rwx):  ORIGIN = 0x00000000, LENGTH = 512K
    DTCM (rwx):  ORIGIN = 0x20000000, LENGTH = 512K
    RAM (rwx):   ORIGIN = 0x20200000, LENGTH = 512K
    FLASH (rwx): ORIGIN = 0x60000000, LENGTH = 7936K
    ERAM (rwx):  ORIGIN = 0x70000000, LENGTH = 32768K
}

So, it should be somewhere between 0x20200000 and 0x2027FFFF {based on usage in CrashReport}

diagnostics when errors occur

Are you expecting that memory to be valid across warm restarts, or only while actively running?

 

[samscudd]

Thanks for the recommendation!

Are you expecting that memory to be valid across warm restarts, or only while actively running?

It will only need to be in the RAM while actively running and then I'll save the buffer to an SD card when an error occurs.

And to be clear, I'm not trying to track Teensy specific errors, moreso errors with other components in the system, so the Teensy should pretty much always be powered on unless it is intentionally turned off.