T4.0 Memory - trying to make sense of the different regions

Its been so long now since I read the overtempt seq but I do remember that when a reset triggers the T4 sets a register value for overtemp and was wondering at the time if we could then use that to shut it down. Have to reread that RM again - argh!!! I think it was in SNVS section have to go back again so don't hold me to that.

@mjs513 - I passed code you wrote recently that decoded the boot state/history registers already? Maybe you can find that?
 
@defragster
Been so long now have to go see where I could of put that. Was just looking at the manual - chap15(PMU) pg1234, chap13(pg1185). When panic temp is hit irq_64 should be triggered. So would one have to check to make sure its first been enabled. But have to do a bunch more reading again.
 
@defragster - @Frank B
Finally had a chance to do some work on the tempMon again. Yes, Frank, tempmon now resets when the panic temp is hit.

So using some code I modified from @defragster's debug_tt and @Frank B's power button function for arm power down I updated my standalone temp monitor sketch (didn't want to play with core yet) so I have it so that when the T4 resets due to temperature it will shut down. Attaching the sketch if you want to play and test it.

Let me know what you think.

EDIT: Is there a way to get the LED to blink if we hit panic temp before shutdown? Trying to figure out a way to let user know t4 was shut down due to temp
 

Attachments

  • tempmonStandAlone-200127a.zip
    1.8 KB · Views: 61
@defragster - @Frank B
Finally had a chance to do some work on the tempMon again. Yes, Frank, tempmon now resets when the panic temp is hit.

So using some code I modified from @defragster's debug_tt and @Frank B's power button function for arm power down I updated my standalone temp monitor sketch (didn't want to play with core yet) so I have it so that when the T4 resets due to temperature it will shut down. Attaching the sketch if you want to play and test it.

Let me know what you think.

EDIT: Is there a way to get the LED to blink if we hit panic temp before shutdown? Trying to figure out a way to let user know t4 was shut down due to temp

That works, my Teensy shuts down!

For the blink, wouldn't we use the "high" Temp Alarm? (Give the program time to shut down external hardware or do other things)


Maybe like this?

normal program flow ->
high temp -> user code to do some things (here blink) -> user calls shutdown
panic -> teensy reset&shutdown because user did nothing that helped to keep the temp low
 
Last edited:
That works, my Teensy shuts down!

For the blink, wouldn't we use the "high" Temp Alarm? (Give the program time to shut down external hardware or do other things)


Maybe like this?

normal program flow ->
high temp -> user code to do some things (here blink) -> user calls shutdown
panic -> teensy reset&shutdown because user did nothing that helped to keep the temp low

Ok try this - probably could be simplier for high temp:
 

Attachments

  • tempmonStandAlone-200127a.zip
    1.9 KB · Views: 62
@Frank B, @defragster, @tonton81
here a slightly modified version that follows @Frank B's flowchart which is probably a better way to go:
normal program flow ->
high temp -> user code to do some things (here blink) -> user calls shutdown
panic -> teensy reset&shutdown because user did nothing that helped to keep the temp low
 

Attachments

  • tempmonStandAlone-200127b.zip
    1.9 KB · Views: 70
I tried this :)
I added a Serial.print("alarm") to the High_low_temp isr.
Huston .. we have a problem.. it gets called again and again. Because..yes.. sure, the high temp stays high.
Maybe we need to disable the interrupt until "low" temp occurs? Then, Low-temp should be not much lower then high temp. Maybe 2 degrees?
"Low temp then should re-enable high-temp.

But that's just an idea. Maybe you know a better way?

Or.. just leave it as it is, and provide a "wait for lower temp" which gets called at the end of the interrupt ? (Maybe something with "wfi" - this makes the cpu sleep until the next interrupt and helps to cool it down...)
 
Just a quick note: I just tested something and once the interrupt bit is set its set. I can't seem to clear it. Going to do a work around tonight but tied up with other things right now.
 
Persistent interrupt a pain - but makes sense - it could be polled in loop just as well then.

When seen in either case - record first time and temp - drop CPU speed or other effort to drop the temp based on the system - turn on a fan or alert the user. Monitor the temp for cooling effect and decide what to do if it keeps rising or stays too high too long.

If user gives a callback - can set interrupt or create a polling TempMonitorCheck() function that calls the callback or returns the state, and allows for interrupt disable. No good answer just need information and options to handle it?
 
Have another issue now that I am trying to sort out. If both the Panic and High temp are not both in isr's the T4 resets before Panic temp is tripped unless i have a coding problem - think i am going to start over. But you know me i am a morning person (NY time) not a night owl\\

EDIT: Not 100% true. PANIC ISR never fires. resets before interrupt is set. Have a workaround though :) Tomorrow morning
 
Last edited:
Morning
Ok here is something that we can use for resetting at Panic Temp and high/low temp. The ISRs for Temp are interesting. Low temp is always fired, High temp fired when high temp is reached and always fires, panic never fires before reset occurs. Did test throttling at panic temp and it works, maybe we should use. High Temp lights up the pin13 LED and will turn off at low temp now. Unfortunately once I turn the ISR on it is always firing don't know what kind of performance hit this will be though so this is getting more complicated using high/low temp since there is only one IRQ for both. May have to revert to a user call function to check temps.

Too bad there is no way to use the red LED for this but I believe Paul said we do not have access to it.
 

Attachments

  • tempmonStandAlone-200128a.zip
    1.9 KB · Views: 63
Trying to follow along with all this info about the Teensy 4.0 memory structure, but I have this oddity which I can't explain:

Arduino Verify for Teensy 3.6 produces this:
Sketch uses 661280 bytes (63%) of program storage space. Maximum is 1048576 bytes.
Global variables use 232344 bytes (88%) of dynamic memory, leaving 29800 bytes for local variables. Maximum is 262144 bytes.

Choosing Teensy 4.0:
Sketch uses 659824 bytes (32%) of program storage space. Maximum is 2031616 bytes.
data section exceeds available space in board
Global variables use 582324 bytes (111%) of dynamic memory, leaving -58036 bytes for local variables. Maximum is 524288 bytes.

Not sure why there is a sudden and dramatic increase in global variable size?! The only real difference in my code between 3.6 and 4.0 is using SdFat32 instead of SdFatSdioEX for the SD definition; other than that (handled by a directive) I just switched board types and recompiled.

The largest data structure I have is 153,600 bytes and declared:

DMAMEM uint8_t outBuffer[320 * 240 * 2];

While large, it is fine on Teensy 3.6 and should be fine for 4.0. Any info would be appreciated!
 
@beermat: that is correct.

For background look over the Teensy4 info page with the memory layout details - linked in this thread IIRC or www. search for 'pjrc Teensy 4'

Given that page of info - or this thread maybe - the lower 512KB of directly used fastest RAM1 is loaded with CODE and DATA by default, where the code that is not marked FLASHMEM is placed in RAM1 to run at fastest speed.

To make room for data the code has to be left in FLASH - it will run through a cache as possible - but not always at full speed.

