Teensy 4.1 freeze when executing code from flash

Ralf K.

Member
I have a somewhat larger code base that runs emulations for multiple different old arcade vector games. While the emulations part itself is time critical there are although part of the code that are not. like setup, configuration menus etc. To free up RAM I am moving these functions to be execute from flash. The strange thing now is that while it works fine for some functions others will freeze the whole teensy when execute from flash. Even the reset button isn't working anymore.

Is this a known issue? And if this is the case is there a way to check if a function could be execute from flash instead of RAM without relying on try and error?
 
Have not seen that reported before.

Does the Teensy do a Restart after the 'freeze'? If there is some 8 seconds delay and a restart it may be from a usable gathering of Crash Data.

Try using CrashReport to see if it will identify the problem code:
Code:
setup() {
  Serial.begin(115200);
  while (!Serial && millis() < 10000 );
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  if (CrashReport) Serial.print(CrashReport);
...

}

This will print Crash details if the Teensy remains powered and is restarted and then has to have Serial online within 10 seconds for the data reporting with the above code.

Also - Teensy 4.x has no reset button, the Button puts the Teensy into Program mode.
 
So far the only way I found to get it out of this state is a full power cycle. Therefore I cannot get a crash report. I haven't tried adding a watchdog yet.
 
So far the only way I found to get it out of this state is a full power cycle. Therefore I cannot get a crash report. I haven't tried adding a watchdog yet.

Thought that might be the case - and if it isn't auto restarting then CrashReport code may not get called in this case.
And if the Button won't go into Program mode it seems the MCU is 'offline'?
If there is a processor hang is reading/running code from FLASH while something else has a needed bus - perhaps this isn't debug'able

If you have an unused pin - or one you can use only in this case - you could setup an interrupt for it and PERHAPS restart the Teensy.
Tested this version of BLINK to work when 3.3V applied to pin #33 - not hopeful - but MAYBE ...
Code:
void ResetInterrupt() {
  SCB_AIRCR = 0x5FA0004;
  while (true);
}

elapsedMillis noDelay;
void setup() {
  Serial.begin(115200);
  while (!Serial && millis() < 10000 );
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  if (CrashReport) Serial.print(CrashReport);
  pinMode(13, OUTPUT);

// like this - pick a pin 33 or other ... pulldown/rising or pullup/falling
  pinMode(33, INPUT_PULLDOWN);
  attachInterrupt(33, ResetInterrupt, RISING);
  NVIC_SET_PRIORITY(IRQ_GPIO6789, 0);

...
}

void loop() {
  if ( noDelay > 1000 ) {
    noDelay -= 1000;
    digitalToggle( LED_BUILTIN );
  }
}
 
Sorry, I have no idea.

But if you have some examples of a functions that when run from FLASH that causes it to hang/crash, that you can post, maybe something might
give us hints on what is happening.
 
BTW: In testing I made a LARGE Flash code test and that worked. So, it has to be some specific problem code that runs from Flash when it conflicts

That code github.com/Defragster/T4LockBeta/tree/main/Code4Code was tested running Locked and Encrypted. It cascades through 4,000 calls to do some work and get RAM results it compares to FLASH stored results as it goes through each function calling down to the next and then returning to verify.
 
Any chance you can trim the code down to something small enough to share here in a forum message, but still reproduce the crash?
 
Sorry, I have no idea.

But if you have some examples of a functions that when run from FLASH that causes it to hang/crash, that you can post, maybe something might
give us hints on what is happening.

This is one of the functions I needed to remove the FLASHMEM to avoid the freeze. As a sidenode it although worked after reducing*the input checks from 12 to only 3. Therefore I assumed that it might be an issue with the amount of code and the instruction cache.

Code:
VectrexMenu::MenuResult VectrexMenu::UpdateInputs()
{
	uint32_t newState = 0;

	if (m_P1_Button1()) newState |= (uint16_t)Input::Button1;
	if (m_P1_Button2()) newState |= (uint16_t)Input::Button2;
	if (m_P1_Button3()) newState |= (uint16_t)Input::Button3;
	if (m_P1_Button4()) newState |= (uint16_t)Input::Button4;

	if (m_P1_Left()) newState |= (uint16_t)Input::Left;
	if (m_P1_Right()) newState |= (uint16_t)Input::Right;
	if (m_P1_Up()) newState |= (uint16_t)Input::Up;
	if (m_P1_Down()) newState |= (uint16_t)Input::Down;

	if (m_Prev()) newState |= (uint16_t)Input::Prev;
	if (m_Next()) newState |= (uint16_t)Input::Next;
	if (m_Select()) newState |= (uint16_t)Input::Select;
	if (m_Back()) newState |= (uint16_t)Input::Back;

	m_PressedInputs = (m_CurrentInputs ^ newState) & newState;
	m_ReleasedInputs = (m_CurrentInputs ^ newState) & m_CurrentInputs;

	m_CurrentInputs = newState;

	if (m_Test() == 0)
	{
		return MenuResult::Start;
	}

	if (EdgeConnector::CheckSystemRequest())
	{
		return MenuResult::Exit;
	}

	return MenuResult::Navigate;
}
Any chance you can trim the code down to something small enough to share here in a forum message, but still reproduce the crash?

I will see what I can do
 
Now I am feeling very stupid. After I was adding more unrelated code (for the PDP1) more functions in the Vectrex menu part started to freeze. So I decided to remove the FLASHMEM on all functions in this module. While doing so I noticed that I had excendentily marked one of the interrupt functions. Now I have flagged all functions beside the interrupt one and it still works finr.

Sorry that I have bother you while it was clearly my fault.

I assume that my changes had an impact on the memory layout and therefore the interrupt function was either cached together with other code or not. If it was not cached it probably caused a deadlock because it could not fetch the code while in a high priority irq.
 
Now I am feeling very stupid. After I was adding more unrelated code (for the PDP1) more functions in the Vectrex menu part started to freeze. So I decided to remove the FLASHMEM on all functions in this module. While doing so I noticed that I had excendentily marked one of the interrupt functions. Now I have flagged all functions beside the interrupt one and it still works finr.

...

Opps - I hesitated asking the obvious ... are there any interrupt functions involved that should not be in FLASHMEM.

The Teensy's 1062 has 32KB code cache - so maybe it can get away with it for some time if it stays resident in cache.

ESP32 makes special notes about _isr code having to be RAM resident as the CPU is blocked from FLASH TO RAM to run in that condition when not resident.
 
Back
Top