Unless you’re using new or malloc you can’t run out of RAM as such.
If there isn’t enough RAM for the stack and the stack overflows then typically an AVR chip just resets.
Most likely your code is getting stuck in an infinite loop somewhere.
That’s going to really eat into your progmem.
Also there’s two definitions of hourglasstop in the source code.
Hopefully only one is being included, otherwise you’ve got an ODR violation and the code won’t compile.
You pass them the same as normal arrays.
They’re the same type because the language has no concept of ‘progmem’.
PROGMEM is replaced with a compiler-specific attribute. pgm_read_byte is replaced with inline assembly.
(In the past I have actually experimented with writing wrapper types to make it easier to differentiate between the two with reasonable success. I’ve never published anything though, because I’ve only ever written them as part of libraries that I’ve considered too unfinished to publish. And of course, once you publish something people expect you to support it and provide bug fixes. :P)
That’s because you’re just indexing the array instead of using pgm_read_byte.
When working with a progmem array you need to use pgm_read_byte(&array[index]) instead of array[index].
The reason for that is because AVR chips actually have a machine code separate instruction for reading from progmem and the compiler isn’t able to decide when to use it.
(Also note that you can’t write to an array in progmem.)