Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 10 of 10

Thread: Teensy 4.1 freeze when executing code from flash

  1. #1
    Junior Member
    Join Date
    Dec 2020
    Posts
    17

    Teensy 4.1 freeze when executing code from flash

    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?

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,364
    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.

  3. #3
    Junior Member
    Join Date
    Dec 2020
    Posts
    17
    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.

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,364
    Quote Originally Posted by Ralf K. View Post
    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 );
      }
    }

  5. #5
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    10,975
    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.

  6. #6
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,364
    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.

  7. #7
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,810
    Any chance you can trim the code down to something small enough to share here in a forum message, but still reproduce the crash?

  8. #8
    Junior Member
    Join Date
    Dec 2020
    Posts
    17
    Quote Originally Posted by KurtE View Post
    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;
    }
    Quote Originally Posted by PaulStoffregen View Post
    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

  9. #9
    Junior Member
    Join Date
    Dec 2020
    Posts
    17
    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.

  10. #10
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,364
    Quote Originally Posted by Ralf K. View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •