// Return true if memory at SRAM boundary was successfully reserved.
// One tiny memory block starting before the boundary and one tiny memory block
// starting at or after the boundary are left allocated.
bool reserveSramBoundary() {
const uintptr_t SRAM_BOUNDARY = 0x20000000u;
struct MemBlock {
MemBlock* next;
};
bool result = false;
MemBlock* first = nullptr;
MemBlock* curr = nullptr;
MemBlock* prev = nullptr;
while(true) {
void* mem_ptr = malloc(sizeof(MemBlock));
if(!mem_ptr) break;
if(uintptr_t(mem_ptr) >= SRAM_BOUNDARY) {
if(first) result = true;
else free(mem_ptr);
break;
}
curr = new(mem_ptr) MemBlock();
if(!first) first = curr;
if(prev) prev->next = curr;
prev = curr;
}
if(!first) return false;
curr = first;
while(curr->next) {
MemBlock* next = curr->next;
free(curr);
curr = next;
}
if(!result && curr) free(curr);
return result;
}That's unlikely. There is only a single memory location with issues and unaligned access is generally pretty rare.I am actually doing a project now where it seems like I have some memory problems about variable declarations and such. I use a Teensy 3.6 where my sketch only uses about 5% of dynamic memory, which is also checked using RamMonitor.h. However, when I add a bit of code to my sketch, not at all related to specific variables, my sketch can respond unexpectedly turning these variables to zero or to weird values.
It seems like this topic could be an explanation for this as well.
You can't really use fixed addresses (unless you know exactly what you are doing). The memory at those addresses won't be reserved, so you are bound to get memory corruption due to conflicts with the stack or the heap.I am also not so experienced in programming in C++, but from what I read, should I always declare my variables at fixed adresses like you are doing in the upper post Bill?
That's unlikely. There is only a single memory location with issues and unaligned access is generally pretty rare.
It's not so rare with some of the SD examples I have published. Using very large buffers with SdFat is becoming more common.
SD cards can have very long write latencies, up to 250 ms. High quality cards are better but still 250 KB at 3 MB/sec is only about 80 ms of buffering. I have examples that use all free memory as a FIFO. With SDIO up to 20 MB/sec is possible so 250 KB is small.
Other users have two very large buffers. As I explained before, even if the buffers are aligned on 4-byte boundaries, a transfer to the SD may start on an unaligned address. Most of these apps write to the SD so they don't fault, just get corrupt data.
These users are also finding bugs in my tired old SdFat code. I have a group of stm32duino users that added 512KB of external memory to STM32 for buffering. They are thinking of even more EXRAM, up to 256 MB. Strange what old retired engineers will do.