So find the lesser used non critical functions in the code and mark them like : FLASHMEM void setup() { // … }

Repeat that until the size comes down with code running from FLASH - and the code is stable allowing for runtime use of stack memory exceeding that RAM1 area. Also to help would be to alloc more memory at runtime from the DMAMEM heap when possible instead of static or stack allocated.

Also note that the RAM1 is allocated to CODE in 32KB chunks. So depending on how much free area in that final code block it may not show until whatever portion of that last used block is reduced.
 
@beermat: that is correct.

Thank you for the response, but - the device with twice the flash and four times the RAM (4.0) cannot handle the exact same sketch as the 3.6?! I quickly went through my code and marked 90% of it FLASHMEM. Aside from now badly breaking the compile on the 3.6 (which with half the flash and 1/4 the RAM handled this sketch), it barely made a dent on the dynamic memory, dropping global variables from 111% of dynamic memory to 98% of dynamic memory, which leaves very little room and if this is the solution, this device from a memory perspective is actually worse for me than the less well hung 3.6! Also, where is the other half of the RAM?! This isn't making a lot of sense - folks will recompile their code from 3.6 and have LESS space available/more taken up on the better equipped device?
 
In theory as noted - that is correct.

Posted results a bit confusing? Minimal shrinkage from moving so much code.

If FLASHMEM not provided for T_3.6 ( I haven't tried that ) then #ifdef FLASHMEM to a void replacement?

Yes: T_3.6 has 256KB of RAM - all for Variables. And all code runs from FLASH, unless marked FASTRUN.

And T_4 has 512KB in RAM1 ( the other 512KB is RAM2 for DMAMEM and run time allocs )

FrankB just posted a runtime memory function : flexRamInfo() in a new lib :: github.com/FrankBoesing/T4_PowerButton
Look into these functions for info:
unsigned memfree(void); //free stack / global variable space
unsigned heapfree(void); //heap heap space
void progInfo(); //display file + vesion info
void flexRamInfo(void);
unsigned long maxstack(void); //maximal stack usage

That will give a view of memory as used.
 
Reading the last entries, I was wondering if one could not modify the linker/startup to behave as with T3.6, that is to copy to RAM only variables and Fastrun.
For me memory is MUCH more important than speed (in fact I run T4 at 24 or 150 MHz). I understand Paul's design decision, but my mileage varies.
 
Compile option for RAM_Size or something would be a good way to bypass that with only code in RAM being FASTRUN?
 
Reading the last entries, I was wondering if one could not modify the linker/startup to behave as with T3.6, that is to copy to RAM only variables and Fastrun.
For me memory is MUCH more important than speed (in fact I run T4 at 24 or 150 MHz). I understand Paul's design decision, but my mileage varies.

I second that emotion. If behavior is flipped significantly (from defaulting to flash unless FASTRUN, changed to RAM unless FLASHMEM) I'm an opt-in kinda guy, not opt-out (although from my first pass above, I can't seem to opt out). I'm also memory constrained, not speed constrained, execution from flash was perfectly fine, but memory was running short, hence the upgrade to T4 which promised 4x RAM (and a blazing clock to get some free speed bumps anyway), but right now (and I hope this changes), I'm actually worse off moving from T_3.6 to T_4.0, from a RAM perspective.
 
You can use FLASHMEM to run code from flash,
PROGMEM to have const data in FLASh,
And you can use malloc() or DMAMEM to use the OCRAM.

Combining these can help a lot - without changing the linkerscript.
 
@beermat - something extra affecting this code ???: libraries direct for devices or printf or other core function use bringing large bits of code into RAM1.

No reason T4 isn't better on RAM - maybe needs some tuning - even if it only doubles from 256 to 512KB in RAM1 and giving access to 'extended' RAM2 { DMAMEM / malloc() }

Even at the same speed the T4 should generally be faster with smarter CPU processing.

Showing the memory details with the lib linked in post #115 might show something useful.

Does the code use double ( 8 bytes ) instead of float ( 4 bytes )? T_3.6 IIRC defaults to floats and the T4 with double hard FPU defaults to that.
 
... but I'm with you: Would be good to have a way to choose a different linkerfile from the Arduino-menus.

But, really, as long Arduino does not save the settings on a per-project basis, it's only as half as useful as it sounds (for me). This is really annoying. I have a way around this but I've lost motivation to patch everything again and again with every new version. I can even live with the crappy editor - but this really turns me off.
 
@Frank - with the T4 getting more complete and a T_4.1 in the future this may be the time to tune the 'patch everything' things? I assume this refers to defs.h usage providing #define replacements?

The 1MB of RAM in the 1062 split as it is makes it hard enough to get full use of that RAM - right up there with extended RAM on the original 640KB PC's. And similar issues will come with the 3 parts on the 2MB of RAM in a future 1170 based unit.

With the T_3.6 we tested against all compile FAST*,size,debug and LTO variations, and so far have only built with default FASTER speed.

Trying to get complete use of this hardware will require added flexibility it seems
 
@wmxz: you're right. (And they should at least have their init code in flashmem by default)

If I had wishes free for Arduino, i'd knew a lot.

Project settings, force rebuild, serial monitor logging to file/file upload, VT100 with colors, on Teensy a dedicated emulated serial for every USB mode as logging/error channel (display in red in the sermon or as popup), etc etc etc..
:) ok, xmas is over.
 
Paul has selectively placed some init code in TEENSY4 tree into FLASHMEM … but that doesn't likely cover some fat things like printf() and other such libraries.
 
Back
Top